*NOTE* - I have broken this item (jtag.h state changes) out as a seperate subject item so it can be tracked a bit better (I hope anyway)
duane> 2) jtag/jtag.h. changing state numbers concerns me - but i see jeff> I chalk this narrow window to being normal for a new part. I don't know yet. That's really just a "well known rev4 arm chip". Sure, it is a new zigbee wireless part from FreeScale - but "the arm part" has been around for quite some time. The ARM7TDMI TRM r4p1, if understand arm nomenclature, means "rev 4 - product #1" - has a copyright date of 2001 (1st release, maintenance updates in 2001 and 2004). I doubt the "arm part has changed any" - I could be wrong. My hunch is far more *THUMB* problems then dongle problems. peter> 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. Hmm yes, I remember seeing that too.. peter> 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. rick> [snip/out of context] Every single adapter OpenOCD supports is just fed a stream of bytes indicating the pin states for the next cycle. [snip] Ignoring "what the dongle driver code wants or needs" - what rick says seems like "the right abstract/architectural thing to do" and that should be the design principle we use, nothing less. Dongles need to do what they are told. -Duane. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
