Move documentation in jtag_add_statemove body to Doxygen block.

git-svn-id: svn://svn.berlios.de/openocd/trunk@2136 b42882b7-edfa-0310-969c-e2dbd0fdcd60
__archive__
zwelch 2009-06-09 01:16:13 +00:00
parent ec274b2707
commit b3121aac76
1 changed files with 23 additions and 27 deletions

View 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 )
{