summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--src/jtag/jtag.c50
1 files changed, 23 insertions, 27 deletions
diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c
index 751e53f9..0af50803 100644
--- a/src/jtag/jtag.c
+++ b/src/jtag/jtag.c
@@ -2569,10 +2569,31 @@ static int handle_tms_sequence_command(struct command_context_s *cmd_ctx, char *
}
/**
- * Function jtag_add_statemove
- * moves from the current state to the goal \a state. This needs
+ * Moves from the current state to the goal \a state. This needs
* to be handled according to the xsvf spec, see the XSTATE command
* description.
+ *
+ * From the XSVF spec, pertaining to XSTATE:
+ *
+ * For special states known as stable states (Test-Logic-Reset,
+ * Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
+ * predefined TAP state paths when the starting state is a stable state
+ * and when the XSTATE specifies a new stable state. See the STATE
+ * command in the [Ref 5] for the TAP state paths between stable
+ * states.
+ *
+ * For non-stable states, XSTATE should specify a state that is only one
+ * TAP state transition distance from the current TAP state to avoid
+ * undefined TAP state paths. A sequence of multiple XSTATE commands can
+ * be issued to transition the TAP through a specific state path.
+ *
+ * @note Unless @a tms_bits holds a path that agrees with [Ref 5] in *
+ * above spec, then this code is not fully conformant to the xsvf spec.
+ * This puts a burden on tap_get_tms_path() function from the xsvf spec.
+ * If in doubt, you should confirm that that burden is being met.
+ *
+ * Otherwise, state must be immediately reachable in one clock cycle,
+ * and does not need to be a stable state.
*/
int jtag_add_statemove(tap_state_t goal_state)
{
@@ -2589,35 +2610,14 @@ int jtag_add_statemove(tap_state_t goal_state)
tap_state_name(goal_state) );
- /* From the XSVF spec, pertaining to XSTATE:
-
- For special states known as stable states (Test-Logic-Reset,
- Run-Test/Idle, Pause-DR, Pause- IR), an XSVF interpreter follows
- predefined TAP state paths when the starting state is a stable state and
- when the XSTATE specifies a new stable state (see the STATE command in
- the [Ref 5] for the TAP state paths between stable states). For
- non-stable states, XSTATE should specify a state that is only one TAP
- state transition distance from the current TAP state to avoid undefined
- TAP state paths. A sequence of multiple XSTATE commands can be issued to
- transition the TAP through a specific state path.
- */
-
if (goal_state==cur_state )
; /* nothing to do */
-
else if( goal_state==TAP_RESET )
{
jtag_add_tlr();
}
-
else if( tap_is_state_stable(cur_state) && tap_is_state_stable(goal_state) )
{
- /* note: unless tms_bits holds a path that agrees with [Ref 5] in above
- spec, then this code is not fully conformant to the xsvf spec. This
- puts a burden on tap_get_tms_path() function from the xsvf spec.
- If in doubt, you should confirm that that burden is being met.
- */
-
tms_bits = tap_get_tms_path(cur_state, goal_state);
tms_count = tap_get_tms_path_len(cur_state, goal_state);
@@ -2633,10 +2633,6 @@ int jtag_add_statemove(tap_state_t goal_state)
jtag_add_pathmove(tms_count, moves);
}
-
- /* else state must be immediately reachable in one clock cycle, and does not
- need to be a stable state.
- */
else if( tap_state_transition(cur_state, true) == goal_state
|| tap_state_transition(cur_state, false) == goal_state )
{