On Sunday 27 September 2009, Øyvind Harboe wrote:
> I think we should list the broken drivers in TODO and
> leave it at that.
Done
___
Openocd-development mailing list
Openocd-development@lists.berlios.de
https://lists.berlios.de/mailman/listinfo/openo
> Fixing around a dozen driver seems messy, but perhaps
> unavoidable. Do you think I should check in $SUBJECT
> and have us seek patches and testing for all of the
> other drivers?
I think we should list the broken drivers in TODO and
leave it at that.
There are lots of known bugs/problems in O
On Sunday 27 September 2009, Øyvind Harboe wrote:
> > Comments?
>
> TAP_RESET is special. Navigating to this state
> can only be done via jtag_add_tlr().
Or equivalently jtag_add_statemove(TAP_RESET), which
calls jtag_add_tlr() in turn.
There's bit of a maze at the intermediate levels, which
to
> Comments?
TAP_RESET is special. Navigating to this state
can only be done via jtag_add_tlr(). No assumptions
should be made about the JTAG TAP state as
jtag_add_tlr() supports being invoked when the state has
been modified by some external event.
--
Øyvind Harboe
http://www.zylin.com/zy1000.htm
David Brownell wrote:
> So this one's nasty, because of the root cause: OpenOCD init
> state is incorrect, so "shortest path" through the JTAG state
> machine wrongly short-circuits. Fix is either:
>
> (a) update every interface driver (!) like this
> (b) or else find some core fix
>
> Expedi
Update FT2232 driver so that it reliably enters TAP_RESET.
When the OpenOCD server starts up it records its state as TAP_RESET,
even though it could be anything. Then when it starts to examine
the scan chain, it calls jtag_add_tlr() which sees it doesn't have
any work to do, and so it does nothin
