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__
parent
ec274b2707
commit
b3121aac76
|
@ -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 )
|
||||
{
|
||||
|
|
Loading…
Reference in New Issue