On Fri, Aug 12, 2011 at 12:45 PM, Xiaofan Chen <xiaof...@gmail.com> wrote: > On Sat, Aug 13, 2011 at 12:02 AM, Eric Wetzel <thewet...@gmail.com> wrote: >> I'm going to try to use the Linux software from Segger with the >> kernel's usbmon to capture some commands and see what Segger's doing >> that we're not. (I've never done any of that before, so I don't expect >> good results). > > I think this may be a good method for now -- reverse engineering. > > On the Segger J-Link Linux utility side, you can use usbmon. On > the OpenOCD Linux side, you can use usbmon as well but you > may want to use the "--enable-verbose-usb-comms" build option > which enables verbose USB communication messages for > USB communication debugging. > > Actually I think a easier way is now that you know 4.14g and > lower firmware versions work whereas 4.14h and higher version > firmware versions do not work. So a debug capture from OpenOCD > may be already good enough to pinpoint the problem > (with the "--enable-verbose-usb-comms" build option). > > An example from Spen last time. You can see that thread helped. > http://lists.berlios.de/pipermail/openocd-development/2009-May/007464.html > > At that time, a lot of work were done to help bring J-Link to > better working status. And it worked much better with Gary's patches > including the patches in this thread. > http://lists.berlios.de/pipermail/openocd-development/2009-July/009397.html > > So hopefully more people will jump in this time to fix this V8 issue. :-) >
Alright, I didn't get around to trying your method yet; I've been capturing things from Segger's J-Link Linux program. Here's what I found. Segger's program sends two commands that are undocumented by the J-Link USB Protocol Reference Manual. The first is 0xE6, which returns 256 bytes of data. The first four bytes returned are the serial number of my unit, and the next row, starting from byte 16, is a null-terminated string of the OEM's name (in my case 'IAR'). The next undocumented command is 0x09. It seems to consist of 14 bytes and returns 76 bytes (but for some reason, my usbmon log is being truncated to just 64 bytes). Neither the command nor the response seem to contain ASCII strings. For my test cases, I ran the J-Link program, waited for it to stabilize, then exitted. I tested conditions like the first execution after plugging in the J-Link and successive executions, and having a target connected or not. Here are the forms of the 0x09 commands (responses not included): jlink-trace.txt: 0964a20c 00000000 00000000 0000 jlink-trace.txt: 0964a20c 00000000 00000000 0300 jlink-trace.txt: 0964a20c 00000000 00000000 0300 jlink-trace.txt: 0965a20c 00000000 00000000 0300 segger-after-plug-no-target.txt: 0964850e 00000000 00000000 0000 segger-after-plug-no-target.txt: 0964850e 00000000 00000000 0200 segger-after-plug-no-target.txt: 0965850e 00000000 00000000 0200 segger-after-plug-target.txt: 0964890e 00000000 00000000 0000 segger-after-plug-target.txt: 0964890e 00000000 00000000 0300 segger-after-plug-target.txt: 0964890e 00000000 00000000 0300 segger-after-plug-target.txt: 0965890e 00000000 00000000 0300 segger-first-plug-no-target.txt: 09647f0e 00000000 00000000 0000 segger-first-plug-no-target.txt: 09647f0e 00000000 00000000 0100 segger-first-plug-no-target.txt: 09657f0e 00000000 00000000 0100 segger-first-plug-target.txt: 0964970e 00000000 00000000 0000 segger-first-plug-target.txt: 0964970e 00000000 00000000 0100 segger-first-plug-target.txt: 0964970e 00000000 00000000 0100 segger-first-plug-target.txt: 0965970e 00000000 00000000 0100 Within the context of a regular initialization, here is the sequence of commands: de2be100 3371054452 S Bo:2:005:2 -115 1 = 01 // EMU_CMD_VERSION de2be100 3371057679 S Bo:2:005:2 -115 1 = 01 // EMU_CMD_VERSION de2be100 3371060740 S Bo:2:005:2 -115 1 = 01 // EMU_CMD_VERSION de2be100 3371063805 S Bo:2:005:2 -115 1 = e8 // EMU_CMD_GET_CAPS de2be100 3371065738 S Bo:2:005:2 -115 1 = ed // EMU_CMD_GET_CAPS_EX de2be100 3371067748 S Bo:2:005:2 -115 1 = 01 // EMU_CMD_VERSION de2be100 3371070732 S Bo:2:005:2 -115 1 = e6 // ?? EMU_CMD_VENDOR_INFO de2be100 3371072735 S Bo:2:005:2 -115 1 = f2 // EMU_CMD_READ_CONFIG de2be100 3371076367 S Bo:2:005:2 -115 1 = f0 // EMU_CMD_GET_HW_VERSION de2be100 3371077864 S Bo:2:005:2 -115 14 = 0964970e 00000000 00000000 0000 // ??? de2be100 3371079765 S Bo:2:005:2 -115 14 = 0964970e 00000000 00000000 0100 // ??? de2be100 3371081737 S Bo:2:005:2 -115 2 = c7ff // EMU_CMD_SELECT_IF de2be100 3371083676 S Bo:2:005:2 -115 2 = c700 // EMU_CMD_SELECT_IF de2be100 3371085742 S Bo:2:005:2 -115 1 = dd // EMU_CMD_HW_RESET1 de2be100 3371086703 S Bo:2:005:2 -115 1 = df // EMU_CMD_HW_TRST1 de2be100 3371087669 S Bo:2:005:2 -115 3 = 050400 // EMU_CMD_SET_SPEED de2be100 3371088680 S Bo:2:005:2 -115 1 = c0 // EMU_CMD_GET_SPEEDS de2be100 3371090759 S Bo:2:005:2 -115 3 = 050400 // EMU_CMD_SET_SPEED de2be100 3371092973 S Bo:2:005:2 -115 1 = 07 // EMU_CMD_GET_STATE de2be100 3371094889 S Bo:2:005:2 -115 3 = 056400 // EMU_CMD_SET_SPEED de2be100 3371095853 S Bo:2:005:2 -115 2 = c7ff // EMU_CMD_SELECT_IF de2be100 3371097826 S Bo:2:005:2 -115 5 = c2020000 00 // EMU_CMD_GET_COUNTERS de2be100 3371099987 S Bo:2:005:2 -115 1 = 07 // EMU_CMD_GET_STATE de2be100 3371101756 S Bo:2:005:2 -115 194 = cf00f802 ffffffff ffffff3c e7df0000 00000000 00000000 00000000 00000000 // EMU_CMD_HW_JTAG3 I haven't comapred this sequence against OpenOCD's J-Link initialization sequence, but I wager that we do not read the version string 3 times in a row, so there are some differences. You'll notice that there are two 0x09 commands right in the middle. After the end of this log, all the other commands are EMU_CMD_HW_JTAG3 until I exit. On exit, there is a little bit of clean up, which includes two more 0x09 commands. Here are a couple responses, though, as I mentioned, I think they're being truncated because usbmon reports that they're returning 76 bytes, but there are only 32 there. segger-first-plug-target cmd: 0964970e 00000000 00000000 0000 rsp: 01000400 10000400 970e0000 00000000 00000100 78400000 00000000 00000000 cmd: 0964970e 00000000 00000000 0100 rsp: 01000400 10000400 970e0000 00000000 00000100 79400000 00000000 00000000 If anybody has a contact at Segger, could you ask them to update their documentation? ~Eric _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
