On Sun, Aug 14, 2011 at 9:01 PM, Xiaofan Chen <[email protected]> wrote: > On Mon, Aug 15, 2011 at 5:26 AM, Jean-Christophe PLAGNIOL-VILLARD > <[email protected]> wrote: >> On 12:04 Sat 13 Aug , Carlson Gary wrote: >>> Hi Eric, >>> >>> I have worked a little on the jlink stuff in the past and fixed a few >>> problems with OpenOCD. I have a new project that is going to force me to >>> buy an unrestricted Segger very shortly since my current jlink dongles are >>> Atmel-only devices. Once I get my hands on a new one, I hopefully will be >>> able to take a look at this problem also. >>> >>> I will try to contact Segger on Monday to see if they can shine some light >>> on V8 communication details. I suspect whatever is wrong is probably minor, >>> but will take a little persistence to identify a solution. >> I already contract Segger this year and their answer are we change nothing >> >> I put segger in Cc this time on the ML hope you will work with us to improve >> J-Link support on OpenOCD >> > > To be fair to Segger, I think they do not intentionally change anything in > the firmware. After all, the firmware needs to be compatible with their own > utility under Windows and Linux. On the other hand, they probably did > not test OpenOCD since that was not their focus. > > From the usbmon log, Segger's Linux utility are consistent through > different versions of J-Link. The main issue is that OpenOCD's J-Link > initialization sequence is not the same as Segger's utility, as shown > in Eric's previous email. I think Gary is probably correct that > "whatever is wrong (in OpenOCD) is probably minor". >
After piles of debugging today, I have determined that command 0x09 is EMU_CMD_REGISTER, which is undocumented in the J-Link USB Protocol manual. I don't know what parameters it sends or what data it receives. In addition, there are plenty of commands from the Capabilities table that are undocumented: EMU_CMD_RAWTRACE, EMU_CMD_TEST_NET_SPEED, EMU_CMD_INDICATORS, EMU_CMD_REGISTER, EMU_CMD_FILE_IO, EMU_CMD_UPDATE_FIRMWARE_EX, EMU_CMD_WRITE_DCC_EX, EMU_CMD_SWO, and EMU_CMD_READ_DCC. Regarding OpenOCD's J-Link initialiation sequence, I was going to start trying some things out, changing the order of some commands to make it more like Segger's, adding some of the missing ones (like EMU_CMD_GET_COUNTERS; Segger uses it, but I don't think OpenOCD does). I also noticed that where the usb_bulk_reads start to fail is when we start to issue EMU_CMD_HW_JTAG3; from Xiaofan's log above: Debug: 277 507 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 278 510 jlink.c:1654 jlink_debug_buffer(): 0000 cf 00 07 00 7f 00 Debug: 279 511 jlink.c:1654 jlink_debug_buffer(): 0000 7f Debug: 280 514 jlink.c:1654 jlink_debug_buffer(): 0000 00 Debug: 281 514 core.c:1435 jtag_init_inner(): Init JTAG chain Debug: 282 514 core.c:329 jtag_call_event_callbacks(): jtag event: TAP reset Debug: 283 515 jlink.c:1654 jlink_debug_buffer(): 0000 cf 00 07 00 7f 00 Error: 284 518 jlink.c:1504 jlink_usb_message(): usb_bulk_read failed (requested=1, result=0) Error: 285 518 jlink.c:1367 jlink_tap_execute(): jlink_tap_execute, wrong result -107 (expected 1) Odd that the command succeeds, but sending the very same command again fails. I had a hunch that perhaps it's a data length thing in the V8 firmware. All of Segger's EMU_CMD_HW_JTAG3 commands are on the order of 194 bytes long, and we are sending command sequences that are less than 8 bits. There's already some funky behavior noted in the code for when J-Link returns an extra NULL when the incoming message size is a multiple of 64. It wouldn't be unprecedented, but I haven't investigated it yet. Well, that's a day's work for me. ~Eric _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
