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
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
