From: Andrey G. <and...@e-...> - 2015-04-06 16:30:44
Attachments:
libusb-bulk-trace.txt
|
Dear openocd users and developers, I'd like to know details about how to add a new target for openocd. How difficult is to add some very basic support like run/halt target, then read/write embedded RAM memory? Are these jtag commands common or proprietary? For now I can snoop usb communication with custom gdb python script as in the attached file. For example, here the clk speed is set to 1MHz: write 04 : 86 1d 00 87 But is there any program/script to to decode other jtag messages? Thanks, Andrey |
From: Paul F. <fer...@gm...> - 2015-04-06 17:18:18
|
Hello, On Mon, Apr 06, 2015 at 06:04:46PM +0200, Andrey Gursky wrote: > I'd like to know details about how to add a new target for openocd. > How difficult is to add some very basic support like run/halt target, > then read/write embedded RAM memory? Are these jtag commands common or > proprietary? When JTAG is used for debugging, it's just a transport for a bunch of vendor-specific commands. Some vendors document those, some do not. > But is there any program/script to to decode other jtag messages? Here, the first thing you'll probably need is some parser to get the actual low-level JTAG sequences from your usb dumps by extracting the data from MPSSE protocol. Then you'll likely want some utility (not sure if one exists) to translate that to IRSCAN, DRSCAN higher level description (please refer to any document that has the JTAG state machine diagram to understand what I'm talking about here). And then you can start reversing by trying to understand what specific vendor instructions do, what they expect in the data register etc. This might get quite complicated, depending on the complexity of the specific target's OCD module. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Andreas F. <afa...@su...> - 2015-04-09 17:58:09
|
Hi, Am 06.04.2015 um 19:18 schrieb Paul Fertser: > On Mon, Apr 06, 2015 at 06:04:46PM +0200, Andrey Gursky wrote: >> I'd like to know details about how to add a new target for openocd. >> How difficult is to add some very basic support like run/halt target, >> then read/write embedded RAM memory? Are these jtag commands common or >> proprietary? > > When JTAG is used for debugging, it's just a transport for a bunch of > vendor-specific commands. Some vendors document those, some do not. > >> But is there any program/script to to decode other jtag messages? > > Here, the first thing you'll probably need is some parser to get the > actual low-level JTAG sequences from your usb dumps by extracting the > data from MPSSE protocol. Then you'll likely want some utility (not > sure if one exists) to translate that to IRSCAN, DRSCAN higher level > description (please refer to any document that has the JTAG state > machine diagram to understand what I'm talking about here). And then > you can start reversing by trying to understand what specific vendor > instructions do, what they expect in the data register etc. This might > get quite complicated, depending on the complexity of the specific > target's OCD module. Isn't that adapter already supported for the tms570? In that case only configs for tms320 target and board would be needed. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) |
From: Paul F. <fer...@gm...> - 2015-04-09 18:16:16
|
On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: > Isn't that adapter already supported for the tms570? In that case only > configs for tms320 target and board would be needed. TMS320 is a totally different CPU architecture. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Andreas F. <afa...@su...> - 2015-04-10 08:22:49
|
Am 09.04.2015 um 20:16 schrieb Paul Fertser: > On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: >> Isn't that adapter already supported for the tms570? In that case only >> configs for tms320 target and board would be needed. > > TMS320 is a totally different CPU architecture. I know. What I was suggesting is that looking at USB traces (Andrey's mail) may be a layer too low, when we already know that it's an FTDI based adapter and that we do have a JTAG driver for that interface. That doesn't help with TI's complicated ICE-pick TAP setups, of course, nor with instruction-set support, for which some C code will be needed as well. But even without support for AArch64, I've successfully been able to connect to boards on JTAG level, so I expect the same for C55x. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) |
From: Paul F. <fer...@gm...> - 2015-04-10 08:25:25
|
On Fri, Apr 10, 2015 at 10:22:39AM +0200, Andreas Färber wrote: > Am 09.04.2015 um 20:16 schrieb Paul Fertser: > > On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: > >> Isn't that adapter already supported for the tms570? In that case only > >> configs for tms320 target and board would be needed. > > > > TMS320 is a totally different CPU architecture. > > I know. What I was suggesting is that looking at USB traces (Andrey's > mail) may be a layer too low, when we already know that it's an FTDI > based adapter and that we do have a JTAG driver for that interface. To RE the protocol one would need to sniff the communication of the vendor software with the target, right? The vendor software is unlikely to expose JTAG-level commands anywhere easily accessible, so probably using usbmon to capture usb-level trace would be needed. Anyway, the point is moot since the OP is not responding at all. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Andrey G. <and...@e-...> - 2015-04-11 17:16:31
|
Andreas, Paul, 2015-04-10 10:25 GMT+02:00, Paul Fertser <fer...@gm...>: > On Fri, Apr 10, 2015 at 10:22:39AM +0200, Andreas Färber wrote: >> Am 09.04.2015 um 20:16 schrieb Paul Fertser: >> > On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: >> >> Isn't that adapter already supported for the tms570? In that case only >> >> configs for tms320 target and board would be needed. >> > >> > TMS320 is a totally different CPU architecture. >> >> I know. What I was suggesting is that looking at USB traces (Andrey's >> mail) may be a layer too low, when we already know that it's an FTDI >> based adapter and that we do have a JTAG driver for that interface. > > To RE the protocol one would need to sniff the communication of the > vendor software with the target, right? The vendor software is > unlikely to expose JTAG-level commands anywhere easily accessible, so > probably using usbmon to capture usb-level trace would be > needed. Anyway, the point is moot since the OP is not responding at > all. > Sorry for silence, but I'm still there :) I could sniff usb communication even without usbmon since the software uses libusb 0.1, statically compiled in (BTW, no LGPL license has been supplied) and libftdi either (but I can't figure out what version). But now I'd really need MPSSE decoder and I can't really believe there is no such. E.g. I don't see in MPSSE-related ftdi docs, that usb control channel can be used to set up e.g. latency, but it is there in the libftdi. So the first task using OpenOCD would be to obtain/check tap id. I believe it is possible also without proprietary commands? Possibly this is already contained in the attached previously dump? Regards, Andrey |
From: Andreas F. <afa...@su...> - 2015-04-11 17:35:22
|
Hi Andrey, Am 11.04.2015 um 19:16 schrieb Andrey Gursky: > 2015-04-10 10:25 GMT+02:00, Paul Fertser <fer...@gm...>: >> On Fri, Apr 10, 2015 at 10:22:39AM +0200, Andreas Färber wrote: >>> Am 09.04.2015 um 20:16 schrieb Paul Fertser: >>>> On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: >>>>> Isn't that adapter already supported for the tms570? In that case only >>>>> configs for tms320 target and board would be needed. >>>> >>>> TMS320 is a totally different CPU architecture. >>> >>> I know. What I was suggesting is that looking at USB traces (Andrey's >>> mail) may be a layer too low, when we already know that it's an FTDI >>> based adapter and that we do have a JTAG driver for that interface. >> >> To RE the protocol one would need to sniff the communication of the >> vendor software with the target, right? The vendor software is >> unlikely to expose JTAG-level commands anywhere easily accessible, so >> probably using usbmon to capture usb-level trace would be >> needed. [...] [...] > I could sniff usb communication even without usbmon since the software > uses libusb 0.1, statically compiled in (BTW, no LGPL license has been > supplied) and libftdi either (but I can't figure out what version). > But now I'd really need MPSSE decoder and I can't really believe there > is no such. E.g. I don't see in MPSSE-related ftdi docs, that usb > control channel can be used to set up e.g. latency, but it is there in > the libftdi. > > So the first task using OpenOCD would be to obtain/check tap id. I > believe it is possible also without proprietary commands? Possibly > this is already contained in the attached previously dump? Saying that there is already xds100v2 interface support, I was suggesting to simply run: openocd -f interface/ftdi/xds100v2.cfg -c "adapter_khz 500" -c "init; ftdi_set_signal PWR_RST 1; jtag arp_init" (frequency a placeholder; for the latter commands cf. xds100v2.cfg) Then I would hope that after a few seconds any auto-detected TAPIDs would show up. In the case of tms570 and other TI chipsets, the one showing up by default is not the CPU TAPID though and specific actions need to be taken to access it that are hopefully outlined in a TRM. Cheers, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) |
From: Andrey G. <and...@e-...> - 2015-04-16 18:32:33
Attachments:
error-cmd.txt
error-cmd-ft2232.txt
|
Andreas, 2015-04-11 19:35 GMT+02:00, Andreas Färber <afa...@su...>: > Hi Andrey, > > Am 11.04.2015 um 19:16 schrieb Andrey Gursky: >> 2015-04-10 10:25 GMT+02:00, Paul Fertser <fer...@gm...>: >>> On Fri, Apr 10, 2015 at 10:22:39AM +0200, Andreas Färber wrote: >>>> Am 09.04.2015 um 20:16 schrieb Paul Fertser: >>>>> On Thu, Apr 09, 2015 at 07:58:00PM +0200, Andreas Färber wrote: >>>>>> Isn't that adapter already supported for the tms570? In that case >>>>>> only >>>>>> configs for tms320 target and board would be needed. >>>>> >>>>> TMS320 is a totally different CPU architecture. >>>> >>>> I know. What I was suggesting is that looking at USB traces (Andrey's >>>> mail) may be a layer too low, when we already know that it's an FTDI >>>> based adapter and that we do have a JTAG driver for that interface. >>> >>> To RE the protocol one would need to sniff the communication of the >>> vendor software with the target, right? The vendor software is >>> unlikely to expose JTAG-level commands anywhere easily accessible, so >>> probably using usbmon to capture usb-level trace would be >>> needed. [...] > [...] >> I could sniff usb communication even without usbmon since the software >> uses libusb 0.1, statically compiled in (BTW, no LGPL license has been >> supplied) and libftdi either (but I can't figure out what version). >> But now I'd really need MPSSE decoder and I can't really believe there >> is no such. E.g. I don't see in MPSSE-related ftdi docs, that usb >> control channel can be used to set up e.g. latency, but it is there in >> the libftdi. >> >> So the first task using OpenOCD would be to obtain/check tap id. I >> believe it is possible also without proprietary commands? Possibly >> this is already contained in the attached previously dump? > > Saying that there is already xds100v2 interface support, I was > suggesting to simply run: > > openocd -f interface/ftdi/xds100v2.cfg -c "adapter_khz 500" -c "init; > ftdi_set_signal PWR_RST 1; jtag arp_init" > > (frequency a placeholder; for the latter commands cf. xds100v2.cfg) > > Then I would hope that after a few seconds any auto-detected TAPIDs > would show up. In the case of tms570 and other TI chipsets, the one > showing up by default is not the CPU TAPID though and specific actions > need to be taken to access it that are hopefully outlined in a TRM. > Since ft2232 is deprecated, I'm using custom xds100v2.cfg: interface ftdi ftdi_device_desc "Texas Instruments Inc.XDS100 Ver 2.0" ftdi_layout_init 0x0000 0x001b ftdi_vid_pid 0x0403 0xa6d0 but I haven't yet checked ftdi_layout_init and there is no explicit reset control. The output is in error-cmd.txt I compiled also the deprecated ft2232_libftdi. It gains a bit more (error-cmd-ft2232.txt). Regards, Andrey |
From: Andrey G. <and...@e-...> - 2015-04-11 17:08:43
|
Paul, 2015-04-06 19:18 GMT+02:00, Paul Fertser <fer...@gm...>: > Hello, > > On Mon, Apr 06, 2015 at 06:04:46PM +0200, Andrey Gursky wrote: >> I'd like to know details about how to add a new target for openocd. >> How difficult is to add some very basic support like run/halt target, >> then read/write embedded RAM memory? Are these jtag commands common or >> proprietary? > > When JTAG is used for debugging, it's just a transport for a bunch of > vendor-specific commands. Some vendors document those, some do not. Do you have some references, how typical commands look like? And why irlen can be in such big range from 6 to 38? >> But is there any program/script to to decode other jtag messages? > > Here, the first thing you'll probably need is some parser to get the > actual low-level JTAG sequences from your usb dumps by extracting the > data from MPSSE protocol. Then you'll likely want some utility (not > sure if one exists) to translate that to IRSCAN, DRSCAN higher level > description (please refer to any document that has the JTAG state > machine diagram to understand what I'm talking about here). And then > you can start reversing by trying to understand what specific vendor > instructions do, what they expect in the data register etc. This might > get quite complicated, depending on the complexity of the specific > target's OCD module. > > HTH Thanks. But it sounds like no jtag tools are here? OpenOCD could be programmed without these at all because all has been done only according to available documentation? Maybe you could advice me a better place to ask about jtag related open-source development, if OpenOCD-list is not a such place? Regards, Andrey |
From: Paul F. <fer...@gm...> - 2015-04-11 18:55:27
|
Hey Andrey, On Sat, Apr 11, 2015 at 07:08:36PM +0200, Andrey Gursky wrote: > 2015-04-06 19:18 GMT+02:00, Paul Fertser <fer...@gm...>: > > On Mon, Apr 06, 2015 at 06:04:46PM +0200, Andrey Gursky wrote: > >> I'd like to know details about how to add a new target for openocd. > >> How difficult is to add some very basic support like run/halt target, > >> then read/write embedded RAM memory? Are these jtag commands common or > >> proprietary? > > > > When JTAG is used for debugging, it's just a transport for a bunch of > > vendor-specific commands. Some vendors document those, some do not. > > Do you have some references, how typical commands look like? And why > irlen can be in such big range from 6 to 38? I suggest you search for file named IHI0031A_ARM_debug_interface_v5.pdf , it's the official ARM reference for their debug interface. Another option is to look for some EJTAG (MIPS) documents. > Thanks. But it sounds like no jtag tools are here? OpenOCD could be > programmed without these at all because all has been done only > according to available documentation? Maybe you could advice me a > better place to ask about jtag related open-source development, if > OpenOCD-list is not a such place? AFAICT, yes, most of the target support in OpenOCD is done by following reference documents and not reversing. I'm unaware of any other place, unfortunately, probably UrJTAG ML might help. Another possible opportunity to investigating the original code is to try to find irscan and drscan functions in the vendor binaries (it's somewhat likely that they have functions like that), place breakpoints there and log all the invocations. HTH -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Andrey G. <and...@e-...> - 2015-04-16 18:42:30
|
Paul, 2015-04-11 20:55 GMT+02:00, Paul Fertser <fer...@gm...>: > Hey Andrey, > > On Sat, Apr 11, 2015 at 07:08:36PM +0200, Andrey Gursky wrote: >> 2015-04-06 19:18 GMT+02:00, Paul Fertser <fer...@gm...>: >> > On Mon, Apr 06, 2015 at 06:04:46PM +0200, Andrey Gursky wrote: >> >> I'd like to know details about how to add a new target for openocd. >> >> How difficult is to add some very basic support like run/halt target, >> >> then read/write embedded RAM memory? Are these jtag commands common or >> >> proprietary? >> > >> > When JTAG is used for debugging, it's just a transport for a bunch of >> > vendor-specific commands. Some vendors document those, some do not. >> >> Do you have some references, how typical commands look like? And why >> irlen can be in such big range from 6 to 38? > > I suggest you search for file named > IHI0031A_ARM_debug_interface_v5.pdf , it's the official ARM reference > for their debug interface. Another option is to look for some EJTAG > (MIPS) documents. > >> Thanks. But it sounds like no jtag tools are here? OpenOCD could be >> programmed without these at all because all has been done only >> according to available documentation? Maybe you could advice me a >> better place to ask about jtag related open-source development, if >> OpenOCD-list is not a such place? > > AFAICT, yes, most of the target support in OpenOCD is done by > following reference documents and not reversing. I'm unaware of any > other place, unfortunately, probably UrJTAG ML might help. Another > possible opportunity to investigating the original code is to try to > find irscan and drscan functions in the vendor binaries (it's somewhat > likely that they have functions like that), place breakpoints there > and log all the invocations. Thanks for references. I looked for *scan and found: ... --> PTI_IceScanIr() --> ... --> jsc_ScanBoth16() --> FtdiReadBuffer() / FtdiWriteBuffer() --> ... --> libftdi --> libusb. I can't see DR-related things. According to [1], obtaining a TAPID is straightforward thing and IDCODE instruction can be scaned out either. But why doesn't it work in my case (see former mail to Andreas)? [1] http://events.ccc.de/congress/2009/Fahrplan/attachments/1435_JTAG.pdf Regards, Andrey |
From: Andreas F. <afa...@su...> - 2015-04-16 18:46:43
|
Am 16.04.2015 um 20:32 schrieb Andrey Gursky: > 2015-04-11 19:35 GMT+02:00, Andreas Färber <afa...@su...>: >> [...] I was >> suggesting to simply run: >> >> openocd -f interface/ftdi/xds100v2.cfg -c "adapter_khz 500" -c "init; >> ftdi_set_signal PWR_RST 1; jtag arp_init" >> >> (frequency a placeholder; for the latter commands cf. xds100v2.cfg) >> >> Then I would hope that after a few seconds any auto-detected TAPIDs >> would show up. In the case of tms570 and other TI chipsets, the one >> showing up by default is not the CPU TAPID though and specific actions >> need to be taken to access it that are hopefully outlined in a TRM. >> > > Since ft2232 is deprecated, I'm using custom xds100v2.cfg: Sounds like you're confusing interface/ftdi/xds100v2.cfg with interface/xds100v2.cfg? I did point to the new one above. Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton; HRB 21284 (AG Nürnberg) |
From: Andrey G. <and...@e-...> - 2015-04-17 16:19:00
Attachments:
output.txt
|
2015-04-16 20:46 GMT+02:00, Andreas Färber <afa...@su...>: > Am 16.04.2015 um 20:32 schrieb Andrey Gursky: >> 2015-04-11 19:35 GMT+02:00, Andreas Färber <afa...@su...>: >>> [...] I was >>> suggesting to simply run: >>> >>> openocd -f interface/ftdi/xds100v2.cfg -c "adapter_khz 500" -c "init; >>> ftdi_set_signal PWR_RST 1; jtag arp_init" >>> >>> (frequency a placeholder; for the latter commands cf. xds100v2.cfg) >>> >>> Then I would hope that after a few seconds any auto-detected TAPIDs >>> would show up. In the case of tms570 and other TI chipsets, the one >>> showing up by default is not the CPU TAPID though and specific actions >>> need to be taken to access it that are hopefully outlined in a TRM. >>> >> >> Since ft2232 is deprecated, I'm using custom xds100v2.cfg: > > Sounds like you're confusing interface/ftdi/xds100v2.cfg with > interface/xds100v2.cfg? I did point to the new one above. > Andreas, you're right, thanks for catching it. I believe these cfg doubles might become the most popular newbie confusion after fix [1]. Maybe ft2232-related cfgs could be moved to the appropriate interfaces/ft2232/ folder? I've attached output of openocd, but it still can't find any TAP. BTW, xds100v2.cfg mentions: # Detailed documentation is available only as CPLD verilog source code # to the registered TI users. but on my board there is no CPLD, while the ftdi chip is connected directly to the DSP, excepting EMU0/1 pins, which are pull-up high on the DSP side. Yet another question is why openocd appears to hang? I mean if it acts as a server, shouldn't it drop as a last message some info, how to access it (like: serving as ... on port ...)? [1] http://sourceforge.net/p/openocd/code/ci/refs/changes/51/2551/7/~/ Regards, Andrey |
From: Andrey G. <and...@e-...> - 2016-06-04 02:42:15
|
Hi, On Thu, 16 Apr 2015 20:46:33 +0200 Andreas Färber <afa...@su...> wrote: > Am 16.04.2015 um 20:32 schrieb Andrey Gursky: > > 2015-04-11 19:35 GMT+02:00, Andreas Färber <afa...@su...>: > >> [...] I was > >> suggesting to simply run: > >> > >> openocd -f interface/ftdi/xds100v2.cfg -c "adapter_khz 500" -c "init; > >> ftdi_set_signal PWR_RST 1; jtag arp_init" > >> > >> (frequency a placeholder; for the latter commands cf. xds100v2.cfg) > >> > >> Then I would hope that after a few seconds any auto-detected TAPIDs > >> would show up. In the case of tms570 and other TI chipsets, the one > >> showing up by default is not the CPU TAPID though and specific actions > >> need to be taken to access it that are hopefully outlined in a TRM. > >> My last observation a year ago was: > I can't see DR-related things. Now I found a hint, that the used JTAG protocol is called IceMaker (a next generation after a "classic" one, but before ICEpick) and it appears it doesn't use DR at all. Thus I'd need to see the data scanned out on IR. Is this possible? Moreover though the IR len is 38 (6 bit code and 32 bit parameter), the data is padded with 16 bits. It means, I should specify IR len as 54. I noticed on http://openocd.org/doc/html/JTAG-Commands.html ----- irscan: Note: OpenOCD currently supports only a single field for instruction register values, unlike data register values. For TAPs where the instruction register length is more than 32 bits, portable scripts currently must issue only BYPASS instructions. ----- Thus the question: does openocd support "huge IR len" or not at all? Here how it looks: ----- > scan_chain TapName Enabled IdCode Expected IrLen IrCap IrMask -- ------------------- -------- ---------- ---------- ----- ----- ------ 0 auto0.tap Y 0x00000000 0x00000000 7 0x01 0x03 1 my.tap Y 0x00000000 0x00000000 54 0x01 0x03 > irscan my.tap 0x3FFFFFFFFFFFFF Debug: 712 1865665 command.c:143 script_debug(): command - ocd_command ocd_command type ocd_irscan my.tap 0x3FFFFFFFFFFFFF Debug: 713 1865666 command.c:143 script_debug(): command - irscan ocd_irscan my.tap 0x3FFFFFFFFFFFFF Debug: 715 1865666 ftdi.c:408 ftdi_execute_scan(): IRSCAN type:2 Debug: 716 1865666 ftdi.c:237 move_to_state(): start=RUN/IDLE goal=IRSHIFT Debug: 717 1865666 ftdi.c:241 move_to_state(): tap_set_state(DRSELECT) Debug: 718 1865666 ftdi.c:241 move_to_state(): tap_set_state(IRSELECT) Debug: 719 1865666 ftdi.c:241 move_to_state(): tap_set_state(IRCAPTURE) Debug: 720 1865666 ftdi.c:241 move_to_state(): tap_set_state(IRSHIFT) Debug: 721 1865666 mpsse.c:573 mpsse_clock_tms_cs(): out 4 bits, tdi=0 Debug: 722 1865666 mpsse.c:455 buffer_write_byte(): 4b Debug: 723 1865666 mpsse.c:455 buffer_write_byte(): 03 Debug: 724 1865666 mpsse.c:455 buffer_write_byte(): 03 Debug: 725 1865666 ftdi.c:442 ftdi_execute_scan(): out field 0/2 7 bits Debug: 726 1865666 mpsse.c:497 mpsse_clock_data(): out 7 bits Debug: 727 1865666 mpsse.c:455 buffer_write_byte(): 1b Debug: 728 1865666 mpsse.c:455 buffer_write_byte(): 06 Debug: 729 1865666 mpsse.c:463 buffer_write(): 7 bits Debug: 730 1865666 ftdi.c:442 ftdi_execute_scan(): out field 1/2 54 bits Debug: 731 1865666 mpsse.c:497 mpsse_clock_data(): out 53 bits Debug: 732 1865666 mpsse.c:455 buffer_write_byte(): 19 Debug: 733 1865666 mpsse.c:455 buffer_write_byte(): 05 Debug: 734 1865666 mpsse.c:455 buffer_write_byte(): 00 Debug: 735 1865666 mpsse.c:463 buffer_write(): 48 bits Debug: 736 1865666 mpsse.c:455 buffer_write_byte(): 1b Debug: 737 1865666 mpsse.c:455 buffer_write_byte(): 04 Debug: 738 1865666 mpsse.c:463 buffer_write(): 5 bits Debug: 739 1865666 mpsse.c:573 mpsse_clock_tms_cs(): out 1 bits, tdi=1 Debug: 740 1865666 mpsse.c:455 buffer_write_byte(): 4b Debug: 741 1865666 mpsse.c:455 buffer_write_byte(): 00 Debug: 742 1865666 mpsse.c:455 buffer_write_byte(): 81 Debug: 743 1865666 ftdi.c:466 ftdi_execute_scan(): tap_set_state(IREXIT1) Debug: 744 1865666 mpsse.c:573 mpsse_clock_tms_cs(): out 1 bits, tdi=1 Debug: 745 1865666 mpsse.c:455 buffer_write_byte(): 4b Debug: 746 1865666 mpsse.c:455 buffer_write_byte(): 00 Debug: 747 1865666 mpsse.c:455 buffer_write_byte(): 80 Debug: 748 1865666 ftdi.c:473 ftdi_execute_scan(): tap_set_state(IRPAUSE) Debug: 749 1865666 ftdi.c:237 move_to_state(): start=IRPAUSE goal=RUN/IDLE Debug: 750 1865666 ftdi.c:241 move_to_state(): tap_set_state(IREXIT2) Debug: 751 1865666 ftdi.c:241 move_to_state(): tap_set_state(IRUPDATE) Debug: 752 1865666 ftdi.c:241 move_to_state(): tap_set_state(RUN/IDLE) Debug: 753 1865666 mpsse.c:573 mpsse_clock_tms_cs(): out 3 bits, tdi=0 Debug: 754 1865666 mpsse.c:455 buffer_write_byte(): 4b Debug: 755 1865666 mpsse.c:455 buffer_write_byte(): 02 Debug: 756 1865666 mpsse.c:455 buffer_write_byte(): 03 Debug: 757 1865666 ftdi.c:489 ftdi_execute_scan(): IR scan, 61 bits, end in RUN/IDLE Debug: 758 1865666 mpsse.c:855 mpsse_flush(): write 27, read 0 Debug: 759 1865666 mpsse.c:829 write_cb(): transferred 27 of 27 Debug: 760 1865666 mpsse.c:831 write_cb(): 4b 03 03 1b 06 7f 19 05 00 ff ff ff ff ff ff 1b 04 ff 4b 00 81 4b 00 80 4b 02 03 ----- Thanks, Andrey |