From 04cb1210733537aa65d2975515a8be137dbd0b2b Mon Sep 17 00:00:00 2001 From: zwelch Date: Thu, 11 Jun 2009 07:08:03 +0000 Subject: Move jtag_add_statemove decl/body nearer jtag_add_pathmove. git-svn-id: svn://svn.berlios.de/openocd/trunk@2184 b42882b7-edfa-0310-969c-e2dbd0fdcd60 --- src/jtag/jtag.h | 66 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 33 insertions(+), 33 deletions(-) (limited to 'src/jtag/jtag.h') diff --git a/src/jtag/jtag.h b/src/jtag/jtag.h index dcdad8e..9ce7347 100644 --- a/src/jtag/jtag.h +++ b/src/jtag/jtag.h @@ -508,6 +508,39 @@ extern void jtag_add_tlr(void); extern void jtag_add_pathmove(int num_states, const tap_state_t* path); /** + * jtag_add_statemove() moves from the current state to @a goal_state. + * + * @param goal_state The final TAP state. + * @return ERROR_OK on success, or an error code on failure. + * + * 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 @c tms_bits holds a path that agrees with [Ref 5] in the + * 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, @a goal_state must be immediately reachable in one clock + * cycle, and does not need to be a stable state. + */ +extern int jtag_add_statemove(tap_state_t goal_state); + +/** * Goes to TAP_IDLE (if we're not already there), cycle * precisely num_cycles in the TAP_IDLE state, after which move * to @a endstate (unless it is also TAP_IDLE). @@ -674,39 +707,6 @@ extern void jtag_add_dr_out(jtag_tap_t* tap, tap_state_t end_state); -/** - * jtag_add_statemove() moves from the current state to @a goal_state. - * - * @param goal_state The final TAP state. - * @return ERROR_OK on success, or an error code on failure. - * - * 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 @c tms_bits holds a path that agrees with [Ref 5] in the - * 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, @a goal_state must be immediately reachable in one clock - * cycle, and does not need to be a stable state. - */ -extern int jtag_add_statemove(tap_state_t goal_state); - /// @returns the number of times the scan queue has been flushed int jtag_get_flush_queue_count(void); -- cgit v1.1