diff options
| -rw-r--r-- | src/jtag/jtag.c | 50 |
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 ) { |