Most of the cheap ft2232 devices probably do not have sense circuit on SRST. Actually, I would like to have Vcc sense circuit on my Olimex board but it is a different topic.
For most users, it is enough to be able to call reset routine defined by reset_config. It most cases (I think) the user will know what is the required reset pulse width and delay between reset rise edge and cpu ready. For example, on one of the boards I have, SRST is connected to sense pin of a reset IC. The IC will hold board reset for about 200ms and then let go. The CPU will need another 50 ms to do its init. So I can just set jtag_nsrst_delay to 300ms. If openocd calls reset routine before doing JTAG scan, everything will work just fine (even with fdt2xx driving SRST/TRST wires on init). I still think that this should be optional feature since some people will want to connect to their cpu without resetting it (hopefully they can use something else the ftd2xx library) in order to debug it. In my case, I really just want to have the cpu in a known state when I run my scripts and I am fine with the reset state. On Wed, 2009-09-23 at 10:30 -0700, David Brownell wrote: > On Wednesday 23 September 2009, Michael Schwingen wrote: > > David Brownell wrote: > > > Where -- to summarize ruthlessly -- you said that not only is > > > the FT2232 annoyingly imposing an SRST on you, but you also > > > need an extra delay to recover from that. Right? > > > > > A board may stretch SRST, so you *have* to be able to wait a > > (user-defined) amount of time after SRESET assertion/deassertion before > > talking to anything in the chain. This is also true if the SRESET > > assertion is not caused by OpenOCD directly. > > Understood. This is part of why some JTAG adapters provide > inputs for SRST, not just outputs. It'd be nice if the > FT2232 ones provided a "USB interrupt" to give hosts an > asynch (more or less) notification that it was asserted. > > Hmm ... FT2232 *does* have special 0x88 and 0x89 commands > to block on ACBUS1 (GPIOH1) levels. And at least one > adapter design I'm looking at hooks nSRST up to that, as > an input (you can tell by, among other things, looking at > how the level shifters are wired). So for such adapters > (which I suspect aren' that common) it might be possible > to add some special casing to handle that case. > > - Dave > _______________________________________________ > Openocd-development mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/openocd-development _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
