I have been experimenting with OpenOCD XSVF support and have banged my head into (I guess) a configuration problem.
What happens:
“Error: ft2232.c:480 ft2232_add_pathmove(): BUG: rti → tlr isn’t a valid TAP transition”
This message makes sense, as the TAP transition mentioned above is invalid. However, the XSVF file is a valid one, and there is no such transition. The file starts with:
XREPEAT 0x20
XSTATE TLR
XSTATE RTI
XIR xxx
The error occurs after processing the XIR command, but this is only because the JTAG queue is executed by then. After adding some debugging commands, the real problem seems to be in the first XSTATE command.
It seems that the system is in the RTI state before executing the XSVF file. So, as the first state in the file is TLR, the JTAG engine chokes.
It also seems that the system is in RTI because the polling function has been running. Using the debugging polling is absurd in any case, as the chip is a PLD, not an ARM. So, my configuration is utterly insane. But how can I disable all ARM-specific debugging in the config file? So that no polling occurs and that the system is nicely in the TLR state in the beginning.
Also, the Xilinx paper on XSVF (XAPP503) seems to say three things about the XSTATE command:
-
if TLR is specified, use the safe sequence (five 1’s)
-
if the state is already valid (e.g. rti->rti), do nothing
-
otherwise take the correct path from A to B
This seems to imply there is no guarantee about the “one-step” approach, XSTATE may specify non-adjacent states. It seems that Xilinx files do specify only one-step transitions, but the above does not guarantee it.
I can write a patch, if required. However, I am not quite sure where the patch should go. In a way I think this is something the add_pathmove should actually take care of. No functions above it know anything about the actual JTAG state, and that knowledge is required. OTOH, if we are only talking about XSVF functionality, and we take the TLR part (five 1’s) seriously, then it might happen we do not need to know anything about the previous state.
On the other hand, there seems to be some stuff related to state transition paths in jtag.c, so maybe that could be utilized here?