Re: [Openocd-development] Advanced Reset Process

[David B. <da...@pa...>]

On Saturday 27 June 2009, Duane Ellis wrote:
> Today - the C code *controls* and *drives* the reset sequence.
> 
> I'm suggesting we turn that inside out - and make the TCL code - drive 
> the reset sequence - via commands above.

That's a good direction, I think.  Details TBD, but
certainly getting the current hard-coded SRST/TRST
reset policies from C into Tcl seems essential.

Tcl code would need to be able to query some of the
quirk flags -- srst pulling trst etc -- to figure out
how to diddle SRST and TRST in certain cases.


> There would be a few *default* reset sequences - in tcl... that one 
> could point "proc reset" at.

I think I'd prefer to avoid that particular level of
need-to-rewrite.  But maybe one having that handful of
standard models would remove the need for that, if the
models were sanely factored.  (Initial design task:
come up with that factored handful of models.)

I'm not sure all the current events should be discarded,
for example, and the easiest way to preserve them would
involve less-than-wholesale replacement.


So for example, your:

> proc reset { } {
>     jtag  assert  TRST  SRST
>     jtag  sleep-msecs  250

To my taste, "msleep 250".  ;)

>     jtag de-assert TRST

I'd like to see some "jtag verify" options here,
so that part of the reset sequence is likewise
not hard-wired in C code.  

So maybe "jtag verify from_trst [NBITS]" would
verify the IR length of NBITs total against the
declared TAPs, and then the DR values for TAPs
that have an IDCODE instruction.  And, harder,
do something sensible when there's no match...
today everything just continues to bull through.


>     jtag ... scan command
>     jtag .. scan command
>     jtag .. scan command
>     jtag de-assert SRST
> }

That seems more like a component that should be plugged
into the reset sequence than a reset itself.  (And it's
a good example of getting work done while SRST is
still asserted... something not all TAPS handle, but
some require.)


Doing a bit of brainstorming ... I think that should
be instead a "proc hard_reset", with those scans
packaged not unlike the current *target* event ops,
except done as *TAP* events.  Each TAP might need
different setup too.

That way for example if you've got a system that has
no SRST and must instead issue resets through JTAG ops,
just hard_reset would get overridden.

And from the user interaction perspective, my initial
thought is that being able to customize behavior of
resets by permitting "reset hard", "reset soft", and
other operations ("reset fred", "reset usb", etc)
would seem a bit nicer than needing to define a bunch
of custom operations.  But those models can be argued.

- Dave