Articles

JTAG Interview Questions: TAP States, Scan Chains, and Debug Connection Failures

Practice JTAG interview questions with TAP scan traces, two-device bit calculations, and evidence-led diagnosis of ID mismatches and debug connection failures.

You have the board, probe, and firmware ready, but the debugger reports an invalid device ID. You lower the clock and reconnect, but the processor still will not halt. JTAG interview questions ask whether you can explain what each observation proves: an electrical path, a valid scan, the intended device, or usable debug access.

Start with one distinction: a working scan chain is necessary evidence, but it does not prove that a processor is ready for debugging. This guide works through TAP transitions, a two-device bit ledger, and a connection diagnosis. Official protocol and tool behavior is linked where introduced. The numerical examples are original exercises, not measurements from a physical board.

What does the TAP controller actually control?

The Test Access Port controller selects how test logic captures, shifts, pauses, and updates information. TCK provides the clock; TMS steers the state transitions; TDI enters the serial path; TDO returns serial data. TRST, when present, resets test logic. It is different from a system-reset signal.

For an official implementation reference, TI's TM4C1294NCPDT data sheet shows the conventional 16-state TAP diagram and describes resetting it by holding TMS high for five TCK cycles. Treat that as TAP synchronization, not a promise that the application processor, memories, peripherals, or board power were reset.

An interview answer should connect three actions. Capture loads an observation into a selected shift path. Shift exchanges serial bits. Update makes the scanned value available to the relevant update stage. A controller state alone does not tell you which internal register is selected: the active instruction matters.

If asked to draw every state, start with Test-Logic-Reset and Run-Test/Idle, then draw the DR and IR branches. Each branch has Capture, Shift, Exit1, Pause, Exit2, and Update. Explain the decisions at the branches rather than reciting the names. The interviewer can then change one TMS bit and ask you to predict the resulting path.

Work a scan without losing its final bit

This original trace starts in Run-Test/Idle and loads a four-bit instruction. The four-bit opcode is fictional; use the actual device documentation before issuing an instruction to hardware.

Clocked TMS sequence	Resulting state or action
`1, 1, 0, 0`	Select-DR, Select-IR, Capture-IR, then Shift-IR
`0, 0, 0` while shifting	Exchange the first three instruction bits and stay in Shift-IR
`1` on the fourth shift clock	Exchange the final bit and leave Shift-IR for Exit1-IR
`1, 0`	Reach Update-IR, then Run-Test/Idle

The important follow-up is whether the fourth bit requires TMS to remain low. In this exercise it does not: the clock that exits Shift-IR also exchanges the last bit. Adding an extra shift clock changes the data; leaving before that clock truncates it. State clearly whether your trace names the state before or after each edge so two otherwise correct descriptions do not appear to disagree.

The analogous entry path to Shift-DR from idle is 1, 0, 0. Pausing a scan also differs from updating it: Exit1 can lead into Pause, and Exit2 can return to Shift. In a whiteboard exercise, track both the controller state and the number of bits already exchanged. That exposes an off-by-one error faster than a drawing with unlabeled arrows.

Why do IR and DR lengths differ?

Officially, OpenOCD's JTAG command documentation distinguishes a fixed instruction-register length per TAP from a data-register length determined by its active instruction. BYPASS selects a one-bit data register. Its irscan command places unmentioned TAPs in BYPASS; drscan expects the other TAPs to be bypassed and requires the caller to supply the correct data length.

This distinction prevents a common answer error: “The chip has a four-bit IR, so its data scan is four bits.” The instruction chooses a register; it does not generally encode that register's width.

TI's TM4C JTAG application report gives concrete device examples: BYPASS selects one bit, while IDCODE selects a 32-bit register. That does not make every device's instruction encodings identical. Record the opcode and selected register width separately so a correct instruction cannot hide an incorrect data-scan length.

If the interviewer gives you a boundary-scan register, ask for its documented length or BSDL description. If they give you an implementation-specific debug register, ask for the relevant target architecture. Guessing a scan width can corrupt alignment across every following device, even when the requested opcode was correct.

Calculate a two-TAP scan chain

Use this original board model:

Host TDI -> Device A -> Device B -> Host TDO
A: IR length 4; selected data register 8 bits
B: IR length 5; selected data register BYPASS, 1 bit

Both TAPs share TMS and TCK in this model. They move through the control states together, while their selected registers form one serial data path. BYPASS shortens a device's contribution; it does not physically remove that device from the chain.

The total instruction scan is nine bits. Suppose A needs the fictional four-bit instruction 0010 and B receives the five-bit BYPASS instruction 11111. To end with those values, the input stream sends B's desired bits first, followed by A's desired bits, using least-significant-bit-first ordering within each field. The bits destined for the device nearest TDO must travel through the upstream register before arriving there.

The resulting DR scan is also nine bits, for a different reason: eight bits from A plus one from B. If A captures 0xA6 and B captures zero in this simplified model, the first outgoing bit is B's zero, followed by A's eight bits. Written in clock order, the output is 0, 0, 1, 1, 0, 0, 1, 0, 1. State the temporal convention before interpreting that string as a number.

Now change only A's instruction to a 32-bit IDCODE register. The IR scan still has nine bits, while the DR scan grows to 33. If both devices select BYPASS, the DR path is two bits. A diagram that labels the chain with one permanent length cannot express all three cases.

For tool configuration, OpenOCD's TAP-order FAQ specifies declaring the device nearest TDO first. In this board, B is listed before A. Do not confuse that declaration order with a schematic drawn from host TDI to host TDO, or with a vendor tool's unrelated display convention.

How would you validate the arithmetic?

Use a small model with explicit arrays for A and B. Seed each captured register, shift one bit per simulated clock, and record the outgoing bit before advancing. Check the desired instructions after nine shifts, then repeat for the nine-bit, 33-bit, and two-bit data paths. Change B's declared IR length from five to four and confirm that an eight-clock scan no longer places both intended fields correctly.

The accompanying Python state-and-array model passed 12 local checks, including five-high-clock reset from all 16 states, the final-bit exit path, three DR widths, and a wrong-IR-length negative control. That model checks arithmetic and conventions. It does not validate target timing, signal integrity, electrical levels, or a probe driver. Name the next real observation: a logic-analyzer capture, vendor scan-chain test, or documented ID read on the intended hardware.

What does chain discovery prove?

Official OpenOCD TAP declaration documentation requires the configured TAPs to match the active chain, including IR lengths. It also warns that IDCODE is not mandatory and that routers can change which TAPs are linked into a chain. Automatic discovery cannot reliably infer every IR length.

A plausible ID therefore supports a narrower conclusion than “the board is healthy.” You still need to compare it with the expected device and revision, explain the chain location, and identify any router state. An unexpected but stable value can be a configuration mismatch. A changing value suggests a different investigation. Neither observation justifies declaring the CPU dead immediately.

Keep the original logs. Record which tool command produced the value, whether a reset occurred, and which TAP configuration was active. A later successful connection is useful evidence only if you can identify what changed between attempts.

Diagnose a connection failure from the lowest unproven layer

TI's current Common JTAG Errors documentation covers distinct failures involving the probe, invalid IDs, target power or reset, inaccessible debug components, and unstable device state. It also documents cases where transport selection or a lower debug clock matters. Those error descriptions support hypotheses; the exact code must be interpreted for the named target and probe.

The following investigation order is a preparation recommendation, not a vendor-mandated universal procedure.

First, confirm the host can enumerate the intended probe and that the configured adapter matches it. A missing probe is not yet a target scan failure. Save the host-side error rather than replacing it with “JTAG broken.”

Second, inspect the board-level path: connector orientation, common ground, target voltage reference, documented pin assignments, reset wiring, and continuity through the chain. Compare observations with the schematic. A consistently high or low TDO reading is evidence to investigate this layer, not a uniquely identifying diagnosis.

Third, establish the selected transport and a conservative supported clock. Four-wire JTAG, SWD, and compact JTAG are not interchangeable configuration labels. Change one variable, rerun the same non-destructive connection check, and compare logs. A slower clock fixing the scan suggests a timing-sensitive issue; it does not by itself locate the faulty component.

Fourth, reconcile the active TAP topology and register widths. Compare the expected chain with the observed one. Check whether reset or routing changed it. Only after chain integrity is established should you investigate architecture-specific debug initialization and processor access.

Stable IDCODE, but no processor halt

Consider an original scenario: the expected ID is stable on ten repeated scans, but halt requests fail. Treat the repeated count as scenario data, not a success-rate measurement. The evidence makes an entirely absent serial path less likely. It does not eliminate power-domain, reset, access-control, target-script, or firmware-state problems beyond that path.

Officially, OpenOCD reset configuration separates TAP reset, system reset, and architecture-specific reset behavior. Available signals, shared reset wiring, delays, and board-specific initialization constrain what a debugger can do. “Reset and retry” is incomplete until you name the reset and the intended resulting state.

Ask what happens before firmware runs, whether the core is intentionally held in reset, and whether the debug domain is accessible under the documented device lifecycle. Prefer observation before changing persistent settings. If a suggested recovery erases flash, say that it is destructive and requires a known recovery plan; it is not a routine substitute for diagnosing the connection.

Sources and Further Reading

Research checked October 6, 2026. Device opcodes, timing, reset wiring, routing, and debug-access policies require the exact target documentation.