On Wed, Apr 6, 2011 at 3:33 PM, Laurent Gauch <laurent.ga...@amontec.com> wrote: > Before. > Reading "Figure 6-16 Write Processor Access Example", the PrACC must be > checked first.
OK, then it is well implemented in my patch. But I propose other method, based on my last thinking of SPrAcc - PrAcc relation (if my assimption is right) : SPrAcc basically holds the value of PrAcc from CONTROL register. They are the same thing - a replica. With the difference that you can affect SPrAcc with scan chain : What you shift out is the current value of PrAcc. What you shift in is the future value of PrAcc. Because every "simple" write begins by waiting that PrAcc is "1" and then putting it to "0", FASTDATA is no exception, but we put PrAcc to zero by shifting "0" to SPrAcc. At the same time we shift out ex-value of PrAcc - an if it was not "1" we are in trouble (that means that we wanted to initiate access on PrAcc "0"). So, if these assumptions are correct, then finally current implementation in the repo is quite fine. Except for the fact that it does not shift out SPrAcc (i.e. it misses jtag_execute_queue() and check at the end). We do not need to wait for PrAcc before (big loose of time) - we will check it's ex-value anyway in the shifted-out SPrAcc. If it was not "1" we can then wait and try again when it becomes "1". But with Amontec probe that will never happen - as I noted before in patch #3 which was rejected, as soon as we do jtag_execute_queue() I see no more problems ( even without shifting out bits, i.e. field.in_value=NULL; ). And because I have to do jtag_execute_queue() to shift out SPrAcc, I will never see a problem that PrAcc was not "1" (delay will be sufficient for it to become "1" every time), so I can not test this implementation. BR, Drasko _______________________________________________ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
