JTAG vs SWD

In short: Use full JTAG (IEEE 1149.1) when you need boundary scan, multi-device chains, or deep silicon test access; use 2-wire SWD when you are debugging a single ARM Cortex-M part and want to reclaim two pins and win a little speed — both reach the same CoreSight debug logic underneath.

Ask any embedded or silicon engineer which debug port their board exposes and you will get one of two answers: a 5-pin JTAG header or a 2-pin SWD header. They look like rivals, but on a modern ARM device they are two front doors into the same house. Understanding what each wire actually carries, and where the pins physically go inside the chip, is what separates a candidate who "has used a debugger" from one who can diagnose why a board won't halt. This article walks through both, their shared CoreSight backbone, and a concrete decision rule.

The physical layer: 5 wires versus 2

Classic JTAG defines a Test Access Port (TAP) with up to five signals: TCK (clock), TMS (mode select), TDI (data in), TDO (data out), and optional TRST (test reset). Data is shifted serially, one bit per TCK edge, through either the instruction register or a data register — a dedicated 16-state finite state machine driven entirely by TMS decides which. If you have never traced that FSM, read our companion piece on the JTAG TAP controller state machine; it is the single most-asked JTAG interview topic.

SWD (Serial Wire Debug) collapses that into two wires: SWCLK (clock) and SWDIO (bidirectional data). ARM introduced it precisely because small Cortex-M packages — a QFN-32, say — cannot spare four or five pins just for debug. The SWDIO line is half-duplex: the host and target take turns driving it, with a mandatory one-cycle turnaround to avoid bus contention. That turnaround and the packet framing are the price you pay for saving three pins.

On a 48-pin Cortex-M0+ with ~34 usable GPIO, giving back 3 debug pins by choosing SWD is a ~9% increase in available I/O — often the difference between fitting a peripheral and not.

Where the pins actually go: ARM CoreSight

Here is the insight that unlocks everything: on an ARM Cortex-M or Cortex-A, both ports feed a Debug Access Port (DAP) inside the CoreSight architecture. The DAP contains a SWJ-DP — a combined Serial-Wire/JTAG Debug Port — that auto-detects which protocol the host is speaking and switches between them with a magic bit sequence (the classic 0xE79E 16-bit SWD-to-JTAG, or 0x79E7 the other way). Downstream of the DP sits the APB/AHB Access Ports that bridge onto the chip's internal buses, letting the debugger read memory, set breakpoints via the FPB, and stream trace through the ITM/DWT.

So SWD and JTAG are not two different debuggers — they are two transport encodings for the same register accesses into the same silicon. This is why Keil µVision, OpenOCD, and a SEGGER J-Link can target one device over either wire and give you identical halt/step/watchpoint behaviour.

What only full JTAG can do: boundary scan

SWD debugs the core. It cannot do boundary scan, and that is JTAG's original reason to exist. IEEE 1149.1 places a scan cell on every device I/O pin; by shifting patterns through them you can test solder joints and board interconnect without the chip even running firmware. On a dense BGA you physically cannot probe the balls, so EXTEST/SAMPLE boundary-scan is often the only way to verify the PCB. Tools like Siemens Tessent and the boundary-scan descriptions in a device's BSDL file drive exactly this flow in production test.

JTAG also chains: TDO of one device wires to TDI of the next, so a single header can reach an FPGA, a flash, and an MCU in one daisy chain. SWD addresses one target at a time (SWD multidrop with target IDs exists but is far less common).

Speed, cost, and trace

Raw clock rates are comparable — a J-Link happily runs either at tens of MHz. JTAG moves TDI and TDO in parallel every clock, so for pure bulk register traffic it can edge ahead; SWD loses a cycle to turnaround per transaction but wins on wiring simplicity. For high-bandwidth instruction trace neither matters much: that goes out a separate SWO pin (single-wire, with SWD) or a multi-bit TPIU/ETM trace port (with JTAG), which is a different conversation entirely.

A practical decision rule

Choose SWD when: the target is a single ARM Cortex-M, pins are scarce, and you only need run-control debug plus printf-style SWO trace. This covers the vast majority of STM32, nRF52, and RP2040-class designs. Choose full JTAG when: you need boundary-scan board test, you are chaining an FPGA + MCU + flash, you target non-ARM silicon, or your production line already standardises on BSDL-driven test. Many headers expose both (the 10-pin Cortex Debug connector carries SWD/SWO and JTAG on shared pins), so a smart board layout lets you keep options open. If your team is building test fixtures or bring-up boards, the hardware debug services at Avecas design services can save weeks of header-standardisation pain.

Rule of thumb: if the question is "is my core doing the right thing?" reach for SWD; if it is "is my board built correctly?" you need JTAG boundary scan.

For the deeper CoreSight trace path — ITM, DWT, and the ETM — see our walkthrough on ARM CoreSight trace architecture, which picks up exactly where run-control leaves off.

Want to go from "I've plugged in a debugger" to "I can bring up any board and read a scan chain"? CourseTron's hands-on debug and DFT modules build exactly that muscle — explore the VLSI & embedded courses.

FAQ

Can I convert an SWD-only board to JTAG later?

Only if the MCU physically multiplexes JTAG pins and your header routed them. The SWJ-DP inside most Cortex-M parts supports both, but if the PCB only broke out SWCLK/SWDIO, the other three TAP signals were never routed — you cannot recover them in software.

Does SWD support boundary scan at all?

No. Boundary scan is an IEEE 1149.1 JTAG feature living on the TAP, not the SWD transport. SWD reaches the debug logic but not the boundary-scan register chain around the I/O ring.

Why do SWD and JTAG feel identical in my IDE?

Because above the transport they are. Both deliver DAP register reads/writes into CoreSight, so halt, step, breakpoint, and memory access behave the same regardless of which wires carry the bits.

Is JTAG obsolete for modern microcontrollers?

For field debug of a single ARM part, largely yes — SWD is the default. But for production interconnect test, FPGAs, and multi-chip chains, JTAG remains indispensable and standardised.