So I'm trying to whack the user guide into shape, and those two
commands leave me a bit puzzled. Ergo, some questions and a few
observations. In no particular order here:
drscan and irscan ... hmm, these seem to require numeric
TAP identifiers, vs the names preferred elsewhere.
==> Worth fixing at some point, yes?
drscan and irscan ... what's the final state if the caller
doesn't specify "-endstate ..."? I hope/expect IDLE.
==> if not specified, worth IMO doing so; random == bad.
drscan and irscan ... as noted in [1] (top of p. 3-6) there
are only six "steady" states, with TMS fixed, where TCK
doesn't start walking through the JTAG state machine.
Of those, the two SHIFT states change register contents,
thus presumably walking through device state machines.
And RESET is all kinds of special case.
Seems to me this adds up to advice that the endstate
should be either IDLE, DRPAUSE, or IRPAUSE. Because
some JTAG adapters will use free running TCK (yes?),
and using non-"steady" states means the TCL code can't
rely on reproducible behavior otherwise...
==> if so, it might be worth rejecting other endstates.
Who knows, maybe there are some bugs hiding there.
drscan ... "drscan 0 16 0x1234 16 0x5678", is this equivalent
to "drscan 0 32 0x12345678"? With the 0x12... bits
going out first, in both cases (not the 0x87... ones)?
drscan ... observation, platforms with 64 bit integers are
going to be able to say "drscan 0 38 "0x123456789A"
but that won't work on most systems. Ergo I'll give
guidance not to use fields of more than 32 bits, to
avoid proliferation of nonportable scripts.
drscan ... can only send bits to one TAP. Presumably
all others must be in bypass? And so the single
bit written to their bypass register is "don't care".
==> probably worth adding code to verify only that
one device is out of bypass, yes?
irscan ... observation, this doesn't seem to accomodate
arbitrary length instructions. (Even if I got
docs for that C55x DSP's JTAG, I couldn't feed it
38-bit instruction words in any portable way.)
==> possibly worth having this share the same code
that drscan uses. For now I'll just warn about
not being able to issue large instructions. This
doesn't seem like a big deal; just worth noting.
irscan ... observation, this supports chatting with multiple
devices (the others seem to get BYPASS). Which
means it's more powerful than DRSCAN, which only
supports one device.
==> again, possibly worth sharing code. I suspect
not; since there's no error checking on lengths for
data registers, it' be too easy to cause problems.
So it'd be good enough to just verify that only one
TAP is out of BYPASS mode during a drscan.
Hmm, and:
tms_sequence ... we plan this to go away by 0.4 at the
latest, yes? (If not 0.3 ...)
I there's any agreement about those "may be ..." comments,
I'll provide a patch with relevant FIXME comments so the
issues don't get lost. (Then maybe fix some.)
That's all for now. :)
- dave
[1] http://focus.ti.com/lit/an/ssya002c/ssya002c.pdf
... there's a "...2d.pdf" too, rev d; you'll see
the page size/format issues if you look.
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
