Michael Bruck wrote: > On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > >> Spencer Oliver wrote: >> >>>>> If you define your interface with only srst then the >>>>> >>>> software method >>>> >>>>> will be used. >>>>> Well it did last time i checked - see jtag_add_reset for code. >>>>> >>>>> >>>>> >>>> That code makes a move to TLR. This method is fine when you know in which >>>> state you are, but not when OpenOCD is started and the previous TAP state >>>> is >>>> undefined. >>>> >>>> >>>> >>> I have not dug into jtag.c for a while, i am pretty sure it was not the >>> case. >>> it was a few years back however that this support was originally added. >>> >>> Cheers >>> Spen >>> >>> _______________________________________________ >>> Openocd-development mailing list >>> Openocd-development@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/openocd-development >>> >>> >> move to TLR works for all current states. It is 7 steps with TMS high, that >> takes you to TAP_RESET froma any starting state. >> > > Moving to TLR from an *unknown* state doesn't work because we pretend > that there is no such thing as the TAP being in an unknown state. We > rather initialize the boot state to be TAP_RESET. Which is not only > false but also leads low level drivers to believe that nothing needs > to be done. In particular the ft2232 driver says statemove TAP_RESET > -> TAP_RESET is redundant and does not need to be executed (see > ft2232_execute_statemove() ). > > > I have not had time look look closely into this but I think that what must be decided is the exact semantics of state_move(end_state) - Is it, as I think it should be : move to end_state, and if we are already there do nothing ?
Then the tlr call should be implemented , in jtag.c, with a path_move of 7 tms=1 steps. This should work for all start states. And it easy to implement and test witout major disruptions. Definetly possible for 0.2.0 Regards Magnus - _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
