On Mon, 18 May 2009, Peter Denison wrote: > Now, on to the actual crash. I will do more investigation, but for now, > here's the backtrace: > > Starting program: <path>/src/.libs/lt-openocd -f > ../../../openocd-usr8200-jlink.cfg > Open On-Chip Debugger 0.2.0-in-development (2009-05-18-18:52) svn:1827M > > BUGS? Read http://svn.berlios.de/svnroot/repos/openocd/trunk/BUGS > > $URL: http://svn.berlios.de/svnroot/repos/openocd/trunk/src/openocd.c $ > jtag_speed: 16 > Error: J-Link command EMU_CMD_VERSION failed (-110) > > Error: J-Link command EMU_CMD_VERSION failed (-110) > > > Program received signal SIGSEGV, Segmentation fault. > jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 > 940 result = usb_bulk_write_ex(jlink_jtag->usb_handle, > JLINK_WRITE_ENDPOINT, > (gdb) bt > #0 jlink_usb_write (jlink_jtag=0x7003e, out_length=1) at jlink.c:940 > #1 0xb7feaaf8 in jlink_simple_command (command=1 '\001') at jlink.c:509 > #2 0xb7febbb0 in jlink_get_version_info () at jlink.c:549 > #3 0xb7febf2d in jlink_init () at jlink.c:324 > #4 0xb7fe2bbf in jtag_interface_init (cmd_ctx=0x804a008) at jtag.c:2333
Preliminary look at this seems to be that jlink_jtag_handle is overwritten with junk. This sits in memory directly after usb_emu_result_buffer, which is 64 bytes long. Are any of the new in_handler replacement callbacks overwriting the end of this buffer? _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development