Debug Access: JTAG, Debug Ports and Scan Dump

Every debug feature on a chip is reached through a debug port: a handful of pins through which an external debugger sends commands and reads results. The most common is the JTAG test access port, originally designed for testing boards and now used on almost every chip for debug as well.

Behind the port, a debug access controller turns those commands into reads and writes of registers, memory and debug units, and can switch the chip into a mode where its whole internal state is shifted out through the scan chains. This article explains the common debug interfaces, how JTAG works, how a debugger reaches the inside of a modern chip, and what a scan dump is.

8 min read | Intermediate

What You'll Learn

• Compare the JTAG, serial wire and single-wire debug interfaces
• Describe the parts of a JTAG test access port
• Explain how a debug access port reaches buses and debug units
• Explain what a scan dump captures and what it costs

Three Kinds of Debug Interface

All of them carry the same kind of traffic: commands to halt and run, read and write registers and memory, set breakpoints, and configure trace. They differ in pin count and speed. Many chips offer both JTAG and SWD on shared pins and let the debugger choose.

How JTAG Works

JTAG is the common name of the IEEE 1149.1 standard for a test access port and boundary-scan architecture. Its parts:

• Four pins: test clock (TCK), test mode select (TMS), test data in (TDI) and test data out (TDO), plus an optional asynchronous reset (TRST).
• A TAP controller: a small state machine stepped by TMS on each rising edge of TCK, with states for shifting an instruction or data, capturing values and updating registers.
• An instruction register of at least two bits, holding the current instruction.
• Data registers, of which exactly one is connected between TDI and TDO at a time, chosen by the instruction: a one-bit bypass register, an optional 32-bit identification code register, the boundary-scan register formed by cells on the chip's pins, and any number of chip-specific registers.

The standard defines mandatory instructions such as BYPASS, EXTEST and SAMPLE for board test, and allows designers to add their own. That openness is what made JTAG the universal debug port: designers add instructions to load a breakpoint counter, capture key registers into a shadow copy, override registers, or switch the chip into scan dump mode. Because every chip on a board can be chained TDI to TDO, one connector can reach all of them.

JTAG is slow compared with the chip: TCK typically runs at a few to a few tens of megahertz while the chip runs at hundreds of megahertz or gigahertz, and every bit passes serially. It is ideal for control and for reading small amounts of data, not for streaming what the chip is doing in real time. That is the job of trace.

Reaching the Inside of a Modern Chip

A system-on-chip has many processor cores, buses and debug components. Connecting each to its own JTAG register would be unwieldy, so modern debug architectures put a debug access port behind the pins. In ARM's CoreSight architecture, for example:

• A debug port receives commands from JTAG or SWD.
• It turns them into transactions on an internal debug bus, addressed to access ports.
• Access ports act as bus masters on the chip's buses: one reaches the system bus and therefore memory and peripherals, another the debug bus with each core's debug registers, another can drive an internal JTAG chain.
• A ROM table lists the addresses of all debug components, so a debugger can discover what the chip contains without being told.

With this arrangement, a debugger reads a core's registers or a memory location as ordinary bus accesses, at the speed of the debug link. A widely used ARM application core describes the two classic ways of using its debug logic: external debug, where the core is halted with breakpoints and watchpoints and examined through the debug connection, and self-hosted debug, where a debug monitor running on the core itself does the work while the core keeps running.

Scan Dump

Breakpoints and register reads show the state the designers chose to make visible. A scan dump shows nearly all of it. The chip's flip-flops are already connected into scan chains for manufacturing test, so for debug:

1. A trigger stops the functional clocks at a chosen moment, freezing every flip-flop.
2. The flip-flops are switched into scan mode, forming shift registers.
3. Their contents are shifted out, through the debug port or test pins, and stored on the host.
4. A tool maps every bit back to its flip-flop name in the netlist, so engineers can read the complete state of the chip, register by register, as if it were a simulation waveform at one instant.

A scan dump is usually destructive: shifting moves every value, so the chip cannot simply continue afterwards and is reset. It also takes time.

Assume a chip with 4 million scanned flip-flops shifted out through one serial path at 10 MHz: the dump takes 4,000,000 / 10,000,000 = 0.4 seconds. That is fine for a one-time snapshot of a hang, and far too slow to record activity, so dumps and trace complement each other.

Memories are not in the scan chains. Some chips add array dump features that read out caches and other memories through the debug port after the clocks stop, because the contents of a cache are often exactly what a debug engineer needs.

In Practice

Bring-up often begins with the debug port alone. Before any software runs, engineers check that the JTAG identification register reads back the expected code, which proves that power, the test clock and the TAP controller work.

Then they use the debug access port to read and write internal registers and memory, load code into on-chip memory and start a core. If the debug port does not respond, very little else can be learned, which is why its pins, clock and power are among the most carefully checked parts of a design.

Common Mistakes