On Sun, Feb 1, 2009 at 6:16 AM, Dick Hollenbeck <[email protected]> wrote:
> Kees Jongenburger wrote:
>>
>> Hello
>>
>> in src/jtag/jtag.c I see the tap_move array that will define the command
>> to go from one state to an other state.
>>
>> Here is the array
>>
>> /* tap_move[i][j]: tap movement command to go from state i to state j
>>  * 0: Test-Logic-Reset
>>  * 1: Run-Test/Idle
>>  * 2: Shift-DR
>>  * 3: Pause-DR
>>  * 4: Shift-IR
>>  * 5: Pause-IR
>>  *
>>  * DRSHIFT->DRSHIFT and IRSHIFT->IRSHIFT have to be caught in
>> interface specific code
>>  */
>> u8 tap_move[6][6] =
>> {
>> /*        RESET  IDLE  DRSHIFT  DRPAUSE  IRSHIFT  IRPAUSE             */
>>        {  0x7f, 0x00,    0x17,    0x0a,    0x1b,    0x16},     /* RESET */
>>        {  0x7f, 0x00,    0x25,    0x05,    0x2b,    0x0b},     /* IDLE */
>>        {  0x7f, 0x31,    0x00,    0x01,    0x0f,    0x2f},     /* DRSHIFT
>>  */
>>        {  0x7f, 0x30,    0x20,    0x17,    0x1e,    0x2f},     /* DRPAUSE
>>  */
>>        {  0x7f, 0x31,    0x07,    0x17,    0x00,    0x01},     /* IRSHIFT
>>  */
>>        {  0x7f, 0x30,    0x1c,    0x17,    0x20,    0x2f}      /* IRPAUSE
>>  */
>> };
>>
>> I have the following questions about that. It seams sub-optimal to
>> always perform 7 TCK cycles
>> to move from one state to an other or am I mis understating something?
>>
>
> You are correct.   As an alternative you can steer the TAP controllers step
> by step if you like.   These 6 states are all stable states, and should the
> TAP get to a destination stable state before the balance of the seven clocks
> are fired, then the balance are fired in the destination state.
Clearly if shift-ir and shift-dr are stable states we should not clock events
while in those states. I think the code does just to opposite and
wait's somethere.


>It is only
> a few clocks typically.  Another question to keep in mind is, is the path
> between stable states given always the path desired?
Apparently not  but we need to check.

I just updated the SVN and I am looking into the new methods
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to