The problem I have is that the JTAG scan [in openocd] happens too soon after SRST [in ftd2xx] is released. The CPU is not ready. That is why I proposed to 'properly' reset CPU before accessing it.
I thought that you want to have the CPU in a known state? Accessing it after SRST/TRST wires are driven "randomly" is going to give un-reasonable/un-repeatable results. So, either you have to guarantee that you are not touching JTAG signals before doing scan (so that you can 'attach' yourself to current CPU state without altering its state) or you touch the signals in a fashion the will put the cpu in a known state (reset for example). As a compromise, it would be ideal to allow for option to reset (SRST/TRST or however reset is defined for a given CPU with reset_config) before accessing JTAG state machine. For example, you could have reset_on_access true/false or something similar. On Wed, 2009-09-23 at 07:26 +0200, Øyvind Harboe wrote: > On Wed, Sep 23, 2009 at 1:30 AM, michal smulski <[email protected]> > wrote: > > > > The offending code is called from this function: > > static int ft2232_init_ftd2xx(uint16_t vid, uint16_t pid, int more, int* > > try_more) > > > > And the actual function call is here: > > status = FT_OpenEx(openex_string, openex_flags, &ftdih); > > It's only to be expected that the hardware is in an undetermined > state before OpenOCD accesses it + that signals go a bit > haywire while the ft2232 is being set up. > > I don't think there is anything that OpenOCD could or should > do with this... > > > _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
