Re: [OpenOCD-user] SWD transport for sysfsgpio

[Jean-Christian de R. <jc...@ec...>]

Le 10. 12. 14 22:32, Angus Gratton a écrit :
> On Wed, Dec 10, 2014 at 01:29:00PM +0100, Jean-Christian de Rivaz wrote:
>>> My understanding, that I'm guessing you share, is that you should be
>>> seeing FAULT responses to everything after the WAIT, until a write to
>>> ABORT clears the STICKYORUN flag.
>> Thanks for the hint ! The CORUNDETECT bit is set in target/arm_adi_v5.c and
>> is the cause of my problem. Not setting this bit make my patch working very
>> well.
> Hi Jean-Christian,
>
> Glad you found a solution!
>
> Just curious based on what you said previously, does clearing the
> STICKYORUN flag fail on SAMD21? (This should happen as part of writing
> ABORT, if you set the correct flag?)

Yes, it failed.

> I'm wondering because you could possibly leave overrun mode enabled
> and just call swd_clear_sticky_error(dap) on WAIT (or issue an
> equivalent command, as the "queueing" mechanism will disallow this
> exact call happening straight away), before you loop around and try
> again. This way the patch wouldn't require the hack, and all adapters
> could still use overrun mode.

Thanks for the advise, it work well this way too. I hope this make my 
last version of the patch viable enough to ask for a review:

http://openocd.zylin.com/#/c/2433/

Here is an image of the logic analyser with this patch in case of a WAIT 
response:

http://www.eclis.ch/openocd/swd-wait-3.png

> Let me know if the above paragraph doesn't make sense and I'll try and
> write it into the patch.

It make sense to fit the general organization of current OpenOCD code, 
but using the sticky bits on a sysfsgpio driver is slow and against the 
purpose of the sticky bits. Sticky bits have been designed for high 
latency and high throughput driver, witch is exactly the contrary of the 
the sysfsgpio driver: it has no latency at all and his throughput is 
minimal. But I agree that this is the best solution to not touch more 
files with the patch.
> (As written, the driver in the patch still behaves a bit as if it were
> in overrun mode - it clocks the data bits regardless of the command
> response. It looks like you could change this instead without too much
> trouble, but I think supporting overrun is a better idea if possible to
> avoid another special case in the higher layer.)
>

This was true for the bitbang_swd_read_reg(), but not for the 
bitbang_swd_write_reg(). I have fixed that in the last patch as sticky 
bit require a data phase in case of a WAIT response.

Jean-Christian