[Openocd-development] Advanced Reset Process

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

On Wednesday 24 June 2009, Duane Ellis wrote:
> > So maybe you can answer this ... What does the "arp_" prefix in
> > various commands represent?
> >
> > "Address Resolution Protocol" was my first reaction ... but
> > that doesn't seem relevant to JTAG.  ;)
> 
> That name "arp_" was coined by my self an Oyvind last year when we where 
> trying to introduce "Reset events" and all the other Jim type events.
> 
> The "ARP" - stood for: "Advanced Reset Process" - ....


On Wednesday 24 June 2009, Øyvind Harboe wrote:
> The idea is to have a prefix to low level fn's that the higher
> level tcl reset proc uses.
>
> As such the choice of prefix is arbitrary.

OK, first question answered.  Thanks.

Next ...


Does it seem to you like the reset process is flexible
enough yet?  I'm thinking .. no:

 - All those reset events go to debug targets ... but
   there's at least the ICEpick example, where a JRC
   needs 100+ TCK cycles after entering TLR, and it's
   easy to find others.  Loading an FPGA, for one.
   Those aren't targets; so no events...

 - I was looking at DM355 documentation and it clearly
   distinguishes "cold" resets -- both TRST and SRST
   get cycled -- from "warm" ones -- SRST only.  We
   don't seem to have a clean way to do "warm" today.

 - In cases where there's no SRST available (*), there's
   no alternate hook to trigger reset through JTAG.  For
   example, using JRC operations (I'm hoping to get some
   documentation).  Or with Cortex-M3, it seems that
   some DAP operations can generate SRST too.

 - Wondering why this old PXA255 board won't work with
   current OpenOCD ... docs say that not only does it
   need 35+ TCK cycles after entering TLR, but also
   that the model is to keep SRST active while issuing
   the first few JTAG commands.  Current reset code
   deactivates SRST at the same time as TRST.

 - I found some TI docs talking about "Wait in Reset"
   capability of some systems, triggered by changing
   the EMU0/EMU1 signals (which OpenOCD doesn't know
   about) from "pulled high" to "one driven low".
   Same kind of model as those PXA255 docs describe.

 - Even when SRST *does* exist, I can imagine debug
   scenerios where using it is the wrong thing.  You
   may just want to reset one component, not the whole
   system.

 - Chasing that PXA thing I wanted to just issue a
   reset with no target enabled.  It didn't want to
   do such a thing with only JTAG level stuff defined.

And I suspect that if I looked around a bit, I'd find
more such cases where the reset model isn't (yet!)
advanced enough.  Thoughts?

- Dave

(*) As for example wherever TI's 14-pin JTAG connector
    is used.  My DM6446 board through 20-pin CTI to
    14-pin level shifting adapter; OMAP3 BeagleBoard.