SWD vs JTAG: Debug Ports, Connectors and Probes

Illustration

SWD is the Arm debug interface that uses a clock and one data line in place of the larger JTAG port. JTAG, defined by IEEE 1149.1, adds boundary scan and lets several chips share one chain. Use SWD on small Arm Cortex-M boards, and JTAG for boundary scan, chains or chips without SWD.

Every microcontroller board needs a way in for flashing, stepping through code and reading memory. On most Arm Cortex-M parts that way in is SWD or JTAG, and the choice shapes the connector, the probe and the factory programming step. This guide compares the two interfaces, SWO trace, connectors and probes, and how to lock debug access before units ship, with a checklist for the layout review.

This is an engineering summary. Probe specifications and vendor documentation change, so check the linked pages for your exact chip and probe. All sources were read on November 15, 2026.

What is the difference between SWD and JTAG?

JTAG started as a board test interface. SEGGER describes the JTAG test access port as a minimum of three inputs (TDI, TCK and TMS) and one output (TDO), with an optional nTRST input, and it defines the JTAG standard as compliance with IEEE standard 1149.1-2001 (SEGGER JTAG, as of November 2026). The IEEE lists the later revision as IEEE 1149.1-2013, the Standard for Test Access Port and Boundary-Scan Architecture (IEEE SA, as of November 2026).

SWD is Arm's answer for small parts. SEGGER says Serial Wire Debug replaces the traditional 5-pin JTAG debug interface with a 2-pin interface: a clock (SWDCLK) and a single bi-directional data pin (SWDIO). It keeps the normal JTAG debug and test functions, but daisy-chaining devices as with JTAG is not possible (SEGGER SWD, as of November 2026). Arm's CMSIS-DAP documentation says the same from the probe side: a device's Debug Access Port typically uses a 5-pin JTAG or a 2-pin SWD interface (CMSIS-DAP, as of November 2026).

On an Arm part, the practical differences are pin count, chaining and boundary scan. For where firmware sits next to app and cloud code, see firmware vs software vs hardware.

SWD vs JTAG: how do they compare on a real board?

Sourced cells link to the page they came from. Cells without a link are engineering reasoning.

When do you still need JTAG?

Boundary scan for board test

JTAG requires at least two data registers, the bypass register and the boundary-scan register. The boundary-scan register allows testing of board interconnections and access to component inputs and outputs (SEGGER JTAG, as of November 2026). OpenOCD notes that JTAG remains more functional than most other transports and that other transports do not support boundary scan operations (OpenOCD adapters, as of November 2026). If your factory test plan relies on boundary scan to find shorts and opens under BGA parts, the board needs a JTAG port. For how that fits with other factory tests, see in-circuit test vs functional test.

Several chips on one port

OpenOCD describes a scan chain as a daisy chain of TAPs. It requires explicit configuration of every TAP, the order of declaration must match the physical chain, and each TAP needs its instruction register length (OpenOCD TAP declaration, as of November 2026). SWD has its own option for more than one chip: newer SW-DP v2 or SWJ-DP v2 devices support a multi-drop extension, where two or more devices connect to one SWD adapter (OpenOCD adapters, as of November 2026). Check that both the chips and the probe support it before you count on it.

Chips that only speak JTAG

Not every MCU is an Arm part. Espressif says the ESP32-S3 does not support SWD, and that the minimal signalling for a working JTAG connection is TDI, TDO, TCK, TMS and GND (ESP-IDF JTAG debugging, as of November 2026). A product with an Arm MCU and an ESP32-S3 radio chip therefore needs two debug paths, one per chip.

What does SWO trace add?

SWO is an optional pin next to SWD. SEGGER describes it as a dedicated pin that lets the target output data such as printf output via UART or Manchester protocol. It is one-way, so the probe cannot send data back on it. Together, the Instrumentation Trace Macrocell and SWO form the Serial Wire Viewer (SEGGER SWO, as of November 2026).

Three limits matter in practice. Not all targets that support SWD also support SWO. On most Cortex-M devices the SWO clock is derived 1/1 from the CPU core clock, so the tool needs the core clock that applies after startup. And J-Link software currently supports only the UART protocol on SWO (SEGGER SWO, as of November 2026). Engineering reasoning: route SWO even if the first firmware does not use it, because adding a pin later means a board spin.

Which debug connector should the board use?

Arm 10-pin and 20-pin Cortex debug connectors

Arm's connector note says the Cortex Debug Connector has only 10 pins and supports JTAG debug, Serial Wire debug and Serial Wire Viewer through the SWO connection. The pins are VCC, SWDIO/TMS, SWDCLK/TCK, SWO/TDO, NC/TDI, nRESET, GNDDetect, a key position and grounds. The Cortex Debug+ETM Connector has 20 pins and adds the trace clock and four trace data lines (Arm Cortex-M debug connectors, as of November 2026).

Keil lists the 10-pin connector as a Samtec FTSH-105-01-L-DV-007-K with dimensions of 6.35mm x 4.78mm. Position 7 has no pin and serves only as a key. The first 10 pins of the 20-pin connector are identical to the 10-pin one (Keil ULINKpro connectors, as of November 2026). The older 20-pin JTAG connector used by J-Link is a keyed box header at 2.54mm (SEGGER 20-pin connector, as of November 2026). Arm's note says 20-pin IDC connectors are too big for today's microcontroller boards (Arm Cortex-M debug connectors, as of November 2026).

Spring-pin footprints with no header

A connector costs space and height. Tag-Connect cables press spring pins onto a footprint of pads and locating holes, with no mating connector on the board. Its no-legs footprint takes only 0.03 square inches, the spring pins are rated for over 100,000 operations, and the cable can be held in place with a TC2050-CLIP board (Tag-Connect TC2050-IDC-NL, as of November 2026). Engineering reasoning: on a small wearable, a pad footprint like this is often the only debug access that fits, so place it before the layout fills up.

Power reference and reset

SEGGER describes VTref as the target reference voltage, which the probe uses to detect target power and set logic levels. Pin 19 of its 20-pin connector can supply the target at 5V with a max. current of 300mA (SEGGER 20-pin connector, as of November 2026). On reset, OpenOCD separates SRST, which resets all chips connected to the adapter, from TRST, which resets only the TAP controllers. It notes that some boards do not wire SRST or TRST to the connector, and that missing TRST is not a problem because JTAG resets can use TMS signaling (OpenOCD reset configuration, as of November 2026). Engineering reasoning: route nRESET anyway, so a probe can still connect when firmware has put the chip to sleep or reused the debug pins.

Which debug probe fits: CMSIS-DAP, J-Link, ST-LINK or ESP32 USB-JTAG?

CMSIS-DAP is Arm's open firmware standard for a debug unit that connects the debug port to USB. Arm says CMSIS-DAP v1.x is deprecated, and v2.x provides high-speed SWO trace streaming and does not require driver installation on Mac OS, Linux or Windows. A CMSIS-DAP debug unit may also be integrated on an evaluation board (CMSIS-DAP, as of November 2026).

SEGGER J-Link is a commercial probe family. SEGGER lists a max. target interface speed of 50 MHz for J-Link Ultra and Pro and 15 MHz for J-Link BASE and PLUS, max. SWO speed of 100 MHz and 30 MHz, and supported target voltage of 1.2 V - 5 V across the range (SEGGER J-Link model overview, as of November 2026).

ST-LINK adapters serve the STM32 families. OpenOCD supports ST-LINK/V2, STLINK-V3 and STLINK-V3PWR through its st-link driver (OpenOCD adapters, as of November 2026). Espressif warns that JTAG adapters hardcoded to one product line, such as ST-LINK adapters for STM32 families, will not work with the ESP32-S3 (ESP-IDF JTAG debugging, as of November 2026).

The ESP32-S3 has its own built-in JTAG circuitry and can be debugged with only a USB cable on GPIO19 (D-) and GPIO20 (D+) (ESP-IDF built-in JTAG, as of November 2026). To use an external adapter, you burn the DIS_USB_JTAG eFuse, which moves JTAG to GPIO39-GPIO42, or the STRAP_JTAG_SEL eFuse, which lets GPIO3 pick the interface at reset. Espressif warns that burning eFuses is irreversible (ESP-IDF external JTAG, as of November 2026). For how the ESP32 variants differ beyond debug, see ESP32-C3 vs S3 vs C6.

Probe speed is only half the limit. OpenOCD notes that chip data sheets generally include a top JTAG clock rate, and the speed it uses will not be faster than the one you set (OpenOCD adapters, as of November 2026). Engineering reasoning: long flying leads and level shifters lower the usable clock as well, so test at the speed the factory fixture will run.

How does the debug port serve production programming?

The same port usually loads firmware in the factory. OpenOCD's program command shows the typical steps: reset and halt the target, erase and write flash from the image file, optionally verify the image, optionally reset, then exit (OpenOCD flash programming, as of November 2026).

SEGGER's representative production sequence programs the images, provisions identity and credentials, runs the tests that need full access, then applies the debug restriction, power cycles and checks that unauthenticated debug access is rejected. SEGGER adds that locking should be the last step that needs unrestricted debug access, and that a unit whose locked state has not been confirmed should not ship (SEGGER MCU security options, as of November 2026). For the wider build, test and release loop, see the embedded programming workflow for connected device firmware.

How do you lock debug access before shipping?

An open debug port lets anyone with a probe read the firmware and secrets. SEGGER explains that JTAG and SWD can halt the CPU, inspect or change memory, and program flash. MCUs may restrict readback, disable access ports or close the debug interface, through option bytes, fuses or a lifecycle state. Some protections can be removed only by a device erase, and others are irreversible for normal service, such as STM32 RDP Level 2 (SEGGER MCU security options, as of November 2026).

• STM32: OpenOCD's stm32f1x unlock command causes a mass erase of the entire device if it was locked, and its stm32lx notes say RDP Level 2 can't be unlocked at all (OpenOCD flash commands, as of November 2026).
• Nordic nRF: Zephyr's NRF_APPROTECT_LOCK option makes SystemInit() lock the AP-Protect mechanism, which permanently prevents debugger access. Only the ERASEALL operation through CTRL-AP can restore it (Zephyr Nordic Kconfig, as of November 2026).
• ESP32-S3: Espressif says the JTAG interface stays disabled if any of the security features are enabled, and can also be disabled through the eFuse API. The ESP32-S3 also supports soft disabling of JTAG, re-enabled with a secret key through HMAC (ESP-IDF security overview, as of November 2026).

Decide the service path before you lock. SEGGER advises deciding at design time whether service should preserve firmware and data, and evaluating the MCU's authorized debug facilities where data must survive failure analysis (SEGGER MCU security options, as of November 2026). Debug locking works alongside signed images, so read secure boot and signed firmware for small devices as well.

What should the board layout review check?

Bring this list to the schematic and layout review, before the debug pins are fixed.

• Is SWDIO pulled up on the target, and is SWCLK held at a defined level (SEGGER SWD, as of November 2026)?
• Does the connector carry the target supply on the VTref pin, so the probe can match logic levels (SEGGER 20-pin connector, as of November 2026)?
• Is nRESET routed to the connector, and is the probe configured to know whether SRST and TRST are wired?
• Is the SWO pin routed, and does the firmware set up the trace clock that the probe expects?
• Do the programming pads sit where a fixture or a spring-pin cable can reach them with the enclosure open?
• If several chips share one JTAG chain, does the firmware team have the order and IR length of every TAP?
• Is the debug lock step in the production flow, and is there a test that proves the lock took effect?
• Is the recovery path written down, including what a mass erase deletes?

For how firmware work, debug access and source handover are organized in a project, see firmware development.

If you are planning debug and programming access for a custom board, tell us about your device.

Sources. All pages accessed November 15, 2026. Probe specifications and chip security features change between revisions, so confirm current values for your exact part.

• SEGGER Knowledge Base, Target Interface SWD (link)
• SEGGER Knowledge Base, JTAG (link)
• SEGGER Knowledge Base, SWO (link)
• SEGGER Knowledge Base, MCU Security Options (link)
• SEGGER Knowledge Base, 20-pin J-Link Connector (link)
• SEGGER, J-Link model overview (link)
• IEEE SA, IEEE 1149.1-2013 Standard for Test Access Port and Boundary-Scan Architecture (link)
• Arm, CMSIS-DAP documentation (link)
• Arm, Cortex-M Debug Connectors (link)
• Keil, ULINKpro CoreSight connectors (link)
• OpenOCD User's Guide, Debug Adapter Configuration (link)
• OpenOCD User's Guide, TAP Declaration (link)
• OpenOCD User's Guide, Reset Configuration (link)
• OpenOCD User's Guide, Flash Programming (link)
• OpenOCD User's Guide, Flash Commands (link)
• Espressif, ESP-IDF JTAG debugging, ESP32-S3 stable (link)
• Espressif, ESP-IDF configure ESP32-S3 built-in JTAG interface (link)
• Espressif, ESP-IDF configure other JTAG interfaces, ESP32-S3 (link)
• Espressif, ESP-IDF security overview, ESP32-S3 (link)
• Tag-Connect, TC2050-IDC-NL 10-pin no-legs cable (link)
• Zephyr Project, soc/nordic/Kconfig (link)