Move documentation in jtag_add_statemove body to Doxygen block.
authorzwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60>
Tue, 9 Jun 2009 01:16:13 +0000 (01:16 +0000)
committerzwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60>
Tue, 9 Jun 2009 01:16:13 +0000 (01:16 +0000)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2136 b42882b7-edfa-0310-969c-e2dbd0fdcd60

src/jtag/jtag.c

index 751e53f96e1454d4f73f4118d05c4a1ce542b9c8..0af508032a134750373b3538531287e8534d2e17 100644 (file)
@@ -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 )
        {

Linking to existing account procedure

If you already have an account and want to add another login method you MUST first sign in with your existing account and then change URL to read https://review.openocd.org/login/?link to get to this page again but this time it'll work for linking. Thank you.

SSH host keys fingerprints

1024 SHA256:YKx8b7u5ZWdcbp7/4AeXNaqElP49m6QrwfXaqQGJAOk gerrit-code-review@openocd.zylin.com (DSA)
384 SHA256:jHIbSQa4REvwCFG4cq5LBlBLxmxSqelQPem/EXIrxjk gerrit-code-review@openocd.org (ECDSA)
521 SHA256:UAOPYkU9Fjtcao0Ul/Rrlnj/OsQvt+pgdYSZ4jOYdgs gerrit-code-review@openocd.org (ECDSA)
256 SHA256:A13M5QlnozFOvTllybRZH6vm7iSt0XLxbA48yfc2yfY gerrit-code-review@openocd.org (ECDSA)
256 SHA256:spYMBqEYoAOtK7yZBrcwE8ZpYt6b68Cfh9yEVetvbXg gerrit-code-review@openocd.org (ED25519)
+--[ED25519 256]--+
|=..              |
|+o..   .         |
|*.o   . .        |
|+B . . .         |
|Bo. = o S        |
|Oo.+ + =         |
|oB=.* = . o      |
| =+=.+   + E     |
|. .=o   . o      |
+----[SHA256]-----+
2048 SHA256:0Onrb7/PHjpo6iVZ7xQX2riKN83FJ3KGU0TvI0TaFG4 gerrit-code-review@openocd.zylin.com (RSA)