On Monday 01 June 2009, Øyvind Harboe wrote:
> On Mon, Jun 1, 2009 at 10:09 AM, David Brownell <davi...@pacbell.net> wrote:
> > 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.
>
> :-) I've suggested to retire jtag_add_end_state() which defines
> the default end state...
I've followed *some* of that discussion, but that seems to be
focussed on the innards. For the moment I'm coming at this
problem top-down: what does the TCL-user see? It should be
reproducible and fully predictable, IMO. Questions about how
the C code can unconfuse itself are good, but separable.
In both drscan and irscan commands we see this initialization:
endstate = cmd_queue_end_state;
Which seems as likely to be garbage as anything else. I guess
I'm suggesting it just get initialized to TAP_IDLE. (And will be
submitting a patch to do that, I think.)
> > ==> 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.
>
> DRPAUSE and IRPAUSE are illegal end states for lots
> of good reasons...
The "-endstate" flag seems misnamed. "-nextstate" would
stop implying it's a *terminal* state. For intermediate
states those are perfectly valid ... and are even designed
to be safe places to pause state machines.
The whole point of that flag is to specify some of the
key *intermediate* states. Without specifying them, it's
not possible to do things like "load instruction, then load
the data to which it applies" ... or "load one instruction
and its data, then the next instruction and its data".
At least, not without entering the Run/Idle state ... which
can have undesirable side effects.
Note that the ICEpick/JRC code must use both DRPAUSE and
IRPAUSE in order to work. And the limited public docs
I've found on the topic (OMAP-L137) specify those states
very explicitly.
... all that said, my question stands: does it make
sense to support anything other than IDLE, DRPAUSE, and
IRPAUSE for the current "-endstate" param value? AFAICT
the only way such states would make sense is if the TCL
script somehow knew that the adapter didn't use a free
running JTAG clock. That seems unlikely to be a safe
assumption in the long term.
> w.r.t. irscan/drscan they should be rewritten to use the same
> code + fix the various and sundry headaches that you have
> pointed out. Perhaps post 0.2?
I'd like to fix the "random endstate" issue before 0.2, and
maybe verify for drscan verify that only one TAP is out of
bypass. But for the other points, probably post-0.2 is fine.
> > tms_sequence ... we plan this to go away by 0.4 at the
> > latest, yes? (If not 0.3 ...)
>
> If not before 0.2?
>
> It could be made a debug feature, i.e. if you
> enable JTAG_DEBUG_IO(sp?).
I have no objection to it vanishing completely, so long as
nobody turns up ongoing issues with the current default (short)
transition tables.
I think what I'll do for now is just not document it.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
