Dick Hollenbeck wrote:
> Magnus Lundin wrote:
>> Hi, here are som thoughts after looking throuh some parts of the jtag
>> subsystem.
>>
>> What is a stable state ? A state that is unchanged or a state that
>> is unchanged and has no sideeffects ? Only RESET and PAUSE ?
>>
>
> A stable state is one that can persist with subsequent clocks. Most
> states are such that they persist for only one clock cycle. In all
> cases a stable state can only persist with a subsequent clock cycle if
> the TMS line is in a specific value. That is only of the two possible
> TMS values allows the stable state to persist. A stable state is any
> in the TAP state diagram which has an arrow looping back to itself. I
> see 6 of them in the state diagram.
>
That is true if you only consider tep tap state engine, and not the
effects on the target. For shifts we usually want an exact number of
transitions from this state and this is similar in systems that uses RTI
to clock the core. We can also note that TAP_DRSCAN and TAP_IRSCAN are
never used as an endstate in target code. It is only used in jtag
interface code within scan commands to reach the SHIFT states, and then
we transition out to another stable state. So allowing only stable
states because other endstates are unsafe, and allowing SCANS as
endstates from target code is not consistent.
I agree with Laurent
> JTAG STABLE STATE are : RESET / IDLE / IRPAUSE / DRPAUSE
>
> I would go blind looking at these arrays. You talk about using
> states, but then I see a table of numbers. Numbers don't mean
> anything to me. I am not a computer. The code has to be readable, as
> a human. Maybe I mis-understand you.
>
Yes symbolic constant must be used, but they generate very long lines
and this mail system will mess it up terribly. But you can get the tomorrow.
> We already have the jtag_add_pathmove() function. Its API is elegant
> and in theory it can do anything we need anywhere. Why do we need
> other?
jtag_add_pathmove is good, i like it, it is the jtag_statemove and the
bittable of 7 step transitions specified in terms of TMS seuences that
is as clear and elegant, unless you really get deeply involved in jtag
> What is more readable than an array of states through which you wish
> to travel, specified in a human readable #define TAP_<state> ? See
> here from xsvf.c:
>
>
> static tap_state_t exception_path[] = {
> TAP_DREXIT2,
> TAP_DRSHIFT,
> TAP_DREXIT1,
> TAP_DRUPDATE,
> TAP_IDLE,
> };
>
> jtag_add_pathmove(
> sizeof(exception_path)/sizeof(exception_path[0]), exception_path);
>
>
> It is like connecting the dots for me, I understand it. This
> function can handle any use case that I can think of.
>
>
> Dick
>
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
