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? Second, does this happen with "libftdi" too, or does that behave properly? > 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? 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 _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
