Øyvind Harboe wrote: > On Mon, Jun 1, 2009 at 11:39 AM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > >> I propose some changes to the jtag subsystem >> >> - Add jtag_add_statmove( endstate ) call, the code is already in >> jtag_add_tlr() >> > > Could you write the documentation for this fn as a separate proposal? > > This is simply the jtag api wrapper for the JTAG_STATEMOVE command type. Move from current state to (stable state) endstate using the current state_table. If we are already in endstate do nothing > You are here talking about the application code communicating to the > driver that somehow the JTAG state machine state has changed "behind > the scenes"...? > No, that concernes the use in jtag_tlr(). This is useful after reset or some communication failure, usually signaled by a failed IR scan verification check. In my experience we get IR verification errors when there is some error causing the actual hw tap state and the drivers idea about current tap state to disagree. > I don't understand the motivation for allowing access to this fn, but I > vaguely recall that something was written about this on the list recently. > > Post 0.2? > > Or are you talking about something along the lines of xsvf_add_statemove() > in xsvf.c? > > Without knowledge about xsvf_add_statemove, probabky so. >> - Implement jtag_add_tlr() as >> jtag_add_statemovet(TAP_RESET) >> jtag_stableclocks(6) /* I am not 100% sure about this here */ >> > > Why? > > To remove different driver "interpretations" of how this should be done. >> - Make sure that JTAG_STABLECLOCKS is implemented in all drivers (we >> will soon fingd out otherwise ) >> > > Don't we already have this in jtag_add_clocks()? > Look for JTAG_STABLECLOCKS in the current JLink driver.
> Another thing I'd like first is to see if we can retire > jtag_add_end_state(), as this > would effectively make removing jtag_add_runtest() that little bit easier... > > I do not propose to remove jtag_add_runtest. I propose to remove the JTAG_RUNTEST command type and do the implementation in jtag.c layer. This can be done before or after jtag_add_end_state(), there is very little interation. And why am I doing this ? Testing a lot of reset and connect failures for different targets, with diffrent reset configurations for both ft2232 and jlink my conclusion is that the drivers should be smart about efficiently flipping jtag pins using the interface haredware, but jtag command logic and reset logic should be handled in jtag.c layer. So this proposal is part of mw work to make at least ft2232 and jlink drivers behave as similarily as possible. Or we could say "move common functionality upwards". Best regards Magnus _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
