Duane Ellis wrote:
> 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 agree.
> I'd like some comments, second opinion, etc, ie: Am I correct? Or am I
> missing something?
>
The remainder of your email references a patch that was never accepted
into the tree. And I do not think it should be accepted, at least as is.
If this difference in behavior exists in the current HEAD, please
correct me soon, because I am working on the ft232 stuff starting
today. But I think we have to assume that I am only interested in what
is in the HEAD at this moment.
Dick
> ====
>
> 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
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
