zcy
/
tinyriscv-openocd
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

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
__archive__
zwelch 2009-06-09 02:48:28 +00:00
parent cf08b00376
commit 03b2b345ed
2 changed files with 25 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

27
src/jtag/jtag.c
View 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;

30
src/jtag/jtag.h
View 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);