> > Øyvind Harboe wrote: > >/ On Fri, Apr 24, 2009 at 7:52 AM, Dick Hollenbeck <dick at softplc.com > ><https://lists.berlios.de/mailman/listinfo/openocd-development>> wrote: > />/ > />>/ Why is this code in jtag_add_pathmove()? > />>/ > />>/ > />>/ ?????????????????? > />>/ > />>/ /* the last state has to be a stable state */ > />>/ if (!tap_is_state_stable(path[num_states - 1])) > />>/ { > />>/ LOG_ERROR("BUG: TAP path doesn't finish in a stable state"); > />>/ exit(-1); > />>/ } > />>/ > />>/ ??????????????????? > />>/ > />>/ > />>/ > />>/ > />>/ It is not obvious to me why this function should not be allowed to move > />>/ between any states as allowed by the tap state diagram which is enforced > />>/ by the nifty tap_state_transition() tests: > />>/ > />>/ > />>/ if ( tap_state_transition(cur_state, true) != path[i] > />>/ && tap_state_transition(cur_state, false) != path[i]) > />>/ { > />>/ LOG_ERROR("BUG: %s -> %s isn't a valid TAP transition", > />>/ tap_state_name(cur_state), tap_state_name(path[i])); > />>/ exit(-1); > />>/ } > />>/ > />/ > />/ > />/ One reason is to restrict things so as to allow hardware implementations > />/ of the JTAG state machine. > />/ > />/ Why would we need said flexibility? It's not needed by the code today... > />/ > / > Well, my question was "why do we need such a restriction", and yours is > "why do we need such flexibility". > > > I was trying to understand what is being protected against with the > restriction. > > > 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. Regards, Laurent http://www.amontec.com _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
