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 nothing. This can make the next
operations fail because they start from the wrong TAP state...
Fix by: instead of caring about the current recorded state, always
enter TAP_RESET by forcing five clocks with TMS high.
---
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
Expedience suggests (a), since there's no TMS+TCK level interface
to the drivers, and I'm not sure there should be.
Comments?
src/jtag/ft2232.c | 12 ++++++++++--
1 file changed, 10 insertions(+), 2 deletions(-)
--- a/src/jtag/ft2232.c
+++ b/src/jtag/ft2232.c
@@ -1587,8 +1587,16 @@ static int ft2232_execute_statemove(jtag
}
ft2232_end_state(cmd->cmd.statemove->end_state);
- /* move to end state */
- if (tap_get_state() != tap_get_end_state())
+ /* For TAP_RESET, ignore the current recorded state. It's often
+ * wrong at server startup, and this transation is critical whenever
+ * it's requested.
+ */
+ if (tap_get_end_state() == TAP_RESET) {
+ clock_tms(0x4b, 0xff, 5, 0);
+ require_send = 1;
+
+ /* shortest-path move to desired end state */
+ } else if (tap_get_state() != tap_get_end_state())
{
move_to_state(tap_get_end_state());
require_send = 1;
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
