Re: [OpenOCD-user] SWD transport for sysfsgpio

[Angus G. <gu...@pr...>]

OB1;3603;0cOn Wed, Dec 10, 2014 at 02:34:21AM +0100, Jean-Christian de Rivaz wrote:
> Correct, but using bad and unreliable workaround.
> 
> I have investigated modifications of my patch to resend the last 
> operation when a WAIT response is received. Using an logic analyser that 
> decode SWD protocol I have found that the SAMD21 do not reply to the 
> resent operations and do not reply to the multiple W_ABORT after that. 
> Adding delay up to 100ms after the WAIT response don't change the situation.
> 
> I don't understand why resending the last operation after a WAIT 
> response don't work like mentioned into the "ARM Debug Interface v5® 
> Architecture Specification" document. I am lost here.

Hi Jean-Christian,

Are you able to share the analyzer captures you have that show the
weird behaviour?

The only explanation I can think of for lack of responses is that the
SWD port is out of sync and seeing data protocol errors, which it's
specced to ignore. Maybe issue a line reset?

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.

FWIW I don't much like the workaround for SWD WAIT either (it doesn't
work reliably on nrf51822 under some circumstances), and I've spent a
bit of time trying to find an elegant solution to it (including
discussing it on #openocd IRC a bit, and starting-then-abandoning some
patches). I haven't really made any progress. The only ideas I have
seem to require substantial refactoring of openocd, and I have pretty
quickly run into limits in my own understanding of the wider
architecture (and also limits of available time/resources).

(There's quite possibly a simpler elegant solution I haven't thought
of, though, I'm pretty new to openocd.)


Angus