JTAG (IEEE 1149.1, named after the Joint Test Action Group that created the standard) is a serial interface and protocol originally designed for boundary-scan testing of PCB interconnects, and now widely used for in-circuit programming and debugging of microcontrollers, FPGAs, CPLDs, and other digital ICs.
In practice
JTAG uses four mandatory signals -- TCK (clock), TMS (mode select), TDI (data in), and TDO (data out) -- plus an optional TRST (reset). Devices are wired in a daisy-chain, forming a scan chain that allows a host to shift data through all connected devices. A state machine, advanced by TMS pulses on TCK, controls whether the chain accesses the instruction register, a data register, or the boundary-scan cells at each pin. A typical debug adapter (J-Link, ST-LINK, CMSIS-DAP probe) drives these signals and translates them to USB on the host side, though adapters vary in their transport implementations and target-side buffering.
For ARM Cortex-M and Cortex-A based MCUs and SoCs -- including STM32, LPC, i.MX, and Zynq parts -- JTAG typically provides access to CoreSight debug infrastructure, allowing a debugger such as GDB via OpenOCD to set breakpoints, inspect registers, and read or write memory while the core is halted or running, though the specific CoreSight features exposed vary by device and vendor. Many of the same adapters also support ARM's 2-wire SWD alternative. For FPGAs and CPLDs from Intel/Altera, Xilinx/AMD, Lattice, and Microchip/Microsemi, JTAG is the standard path for bitstream programming and in-system flash updates, and is central to projects like those discussed in "FPGA Assemblers and Time Machines."
JTAG is not universal across all MCU families. Many 8-bit and lower-cost MCUs (PIC, AVR, many STM8 parts) use proprietary 2-wire or single-wire interfaces (ICSP, debugWIRE, SWIM) for programming and debugging rather than full JTAG. Some devices implement a JTAG port only for boundary-scan compliance without exposing a debug port through it.
A common pitfall is pin conflict: on many MCUs the JTAG pins are shared with GPIO, and firmware that reconfigures those pins as outputs early in startup can lock out the debugger. Recovering usually requires triggering a factory reset through a vendor-specific mechanism or, on some parts, asserting TRST before the firmware has a chance to run. Multi-device scan chains add another layer of complexity -- each device's IR length must be declared to the debug tool so it can correctly address individual devices.
Frequently asked
What is the difference between JTAG and SWD?
SWD (Serial Wire Debug) is a 2-pin ARM-proprietary alternative to JTAG for debug access on Cortex-M and some Cortex-A cores. It uses SWDIO and SWDCLK instead of the four JTAG signals, saving pins on small packages. SWD provides the same register and memory access as JTAG but does not support boundary-scan or daisy-chained scan chains. Most ARM debug probes support both interfaces; FPGAs and non-ARM devices generally use JTAG only.
Can I program flash memory over JTAG?
On many ARM MCUs (STM32, LPC, SAM, nRF5x, etc.) and virtually all FPGAs and CPLDs, yes. The debug probe uses JTAG (or SWD on ARM) to halt the core, download a flash programming algorithm into RAM, and execute it. On FPGAs, the JTAG port typically connects directly to a dedicated configuration controller rather than going through a CPU, so
bitstream programming does not require a running CPU at all.
Why does my debugger lose connection after my firmware starts?
This is usually a pin-mux conflict. On many MCUs, the JTAG/SWD pins default to debug function after reset but can be reassigned to GPIO by firmware. If your startup code or a peripheral driver reconfigures those pins before the debugger attaches, the debug connection is severed. The fix is to avoid remapping debug pins unless truly necessary, or to connect the debugger and halt the core before it reaches that code.
What is boundary scan and how does it relate to JTAG?
Boundary scan is the original purpose of IEEE 1149.1. Each JTAG-compliant IC contains a shift register of cells wired to its I/O pins. By shifting data through the chain, automated test equipment can drive and observe pin states to test solder joints and board interconnects without physical probing. Most embedded developers only use JTAG for programming and debug, but the same physical interface and protocol underlie both uses.
How do I handle a multi-device JTAG scan chain?
Each device in the chain has an instruction register of a specific length (e.g., 4 bits for many ARM CoreSight devices, varying for FPGAs). Your debug tool must know the IR length of every device in the chain so it can properly frame instructions to the target device while holding others in bypass mode. OpenOCD, for example, requires you to list each device's IR length in the configuration. Mismatches cause garbled communication and are a common source of frustration on boards with a
CPLD and an MCU sharing one chain.
Differentiators vs similar concepts
JTAG is often compared to SWD (Serial Wire Debug). SWD is a 2-pin ARM-proprietary protocol that provides the same CPU debug and memory access as JTAG on Cortex-M and some Cortex-A cores, but does not support boundary-scan or multi-device scan chains. JTAG requires four pins (TCK, TMS, TDI, TDO) and is vendor-neutral and chip-family-agnostic; it is the standard interface for FPGAs, CPLDs, and most non-ARM devices, though some support additional or alternate programming and debug paths. JTAG is also distinct from ISP/ICSP, debugWIRE, and SWIM, which are proprietary single- or two-wire interfaces used on PIC, AVR, and STM8 parts respectively for the same programming and debug tasks but with different physical and protocol layers.
