On Saturday 14 November 2009, Andrew Rogers wrote:
> SWD is not finished yet, a long way to go. Adding the actual hardware
> drivers is a almost the last thing on my list. I want to get the
> framework in place first.
I don't entirely agree about "almost the last thing", since that
can make incremental testing painful. On the other hand, "framework
first" is reasonably correct, within limits: coding with no design
is A Very Bad Thing!
My development often features incremental testing, bottom up, and
allow for some "whoops, this means the upper layers have to work a
bit differently..." By the time I get to actual coding, the basic
shape is pretty well known, and modules get tested as they're written.
(I'm sure there's some recent buzzword/fad covering that approach.)
I don't see anything wrong with getting the hardware interfaces
done early, so we can know that they work for the JTAG/SWD adapters
(or SWD-only adapters) we want to support. (I think that set is at
least: the Raisonance stuff you're working with, Versaloon which
Simon is using, and the Stellaris eval boards.)
That said ... what you seem to have here is fairly close to the
level I'd want to start: the upper level interface to the link
hardware, including lifecycle. And it's true that there should
be a focus on the debug link, which need not specifically be JTAG;
some renaming may be appropriate, to stop assuming JTAG-only.
(Other links that have come up include various ISP flavors like the
SPI stuff used to program AVRs, and even ASCII protocols that are
used to talk to some JTAG adapters which embed propietary knowledge
of various chips. Those aren't IMO near-term concerns.)
> What I have done is to get a SWD interface listed when you use 'openocd
> -c interface_list'. There's a new struct (interface_base_t) added that
> holds the interface type and name. The global variable
> 'chosen_interface' is type cast to 'jtag_interface_t *' or
> 'swd_interface_t *' as needed.
As I said elsewhere, I'd be a lot more comfortable with just seeing
SWD vs JTAG as a "mode" of an existing debug link (JTAG/SWD adapter).
That matches the usage of all the hardware I happen to have seen so
far, and also ARM's documentation about how to switch from JTAG to
SWD and vice versa.
Of course ... there's this little problem where the other end of
a JTAG link is a series of TAPs, while the other end of a SWD link
is a single non-JTAG target. I suppose we'll have to fake that out
somehow, to start with.
> A new function called 'interface_init' is added that calls either
> 'jtag_interface_init' or 'swd_interface_init' as determined from the
> 'type' element in 'chosen_interface'.
Likewise, since the hardware is supposed to allow mode switching,
I'd just have "switch mode" operations. Upper level code would
handle various nuances. For example, the notion of recovering
from SWD loss-of-synch by going through the reset-to-SWD sequence
would sit there ... including do so as a part of switching from
JTAG to SWD modes, which looks something like:
- Poke the signal routing so SWD works;
- Reset-to-SWD sequence ... issue:
* 50+ clocks with TMS high,
* the magic TMS sequence,
* (again) 50+ clocks with TMS high,
* a read of IDCODE
- Verify it all worked right, including the right IDCODE
And the converse, to switch from SWD to JTAG. Because of the
requirement to read IDCODE, much of that logic probably belongs
somewhere in the ADIv5 code ... I'm not entirely sure how that
should be structured though. It seems to inherently call for
a small bit of layering violation: IDCODE is associated with a
debug target of some kind. Hmm. That also complicates any
notion of autoprobing too.
- Dave
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
