Serial Wire Debug (SWD) is a two-wire debug and programming interface defined by ARM as part of the CoreSight debug architecture, used to access the debug and memory resources of ARM Cortex-M and related ARM processors. It provides debug access comparable to JTAG over fewer pins -- one bidirectional data line (SWDIO) and one clock line (SWCLK), plus an optional trace output pin (SWO) -- though JTAG retains capabilities such as multi-device scan chaining that SWD does not support.
In practice
SWD is a widely used debug interface on ARM Cortex-M microcontrollers, though JTAG remains common on some parts and board designs. Devices from vendors such as STMicroelectronics (STM32), Nordic Semiconductor (nRF52/nRF53 series), NXP (Kinetis, LPC), Microchip (SAM), and many others expose SWD as their primary or only debug port. Many low-cost debug probes -- including the ST-LINK, J-Link, CMSIS-DAP-based probes (DAPLink, Picoprobe), and Black Magic Probe -- support SWD natively.
In practice, SWD connects an IDE or command-line tool (OpenOCD, pyOCD, J-Link Commander) to the target to perform flash programming, breakpoints, watchpoints, register inspection, and live memory reads. Because only two mandatory signal lines are required, SWD is especially common on space-constrained boards where dedicating four or five pins to a full JTAG header is impractical. Many designs expose SWD as a minimal two-pad or three-pad test point rather than a full connector.
The optional Serial Wire Output (SWO) pin extends SWD to support non-intrusive trace. When connected, SWO carries ITM (Instrumentation Trace Macrocell) data -- typically used for printf-style trace output or event logging -- without halting the CPU. Not all debug probes support SWO, and not all Cortex-M variants include an ITM; many Cortex-M0/M0+ implementations, for example, omit the ITM, though trace feature availability can vary by vendor and specific core configuration.
A common pitfall is leaving SWD pins reassigned to GPIO in firmware without first providing a way to re-enter debug mode. On some STM32 devices, if the SWD pins are reconfigured as GPIO early in startup, the chip can become temporarily unreachable by a probe unless a specific entry sequence or button-hold is implemented. Another pitfall is sharing SWDIO/SWCLK with application circuitry: bus contention from pull resistors or external drivers can prevent reliable debug connections.
Frequently asked
What is the difference between SWD and JTAG?
JTAG uses a four-wire interface (TCK, TMS, TDI, TDO, plus an optional nTRST reset line) and supports chaining multiple devices on one scan chain. SWD uses two wires (SWDIO, SWCLK) and connects to a single device. On ARM Cortex-M parts, both interfaces reach the same Debug Access Port (DAP), so
flash programming and debugging capabilities are equivalent in practice. JTAG is generally preferred when multiple chips need to share one debug chain; SWD is preferred when pin count is tight.
Can SWD be used to program flash, or is it only for debugging?
SWD provides full access to the target's memory map, including
flash. Debug probes and tools such as
OpenOCD, pyOCD, and J-Link Commander use SWD to erase and program flash by writing through the DAP -- no separate programming interface is required on most ARM Cortex-M devices.
What is SWO, and do I need it?
SWO (Serial Wire Output) is an optional third pin that carries asynchronous trace data from the ITM. It is commonly used as a low-overhead alternative to a
UART for debug logging: the ITM stimulus
registers accept 8, 16, or 32-bit writes, which are transmitted over SWO at a configurable
baud rate. SWO is not required for programming or interactive debugging; it only adds value when non-intrusive trace output is needed. Note that many Cortex-M0 and M0+ implementations do not include the ITM, so SWO availability on those devices depends on the specific vendor and core configuration.
What clock speed should I use for SWD?
Maximum reliable SWD clock frequency depends on the target
MCU, the probe, cable length, and signal integrity. Many Cortex-M devices support SWD clocks of several MHz; J-Link probes commonly default to 4 MHz and can go higher on short, clean connections. A conservative starting point is 1 MHz, which works reliably across most setups. If connection errors occur, reducing the clock is the first thing to try.
My device is no longer reachable over SWD after a firmware update -- what happened?
This typically happens when firmware reassigns the SWDIO or SWCLK pins to
GPIO or a peripheral, or when a misconfigured option byte disables the debug port. Recovery options vary by vendor. On many STM32 devices, holding a specific GPIO low during reset can force the
bootloader to run, after which the debug port may be reachable. On some devices, a brief window exists at reset before the application runs where the probe can halt the CPU before pin remapping takes effect --
OpenOCD's 'reset halt' or J-Link's 'Connect under reset' mode exploits this window.
Differentiators vs similar concepts
SWD is often compared to
JTAG, which it was designed to partially replace on ARM targets. The core distinction is pin count: SWD uses two mandatory pins versus JTAG's four, at the cost of losing multi-device daisy-chain support. Both interfaces reach the same ARM Debug Access Port on Cortex-M devices, so their programming and debugging capabilities are functionally equivalent for single-chip designs. SWD is also sometimes confused with SWO: SWD is the bidirectional debug interface (SWDIO + SWCLK), while SWO is a separate unidirectional trace output pin that is optional and supplementary to SWD.
