On Tue, 2009-09-22 at 17:59 -0700, David Brownell wrote: > On Tuesday 22 September 2009, michal smulski 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); > > I'm not quite following here. First, what's wrong? In what > way does that "offend", what's the failure mechanism? > The problem is that this functions asserts SRST (and TRST but not quitr right). This resets the CPU. openocd does immediate scan and it fails because the CPU is not ready.
> Second, does this happen with "libftdi" too, or does that > behave properly? > I tried libftdi but it has different problems. I gave up on it because I had to power-cycle CPU after running openocd in order to get to talk to CPU. So I actually don't know what it does. > > > ftd2xx is a closed source library. However, openocd should not rely on > > any libraries to properly reset a chip since these libraries do not know > > what is a 'proper reset.' Openocd knows how it should reset the chip > > from *.tcl scripts. So I propose to add a reset after ft2232_init (or > > any other generic libs such as libftdi*) and before the first JTAG scan > > to properly reset devices on the scan chain. > > Again, I don't follow. What are you saying the init sequence > should be? Which chip(s) should get reset when, and why? Are > you referring to one of the chips on the target board? Or maybe > the FT2232 chip? > See my previous email to Øyvind. I am talking about SRST/TRST reset as defined by reset_config command. This is only defined for reset init/halt/run but not for initial scan of the JTAG chain. > What OpenOCD tries to do today is first validate the scan chain > defined to it using only TRST to ensure the TAPs are in a known > state, one which exposes their IDCODE registers (if any) ... and > if that works, it starts up without any SRST assertion, which is > IMO the correct default behavior. > If that fails, then jtag_init() will retry after a hard SRST > assertion. Kind of unavoidable; maybe worth logging, that's > kind of harsh. I don't to see a running board needlessly get > reset just because OpenOCD got started. > > - Dave I do not see this behavior on a scope. The only thing I see is SRST/TRST asserted by ftd2xx library. openocd does not seem to touch those signals until you issue reset halt or similar. In fact, openocd hangs right after initial scan (if SRST is connected to CPU reset) because the CPU returns garbage. _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
