All,
I'm working on the patch that Jeff Williams did that updates the way the
TMS path sequences work and have discovered an issue with the FT2232 driver.
Right now, I believe I can show that given the same sets of scan
commands - the ft2232 driver does not follow the same tap sequence that
other dongles follow.
I also see this with my cheap-usb-logic-analyzer.
I believe: Two dongles in theory, if given the same sets of commands,
should generate the same basic tap state sequences.
To do otherwise is a bug.
I'd like some comments, second opinion, etc, ie: Am I correct? Or am I
missing something?
====
The example place is: jtag_init_inner() - which is called when OpenOCD
first starts up.
Which:
(a) calls jtag_add_tlr() [putting all taps in reset]
(b) calls jtag_examine_chain()
(c) then calls jtag_validate_chain()
When jtag_examine_chain() runs, it basically does a DRSCAN of (N*32)
bits to look for TAP IDs.
====
If you compare the generated wave forms and thus the TAP sequence the
JLINK driver uses - vrs the FT2232 sequence, they are different.
I believe what follows is the reason.
====
For JLINK see: jlink.c - line 417, function jlink_scan(), which does this:
(a) if needed move to the IR-SHIFT or DR-SHIFT state (line: 427)
(b) Calls jlink_tap_append_scan() - which always leaves the tap in
"exit1-ir/dr"
(c) The last step @ line 639 transitions to exit1-IR/DR
(d) Then always transitions to the ir/dr-pause state (line: 434)
Hence, all jlink IR/DR scans *always* exit via: SHIFT -> EXIT1 -> PAUSE.
The "bitbang" (parallel ports) seem to do the same as jlink.
I believe others do the same thing.
====
In contrast, the FT2232 driver does something different.
(a) switch() statement @ line 1452 - does an "absurd" check.
ie: If the current scan is > 128K bytes long...
(b) line 1484 - calls ft2232_add_scan() - which
(c) line 600 - moves to IR/DR shift if needed.
(d) line 623 - loops - over large shift sequences
(e) line 673 - deals with the trailing bits.
And at this point - it is different, it only occurs if the transition is
to another state
(f) At line ft2232.c line 737 - is the issue.
The last else{} in the file - calls tap_get_tms_path()
That function returns the TMS sequence to the next state.
In this case, it is to RESET, which is 0x7F
Hence, it is different.
For example - if it was an IR shift, path is IR-SHIFT -> EXIT1 ->
UPDATE-IR without traversing PAUSE-IR, or EXIT2-IR
But it is also different if it was to goto another state, ie: SHIFT-IR
to SHIFT-DR ...
====
Interestingly, the TMS paths - happens to be the same.
ie: If the traversal was: shift-ir -> move to shift-dir ...
The ft2232 would then generate the TMS sequence
1 -> exit1-ir
1 -> update-ir
1 -> select-dr
0 -> capture-dr
0 -> shift-dr
While the jlink (and other bit-bangers) would follow a different path:
Remember: JLINK always ends in PAUSE-IR/DR
thus in this example we are at PAUSE-IR
1 -> exit2-ir
1 -> update-ir
1 -> select-dr
0 -> capture-dr
0 ->shift-dr
An identical 'tms' sequence - however - by completely different state path.
====
I believe this also relates to [ GRR - openocd mailing list archive is
down right now ... can't make a link right now]
See mail from: Dirk Behme - 3/1/2009 - Subject: RE [Openocd-development]
OMAP3-Jtag
dirk> Most probably the issue is with this TMS manipulation
dirk> BUFFER_ADD = tap_get_tms_path( tap_get_state(), tap_get_end_state() ) |
(last_bit << 7);
dirk> in ft2232.c which most probably only works if always 7 clocks
dirk> are done for each state change (?). And this isn't the case
dirk> any more with improved ap_get_tms_path() from Holger.
**END**
--Duane.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
