On Tuesday 22 September 2009, michal smulski wrote:
> 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.
Hmm ... I had been hoping that JTAG adapters would initialize
themselves to both SRST and TRST *inactive* but it seems we
can't rely on that in this case because the FT2232 chip itself
isn't cooperating.
Maybe we need something like a call to
jtag_add_reset(0, 0);
very early in interface setup? Plus something to flush it,
I guess. If the JTAG adapter itself is going to glitch
those signals, we can't help that; but we can at least make
sure that we have a clean init state on our end, even if
the adapter sent the board out to lala-land for a while.
> > 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.
Annoying.
> > > 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.
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?
> 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.
Actually that jtag_init() code will call the same jtag_init_reset()
that starts the "reset halt" sequence, *IF* the init_inner() fails.
Now, there are some problems in that init_inner() doesn't much like
to fail. Maybe it should be less accepting... at least on the
initial invocation.
Correct me if I'm wrong (and please consult the jtag/core.c init
code to clarify): (a) your init_inner() call sees chaos but
(b) doesn't fail, so (c) you're not getting that cautious call
to have jtag_init_inner() do SRST at OpenOCD startup through
that jtag_init() call, and thus (d) you're doing it yourself ...
... but if (b') it *DID* fail so (c') that got called as the
code wants to be done, then (d') it looks like it'd work OK
without needing the manual workaround?
> > 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.
Where I've most recently seen that failure is if the JTAG clock
rate is set very wrong. ;)
And come to think of it, I think it can't have been going down
the SRST path then either, despite what the code says to do when
init_inner() loses.
- Dave
_______________________________________________
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openocd-development
