On Sat, 7 Mar 2009, Peter Denison wrote:
> This write to DCSR should then let the target run (the debug code just
> loaded into the cache), and then the next read is from TX, which the
> debug handler should have written to. However, the 3 guard bits in
> fields[0].in_value[3] should be 010 or 011 (from the hardware), and they
> aren't, which is why I think it's an extra bit clocked somewhere.
I've been looking more closely at the TAP state transtition table in
src/jtag/jtag.c, in tap_get_tms_path(), and first of all there are some
assumptions I must query:
1) Should a transition from one {DR,IR}SHIFT or {DR,IR}PAUSE to another
always make the transtion through {DR,IR}CAPTURE?
Currently some do and some don't
2) Should a transition into {DR,IR}SHIFT always guarantee to arrive at
that state on the last clock of the fixed 7?
Currently most do, but some don't.
3) At the end of a known number of bits in {DR,IR}SHIFT, are the adapter
codes expected to exit into {DR,IR}EXIT1, or to stay in SHIFT? This
assumption is crucial to the subsequent transitions required to update the
register. Is this up to the adapter specific code to know and compensate
for?
At least one adapter implementation automatically comes out into EXIT1.
Of the 36 transitions in the table, I think that 8 are suspect, and of
those, 2 plain wrong:
DRSHIFT -> DRSHIFT: is 00, depends on answer to 1), but could be 13 or 1D
DRPAUSE -> DRSHIFT: is 20, depends on answer to 1), but could be 13,16,1C
IRSHIFT -> DRSHIFT: is 07, which clocks DR twice, should be 13 or 1D
DRSHIFT -> DRPAUSE: is 01, depends on answer to 1), but could be 17 or 2B
DRSHIFT -> IRSHIFT: is 0F, which clocks IR once, should be 1B
IRSHIFT -> IRSHIFT: is 00, depends on answer to 1), but could be 1B
IRPAUSE -> IRSHIFT: is 20, depends on answer to 1), but could be 1B or 1E
IRSHIFT -> IRPAUSE: is 01, depends on answer to 1), but could be 2F
It's the IRSHIFT->DRSHIFT and vice versa that are definitely wrong.
This may not be a real issue, but it's worth correcting.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
