From 03b2b345ed8d5d9a6dfd7c31ccc63a77d5a05122 Mon Sep 17 00:00:00 2001 From: zwelch Date: Tue, 9 Jun 2009 02:48:28 +0000 Subject: [PATCH] Merge documentation for jtag_add_statemove from source into header block. git-svn-id: svn://svn.berlios.de/openocd/trunk@2148 b42882b7-edfa-0310-969c-e2dbd0fdcd60 --- src/jtag/jtag.c | 27 --------------------------- src/jtag/jtag.h | 30 +++++++++++++++++++++++++----- 2 files changed, 25 insertions(+), 32 deletions(-) diff --git a/src/jtag/jtag.c b/src/jtag/jtag.c index 97f60b53..3962fb2d 100644 --- a/src/jtag/jtag.c +++ b/src/jtag/jtag.c @@ -2523,33 +2523,6 @@ static int handle_tms_sequence_command(struct command_context_s *cmd_ctx, char * return ERROR_OK; } -/** - * 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) { tap_state_t cur_state = cmd_queue_cur_state; diff --git a/src/jtag/jtag.h b/src/jtag/jtag.h index e9caf984..3ad12f2d 100644 --- a/src/jtag/jtag.h +++ b/src/jtag/jtag.h @@ -675,16 +675,36 @@ extern void jtag_add_dr_out(jtag_tap_t* tap, /** * jtag_add_statemove() moves from the current state to @a goal_state. * - * This function was originally designed to handle the XSTATE command - * from the XSVF specification. - * * @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); -- 2.39.5