auracaster/openocd
3
0
Fork 1
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Move jtag_add_statemove decl/body nearer jtag_add_pathmove.

Browse Source 
git-svn-id: svn://svn.berlios.de/openocd/trunk@2184 b42882b7-edfa-0310-969c-e2dbd0fdcd60
This commit is contained in:
zwelch
2009-06-11 07:08:03 +00:00
parent c1995bb08f
commit 04cb121073
2 changed files with 77 additions and 77 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
src/jtag/jtag.h
View File

@@ -507,6 +507,39 @@ extern void jtag_add_tlr(void);
*/
extern void jtag_add_pathmove(int num_states, const tap_state_t* path);
/**
* jtag_add_statemove() moves from the current state to @a goal_state.
*
* @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);
/**
* Goes to TAP_IDLE (if we're not already there), cycle
* precisely num_cycles in the TAP_IDLE state, after which move
@@ -674,39 +707,6 @@ extern void jtag_add_dr_out(jtag_tap_t* tap,
tap_state_t end_state);
/**
* jtag_add_statemove() moves from the current state to @a goal_state.
*
* @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);