Merge documentation for jtag_add_statemove from source into header block.
authorzwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60>
Tue, 9 Jun 2009 02:48:28 +0000 (02:48 +0000)
committerzwelch <zwelch@b42882b7-edfa-0310-969c-e2dbd0fdcd60>
Tue, 9 Jun 2009 02:48:28 +0000 (02:48 +0000)
git-svn-id: svn://svn.berlios.de/openocd/trunk@2148 b42882b7-edfa-0310-969c-e2dbd0fdcd60

src/jtag/jtag.c
src/jtag/jtag.h

index 97f60b532ed63c8e5710d198d31c656e866ea79b..3962fb2d8a6310ef76d35279180de8d60d7f50f6 100644 (file)
@@ -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;
index e9caf9840876381c69a0a7eca2e22a5880a1e10d..3ad12f2d11664da3f7182b3d21b494b1e950ec8d 100644 (file)
@@ -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);
 

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)