As Dick pointed out, trunk has a way to log _every_ tap state transition including the moves generated as part of a move to a non- adjacent state. Now, I would be happy to see improvements in the state transitions so that we don't do 7 moves on every transition.

Rick


On Feb 24, 2009, at 12:31 PM, Kees Jongenburger wrote:

Hello Holger

I was looking into the jtag tms_seq code and I am convinced your
function would be more usefull
and would allow us to better understand the code overall. While debugging I even this the openocd state machine should simply follow what happens
in such low level functions.



On Fri, Feb 20, 2009 at 4:53 PM, Holger Schurig
<[email protected]> wrote:
tap_state_transition() calculates the next state given a current
state and a TMS setting.

The attached function jtag_move_to() calulates the TMS bits given
a *ANY* current state and a *ANY* goal state. It could be used in
OpenOCD to replace the tms_seqs[][] table.

Currently, OpenOCD always sends down 7 TMS bit transitions to go
from a stable state to another stable state. However, with my
function it's possible to just send down the needed bits. For
this I wrote my own

void ft2232_tms(int bits, char tms)
{
       MYTRACE("ft2232_tms(%d, 0x%02x)", bits, (quint8)tms);
       for (int i=0; i<bits; i++) {
               bool t = tms & (1 << i);
current_state = tap_state_transition(current_state, t); MYVERBOSE(" tms %d, advance to %s %d", t, tap_state_name(current_state), current_state);
       }
       ft2232_buffer.append(0x4b);
       ft2232_buffer.append(bits-1);
       ft2232_buffer.append(tms);
}


I'm currently using both the jtag_move_to() and the jtag_tms()
functions in a project that is outside OpenOCD, so it might need
slight massaging if you think that this is helpful. For me, it's
helpful, because it allows me to easily do any state transition
the hardware wants.

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development


_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

--
Rick Altherr
[email protected]

"He said he hadn't had a byte in three days. I had a short, so I split it with him."
 -- Unsigned



Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development

Reply via email to