Re: [Openocd-development] Advanced Reset Process

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

On Monday 29 June 2009, Øyvind Harboe wrote:
> The "reset" tcl proc really is *very* CPU oriented. It doesn't make
> much sense to talk about resetting an FPGA into the halted
> state....

Right, and that's a problem.  As I noted earlier, there
need to be reset hooks that kick in at just the TAP layer.
In some cases, just to be able to issue 

Without going into command structure, I think the
following tasks are necessary:

 * After entering test-logic-reset but before leaving
   that state to verify the scan chain using IR or DR
   (and preventing all JTAG state transitions!):

   - Issue N cycles of TCK ... for cases like ICEpick
     or PXA255 where they're needed to wake up JTAG;

   - Issue N pulses TMS with TCK held high ... for that
     MSP430 case, forcing a fuse check 

 * After exiting test-logic-reset by verifying the
   scan chain against the expected record:

   - Arbitrary JTAG operations ... "svf file.name" to
     load an FPGA, "jtag tapenable tapname" to make
     sure a target's TAP is always enabled.  (For now
     I'd avoid the notion of automagic TAP enabling.)

 * Before running a tap-enable handler:

   - Arbitrary JTAG operations ... in particular,
     enabling the ETB before enabling a TAP whose
     ETM requires it

Seems to me all of those can be done with a few
new TAP events:  "pre_verify", "post_verify" for
the first two (following the existing model for
target events), "pre_enable" for the latter.

And for that MSP430 thing, if it starts to matter,
a new lowlevel primitive would be needed.

- Dave