I'm asking -- and in part, answering -- this question to help
get most folk "on the same page" (as the saying goes) about
this work, which should help future discussions. Feel free
to follow up with corrections and other significant points.
"Serial Wire Debug" (SWD) is a two-wire protocol that ARM
defined in their CoreSight architecture, as an alternative
to JTAG for microcontroller scenarios where pins are scarce.
SWD is implemented by a silicon debug port (DP) component like:
- JTAG-DP ... (except that this only talks JTAG)
- SW-DP ... only talks SWD
- SWJ-DP ... combination of SW-DP and JTAG-DP
Most Cortex-M3 parts use SWJ-DP, but I understand that switching
it out for SW-DP is possible ... no JTAG at all!
Vendors would probably not want to use JTAG-DP on Cortex-M3,
because of something which is only available when using SWD:
"SWO Trace", a lightweight mechanism with just one wire.
(More voluminous ETM based trace options are also available,
but that's more expensive all around.)
I believe SWD works with Cortex-M3 devel boards from Luminary/TI
(all those eval boards bundle FT2232 JTAG), and STM (Primer2 is
evidently SWD-only!); some from NXP; plus surely more to come.
SWD and SWO are usually mapped to JTAG pins as follows, on
both chip packages and JTAG/SWD debug adapters:
- TCK ... becomes SWCLK, same role.
- TMS ... becomes SWDIO, bidirectional data. SWD is
half duplex, with N (configurable) clock turnaround.
- TDO ... usually becomes SWO *if* trace is in use.
One of the encodings it writes can be read by UARTs.
In the same way JTAG has sequences to force TAPs into reset
state, there are magic sequences of TCK/TMS which can force
a SWD-capable debug link out of JTAG mode into SWD mode, and
vice versa.
As for the half-duplex SWD protocol, ignoring multidrop stuff
(I didn't trip over docs for it) it's more or less a series of
two-party transactions like this (many details omitted):
- HOST sends 8-bit command
- TARGET sends 3-bit ack/wait/fault code
- DATA is, optionally, read or written ... 32 bits (+parity)
And the addressible entities are what src/target/arm_adi_v5.c
can address; SWD is coupled to that debug stack. There's some
transfer queueing possible, so hosts can throw a stream of those
transactions at the target then collect status at the end. If
an error is triggered it's usually reported by a "sticky" flag,
which causes other operations to be ignored until it's cleared.
OK, end of brief lesson on SWD (and why it's something OpenOCD
should probably care about).
- Dave
p.s. Relevant specs include ADI v5 arch and DAP-Lite.
_______________________________________________
Openocd-development mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/openocd-development
