From 03b2b345ed8d5d9a6dfd7c31ccc63a77d5a05122 Mon Sep 17 00:00:00 2001 From: zwelch Date: Tue, 9 Jun 2009 02:48:28 +0000 Subject: 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 --------------------------- 1 file changed, 27 deletions(-) (limited to 'src/jtag/jtag.c') 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; -- cgit v1.2.3