What is SWD? Serial Wire Debug Explained

SWD in 30 seconds

Serial Wire Debug (SWD) is a debug and programming interface for ARM processors. It uses just two signal wires — SWDIO (data) and SWCLK (clock) — to give a debug probe full access to the processor's memory, registers, and peripherals.

With SWD, you can:

Flash firmware into the chip's flash memory
Set breakpoints and step through code
Read and write RAM, registers, and peripheral registers in real time
Halt and reset the processor
Read the chip's unique ID and security state

SWD is supported by virtually every ARM Cortex-M microcontroller — STM32, nRF52, RP2040, SAMD, LPC, EFM32, AT32, and hundreds of others. If you're working with a Cortex-M chip, SWD is almost certainly available.

The SWD signals

Only two wires are required. A third (reset) is optional but recommended.

SWDIO — Serial Wire Data I/O

Bidirectional data line. The probe and target take turns driving it (half-duplex). Carries commands, addresses, and data. Directly connected to a GPIO on the debug probe.

SWCLK — Serial Wire Clock

Clock signal driven by the probe. Typical speeds: 1-50 MHz depending on the probe and target. The target samples SWDIO on clock edges. Directly connected to a GPIO on the debug probe.

nRST — Reset (optional)

Active-low reset line. Lets the probe hard-reset the target. Not strictly required for SWD, but essential for recovering locked chips or targets in a bad state. Open-drain with a pull-up on the target.

How SWD works

SWD is a packet-based protocol. The debug probe (host) sends a request packet, and the target responds with an acknowledge + data. Everything happens over the single SWDIO line, clocked by SWCLK.

A typical SWD transaction

Request phase — the probe drives 8 bits onto SWDIO: start bit, access type (Debug Port or Access Port), read/write flag, 2-bit register address, parity, stop, park.
Turnaround — one clock cycle where neither side drives SWDIO (bus changes direction).
Acknowledge phase — the target drives 3 bits: OK (001), WAIT (010), or FAULT (100).
Data phase — 32 bits of data + 1 parity bit. For a read, the target drives it. For a write, the probe drives it after another turnaround.

Debug Port vs Access Port

SWD has a two-layer architecture:

DP (Debug Port) — the SWD-specific layer. Handles protocol control, status, and ID registers. The DP is what you talk to first.
AP (Access Port) — the memory access layer. The MEM-AP lets you read/write any address in the target's memory map. This is how you access flash, RAM, and peripherals.

When you "flash firmware over SWD", you're sending write transactions through the MEM-AP to the flash controller's registers, which then programs the data into flash memory. When you "set a breakpoint", you're writing to the breakpoint comparator registers in the debug unit (also memory-mapped).

Clock speed

SWD clock speed is set by the probe. Common values:

1-4 MHz — safe default, works with long wires and noisy setups
10-20 MHz — typical for short connections (< 10 cm)
24-50 MHz — fast probes (J-Link) with good signal integrity

Higher clock = faster flashing, but the target chip's SWD peripheral has a maximum supported frequency (check the datasheet). Wire length and capacitance matter at higher speeds.

SWD vs JTAG

JTAG came first. It uses 4 signals (TCK, TMS, TDI, TDO) plus an optional reset (TRST). SWD was designed by ARM as a lighter alternative specifically for Cortex-M devices.

Aspect	JTAG	SWD
Signal count	4 + optional reset	2 + optional reset
Pin sharing	Dedicated pins	SWDIO/SWCLK share pins with JTAG TMS/TCK
Daisy-chain	Yes (scan chain)	No — point-to-point only
Debug access	Full (via DAP)	Full (via DAP) — same debug unit
Boundary scan	Yes	No
Multi-core	Via scan chain	Via multi-drop SWD (ARM ADIv6)
Cortex-M support	Yes	Yes
Cortex-A/R support	Yes	Some newer chips

Bottom line: For Cortex-M work, SWD is the standard. Fewer wires, same debug capability. JTAG is still used for Cortex-A, multi-chip boundary scan, and legacy devices. Most modern Cortex-M chips share the SWD and JTAG pins, so the same physical connector supports both — the probe auto-detects or you select the protocol.

The SWD connector

Standard pinouts

ARM defines two standard SWD/JTAG connectors:

10-pin Cortex Debug Connector (1.27 mm pitch):

1 VCC	2 SWDIO/TMS
3 GND	4 SWCLK/TCK
5 GND	6 SWO/TDO
7 KEY (no pin)	8 TDI
9 GND	10 nRESET

20-pin legacy JTAG (2.54 mm pitch): The older, larger connector. Still used on evaluation boards and older designs. Carries the same signals plus a few extras. Many probes ship with both connectors or an adapter.

Minimum wiring for SWD

If you're just wiring up to test pads or a custom connector, you only need:

SWDIO — data
SWCLK — clock
GND — ground reference (essential — don't skip this)
VCC — target voltage reference (so the probe knows the target's logic level)
nRST — optional but highly recommended for recovery

Common SWD software tools

A debug probe is only useful with software that talks to it. The main open-source and commercial tools:

Open source

OpenOCD — the venerable open-source debug server. Supports nearly every probe and target. GDB interface. Some rough edges but extremely capable. Command-line driven, scriptable with Tcl.
pyOCD — Python-based debug tool by ARM. Specifically designed for Cortex-M. Clean API, good CMSIS-DAP support. Excellent for scripting and CI/CD. pip install pyocd and go.
probe-rs — Rust-based. Modern, fast, growing quickly. Native CMSIS-DAP and J-Link support. Includes a flash algorithm system that supports hundreds of targets. cargo install probe-rs.

Commercial

SEGGER J-Link Software — J-Link GDB Server, J-Flash, Ozone debugger. Best-in-class for J-Link probes. Free for education, licensed for commercial. The benchmark for flash speed and reliability.
Keil MDK / IAR — full IDE with integrated debug. Support most probes. Expensive per-seat licensing.
STM32CubeProgrammer — free ST tool for STM32 targets. Works with ST-Link. Useful but ST-only.

IDE integration

All modern embedded IDEs support SWD debugging: VS Code (via cortex-debug extension), CLion, Eclipse CDT, Keil µVision, IAR Embedded Workbench, and Segger Embedded Studio. The IDE typically talks to a GDB server (OpenOCD, pyOCD, J-Link GDB Server) which talks to the probe.

Using SWD in production

SWD isn't just for development. It's the standard interface for production programming and in-circuit testing of ARM devices.

Production programming

A production programmer connects to the target via SWD, erases flash, programs the firmware image, verifies the contents, and optionally sets read-out protection (security bits). This takes 1-10 seconds per device depending on image size and flash speed.

Production testing over SWD

Beyond flashing, SWD gives you real-time access to the target's memory map. A test script can:

Read ADC values to verify analog front-end calibration
Write to GPIO control registers to toggle pins and verify connectivity
Read peripheral status registers to confirm a sensor is responding on I2C
Check unique device ID for serial number traceability
Measure current consumption by power-cycling through SWD-triggered sleep modes

This is where SWD goes beyond what a simple UART bootloader can do. The test system has full visibility into the target without the target needing any test-specific firmware.

Scaling up: multi-target SWD

When you need to flash and test many boards in parallel, you need multiple independent SWD connections. Each target gets its own probe (or probe channel). The host software orchestrates all channels simultaneously.

This is the domain of gang programmers (flash only) and dedicated test farms (flash + test + verify). Learn more about multi-target testing →