On Mar 13, 2009, at 2:47 PM, Peter Denison wrote:
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 beagleboard 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 letterof the official spec. I'm not an ARM or JTag expert (yet) but I chalkthis 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.
Does the adapter actually depend on the 7 state transitions or does the driver for that adapter in OpenOCD rely on that. If the former, we have a problem. If the latter, it just means we need to be sure to update the driver. As far as I have been able to discern, every single adapter OpenOCD supports is just fed a stream of bytes indicating the pin states for the next cycle.
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 0210CGood point.Agreed. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
-- Rick Altherr [email protected]"He said he hadn't had a byte in three days. I had a short, so I split it with him."
-- Unsigned
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
