Michael Schwingen wrote: > Magnus Lundin wrote: > >> Michael Bruck wrote: >> >> >>> On Tue, May 26, 2009 at 7:47 PM, Magnus Lundin <lun...@mlu.mine.nu> wrote: >>> >>> >>> >>>> 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 ? >> >> > I think in case of TAP_RESET, an exception to that rule might be useful. > Would it make sense to define that a driver has to make sure a requested > TAP_RESET end state really ends in TAP_RESET state, regardless of the > previous state, ie. the driver needs to always perform the necessary > number of clocks with TMS=1 without any clever optimizations? > > That way, upper layers would have an easy way to re-synchronize state > even if openocd and the target do not agree on what the current state is. > > I see your point and I basically agree, the problem is that state_move uses the state move table(s), that currently do use 7 step reset->reset transitions, but there is no "contract" for this. I also dislike the idea of having to put exceptions like this in the interface drivers. I think we also should look into how jtag_add_runtest is handled because this is a similar situation where we want to reach a certain endstate and then guarante a certain number of transitions in this state.
Best regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
