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. Gary On 8/13/11 7:59 AM, "Eric Wetzel" <thewet...@gmail.com> wrote: > 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 _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
