(Re-sending to the list with right from address this time) On 24/04/2009, Laurent Gauch <laurent.ga...@amontec.com> wrote: > > > > Michael's comment is valid. But it would be a surprise to me that our > > cable API would allow cable hardware to issue clock cycles without being > > specifically requested to do so by the API. That in itself seems very > > wrong to me, and wish to up my reaction from surprise to astonishment. > > > > Without the clock cycles, any state's duration can be stretched, right? > > Stretched across API calls anyway. > > > > > > Dick > > Øyvind's comment is RIGHT ! Actually, no hardware have this functionality of > free TCK running. Also by experience the TCK free running is not a good > approach to me. > Also, restricting things on an HAL as our JTAG interface is ever a good > point(minimize the number of functions and params ... and headache ) > > I want to remember that only the use of JTAG STABLE STATES should be used > from the top of the JTAG interface (jtag.h) ! > As it was done long time ago by Dominic and me at Amontec ( yes 2005 - 2006 > ). > > JTAG STABLE STATE are : RESET / IDLE / IRPAUSE / DRPAUSE. > In this states the JTAG SM (state-machine) is stable. > > Admitting you still want to have a free TCK running, in this case you will > need to make sure that your top interface only allows JTAG STABLE STATE move, > other way your FSM will be out. > > Please KEEP only the HAL as it is and only use JTAG STABLE STATE.
I've heard that Texas instruments' SN74ACT8990 "test bus controller" has a free running TCK (though I'm not familiar with how it works). When I was explaining how the FT2232 jtag commands work to someone who had worked with the 8990, he was shocked that the FT2232 actually paused the TCK between operations. _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
