Øyvind Harboe wrote: > On Fri, Apr 24, 2009 at 7:52 AM, Dick Hollenbeck <[email protected]> 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 _______________________________________________ Openocd-development mailing list [email protected] https://lists.berlios.de/mailman/listinfo/openocd-development
