On Fri, 13 Mar 2009, Jeff Williams wrote:
El Mar 13, 2009, a las 04:30 , Duane Ellis escribió:
2) jtag/jtag.h. changing state numbers concerns me - but i see
*exactly* why you are doing this.
Perhaps this sort of stuff would have helped earlier with the beagle
board work.
And it looks like a good idea.
I'd like others to comment also.
(*HEY* anybody else reading this?*)
ie: ?DIRK/DICK? I forget who - wrote quite a bit of stuff with an
SVF playback
code to do xilinx stuff. I'd hate to break that...
This is a big factor in the JLink working correctly, because it seems
the MC1322x has a low tolerance for anything not following the letter
of the official spec. I'm not an ARM or JTag expert (yet) but I chalk
this narrow window to being normal for a new part.
I have very serious doubts about this *as it stands* (meaning only that I
want more discussion - I'm not trying to close it down!). Several of the
transitions in there are not correct, particularly the DRSHIFT->DRSHIFT,
and IRSHIFT->IRSHIFT. Yes, a single clock with TMS = 0 will cause the TAP
to stay in xxSHIFT, but it will also clock a bit out of the register,
which is not what we want when doing TAP movement.
There is a note somewhere (I think above the original version of the
table) that says it's the adapter code's job to catch xxSHIFT->xxSHIFT
transitions and treat them differently, but we shouldn't do the wrong
thing anyway.
I have recently posted a patch to fix one of the problems on the JLink
adapter, related to DRSHIFT->DRSHIFT transitions. (likewise I sometimes
wonder if anyone is reading this ;)
There are also adapters (at least one - USBprog) that rely on the fact
that there are exactly 7 state transitions in every tms sequence. This is
not immutable, but it will need coordination and will have to change if
OpenOCD does.
3) the state numbers - could you put a better reference in.
Example: The state numbers are from:
Document: ARM 7TDMI Technical Reference Manual
Revision: R4P1
Section: B.1.2
Arm Document ID Number: DDI 0210C
Good point.
Agreed.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
