> > > >/ Maybe the check should be put back anyway, even when we know that > />/ it takes 7 or less steps in case someone changes the code later. > />/ > />/ > /No doubt that check is needed, or > > a function rewrite which changes tms to bit a bit vector, and then > "bits" (which BTW should be called bitcount to make it clear this > parameter is not the bit vector) can be any number and then the > function could be used to send the tap machine on an arbitrary nearly > endless journey, including looping. > > As written, it is a mine field. > > Since I am a dummy, I have experience with "APIs for Dummys". > > Dick >
Actually, you have all functions in OpenOCD JTAG layer to do any TAP State transition. Just adjust _end_state before sending new _scan. end_state should only be STABLE states as : IDLE RESET DRPAUSE IRPAUSE. DO NOT add any _tms functions. Why ? Because it is a bit dangerous to let user calling the JTAG HAL with their own _tms. If you let users going in UNSTABLE states, we will have a lot of new troubles in OpenOCD. As I tell you before, there are enough functions for passing from DRSCAN to a new DRSCAN without passing in IDLE state: fix _end_state to DRPAUSE add your _scan add _state_move to DRPAUSE fix _end_state to IDLE add your new _scan Before adding new functions to JTAG HAL, please make sure to understand the actual ones ! Regards, Laurent Gauch http://www.amontec.com Making JTAG a snap ! ______________________________ *Amontec To Exhibit at Embedded World 2009 *Amontec Hi-Speed JTAGkey2 Compare JTAGkey and JTAGkey2 speeds yourself at Embedded World 2009 <http://www.embedded-world.de/en/> in Nuremberg, Germany from 3rd - 5th March 2009 FTDI Hall 12 Stand 442 ______________________________ _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
