On Mon, Jun 1, 2009 at 9:41 PM, Magnus Lundin <lun...@mlu.mine.nu> wrote: > Ø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".
I don't disagree with that goal. Currently however the lower layers have more intelligence otherwise there would be no pathmove and statemove but rather a shift_tms(data, number_of bits) function. My opinion: We should set the TAP state to TAP_INVALID on startup and resets. All functions that generate activity on the interface except jtag_add_tlr() and the functions that manipulate reset lines should produce fatal errors when called in this state. This way we can weed out many potential errors that can happen when TLR is not enforced after resets. When the device is reset this should *require* an explicit TLR. The condition should not be casually glossed over by an automagic statemove(). This code: > jtag_add_statemove(TAP_RESET) > jtag_stableclocks(6) /* I am not 100% sure about this here */ covers up an error that is produced by the unclear semantics of statemove(). In ft2232 statemove(TAP_RESET) is a NOP under certain circumstances and jtag_stableclocks(6) glosses over that in a rather crude fashion. You can modify statemove() in ft2232 (and in all other drivers that might behave similarly) to work around this, but then you are working against your stated goal to remove intelligence from that layer. Michael _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
