JTAG

JTAG programmers are also used to write software and data into flash memory. This is usually done using the same data bus access the CPU would use, and is sometimes handled by the CPU. In other cases the memory chips themselves have JTAG interfaces. Some modern debug architectures provide internal and external bus master access without needing to halt and take over a CPU. In the worst case, it is usually possible to drive external bus signals using the boundary scan facility.

JTAG boundary scan technology provides access to many logic signals of a complex integrated circuit, including the device pins. The signals are represented in the boundary scan register (BSR) accessible via the TAP. This permits testing as well as controlling the states of the signals for testing and debugging. Therefore, both software and hardware (manufacturing) faults may be located and an operating device may be monitored.

The TRST pin is an optional active-low reset to the test logic, usually asynchronous, but sometimes synchronous, depending on the chip. If the pin is not available, the test logic can be reset by switching to the reset state synchronously, using TCK and TMS. Note that resetting test logic doesn't necessarily imply resetting anything else. There are generally some processor-specific JTAG operations which can reset all or part of the chip being debugged.

Since only one data line is available, the protocol is serial. The clock input is at the TCK pin. One bit of data is transferred in from TDI, and out to TDO per TCK rising clock edge. Different instructions can be loaded. Instructions for typical ICs might read the chip ID, sample input pins, drive (or float) output pins, manipulate chip functions, or bypass (pipe TDI to TDO to logically shorten chains of multiple chips).

Clocking changes on TMS steps through a standardized JTAG state machine. The JTAG state machine can reset, access an instruction register, or access data selected by the instruction register.

JTAG platforms often add signals to the handful defined by the IEEE 1149.1 specification. A System Reset (SRST) signal is quite common, letting debuggers reset the whole system, not just the parts with JTAG support. Sometimes there are event signals used to trigger activity by the host or by the device being monitored through JTAG; or, perhaps, additional control lines.

The host communicates with the TAPs by manipulating TMS and TDI in conjunction with TCK, and reading results through TDO (which is the only standard host-side input). TMS/TDI/TCK output transitions create the basic JTAG communication primitive on which higher layer protocols build:

So at a basic level, using JTAG involves reading and writing instructions and their associated data registers; and sometimes involves running a number of test cycles. Behind those registers is hardware that is not specified by JTAG, and which has its own states that is affected by JTAG activities.

Instruction register sizes tend to be small, perhaps four or seven bits wide. Except for BYPASS and EXTEST, all instruction opcodes are defined by the TAP implementor, as are their associated data registers; undefined instruction codes should not be used. Two key instructions are:

On exit from the RESET state, the instruction register is preloaded with either BYPASS or IDCODE. This allows JTAG hosts to identify the size and, at least partially, contents of the scan chain to which they are connected. (They can enter the RESET state then scan the Data Register until they read back the data they wrote. A BYPASS register has only a zero bit; while an IDCODE register is 32-bits and starts with a one. So the bits not written by the host can easily be mapped to TAPs.) Such identification is often used to sanity check manual configuration, since IDCODE is often unspecific. It could for example identify an ARM Cortex-M3 based microcontroller, without specifying the microcontroller vendor or model; or a particular FPGA, but not how it has been programmed.

A common idiom involves shifting BYPASS into the instruction registers of all TAPs except one, which receives some other instruction. That way all TAPs except one expose a single bit data register, and values can be selectively shifted into or out of that one TAP's data register without affecting any other TAP.

The IEEE 1149.1 (JTAG) standard describes a number of instructions to support boundary scan applications. Some of these instructions are "mandatory", but TAPs used for debug instead of boundary scan testing sometimes provide minimal or no support for these instructions. Those "mandatory" instructions operate on the Boundary Scan Register (BSR) defined in the BSDL file, and include:

Devices may define more instructions, and those definitions should be part of a BSDL file provided by the manufacturer. They are often only marked as PRIVATE.

The contents of the boundary scan register, including signal I/O capabilities, are usually described by the manufacturer using a part-specific BSDL file. These are used with design 'netlists' from CAD/EDA systems to develop tests used in board manufacturing. Commercial test systems often cost several thousand dollars for a complete system, and include diagnostic options to pinpoint faults such as open circuits and shorts. They may also offer schematic or layout viewers to depict the fault in a graphical manner.

To enable boundary scanning, IC vendors add logic to each of their devices, including scan cells for each of the signal pins. These cells are then connected together to form the boundary scan shift register (BSR), which is connected to a TAP controller. These designs are parts of most Verilog or VHDL libraries. Overhead for this additional logic is minimal, and generally is well worth the price to enable efficient testing at the board level.

Licensees of this core integrate it into chips, usually combining it with other TAPs as well as numerous peripherals and memory. One of those other TAPs handles boundary scan testing for the whole chip; it is not supported by the debug TAP. Examples of such chips include:

This debug TAP exposes several standard instructions, and a few specifically designed for hardware-assisted debugging, where a software tool (the "debugger") uses JTAG to communicate with a system being debugged:

That model resembles the model used in other ARM cores. Non-ARM systems generally have similar capabilities, perhaps implemented using the Nexus protocols on top of JTAG, or other vendor-specific schemes.

One basic way to debug software is to present a single threaded model, where the debugger periodically stops execution of the program and examines its state as exposed by register contents and memory (including peripheral controller registers). When interesting program events approach, a person may want to single step instructions (or lines of source code) to watch how a particular misbehavior happens.

So for example a JTAG host might HALT the core, entering Debug Mode, and then read CPU registers using ITR and DCC. After saving processor state, it could write those registers with whatever values it needs, then execute arbitrary algorithms on the CPU, accessing memory and peripherals to help characterize the system state. After the debugger performs those operations, the state may be restored and execution continued using the RESTART instruction.

Debug mode is also entered asynchronously by the debug module triggering a watchpoint or breakpoint, or by issuing a BKPT (breakpoint) instruction from the software being debugged. When it is not being used for instruction tracing, the ETM can also trigger entry to debug mode; it supports complex triggers sensitive to state and history, as well as the simple address comparisons exposed by the debug module. Asynchronous transitions to debug mode are detected by polling the DSCR register. This is how single stepping is implemented: HALT the core, set a temporary breakpoint at the next instruction or next high-level statement, RESTART, poll DSCR until you detect asynchronous entry to debug state, remove that temporary breakpoint, repeat.

Modern software is often too complex to work well with such a single threaded model. For example, a processor used to control a motor (perhaps one driving a saw blade) may not be able to safely enter halt mode; it may need to continue handling interrupts to ensure physical safety of people and/or machinery. Issuing a HALT instruction using JTAG might be dangerous.

Microprocessor vendors have often defined their own core-specific debugging extensions. Such vendors include Infineon, MIPS with EJTAG, and more. If the vendor does not adopt a standard (such as the ones used by ARM processors; or Nexus), they need to define their own solution. If they support boundary scan, they generally build debugging over JTAG.

ARM has an extensive processor core debug architecture (CoreSight) that started with EmbeddedICE (a debug facility available on most ARM cores), and now includes many additional components such as an ETM (Embedded Trace Macrocell), with a high speed trace port, supporting multi-core and multithread tracing. Note that tracing is non-invasive; systems do not need to stop operating to be traced. (However, trace data is too voluminous to use JTAG as more than a trace control channel.)

The target's JTAG interface is accessed using some JTAG-enabled application and some JTAG adapter hardware. There is a wide range of such hardware, optimized for purposes such as production testing, debugging high speed systems, low cost microcontroller development, and so on. In the same way, the software used to drive such hardware can be quite varied. Software developers mostly use JTAG for debugging and updating firmware.

There are no official standards for JTAG adapter physical connectors. Development boards usually include a header to support preferred development tools; in some cases they include multiple such headers, because they need to support multiple such tools. For example, a microcontroller, FPGA, and ARM application processor rarely share tools, so a development board using all of those components might have three or more headers. Production boards may omit the headers, or when space is limited may provide JTAG signal access using test points.

Those connectors tend to include more than just the four standardized signals (TMS, TCK, TDI, TDO). Usually reset signals are provided, one or both of TRST (TAP reset) and SRST (system reset). The connector usually provides the board-under-test's logic supply voltage so that the JTAG adapters use the appropriate logic levels. The board voltage may also serve as a "board present" debugger input. Other event input or output signals may be provided, or general purpose I/O (GPIO) lines, to support more complex debugging architectures.

Adapter hardware varies widely. When not integrated into a development board, it involves a short cable to attach to a JTAG connector on the target board; a connection to the debugging host, such as a USB, PCI, or Ethernet link; and enough electronics to adapt the two communications domains (and sometimes provide galvanic isolation). A separate power supply may be needed. There are both "dumb" adapters, where the host decides and performs all JTAG operations; and "smart" ones, where some of that work is performed inside the adapter, often driven by a microcontroller. The "smart" adapters eliminate link latencies for operation sequences that may involve polling for status changes between steps, and may accordingly offer faster throughput.

RS-232 serial port adapters also exist, and are similarly declining in usefulness. They generally involve either slower bit banging than a parallel port, or a microcontroller translating some command protocol to JTAG operations. Such serial adapters are also not fast, but their command protocols could generally be reused on top of higher speed links.

With all JTAG adapters, software support is a basic concern. Many vendors do not publish the protocols used by their JTAG adapter hardware, limiting their customers to the tool chains supported by those vendors. This is a particular issue for "smart" adapters, some of which embed significant amounts of knowledge about how to interact with specific CPUs.

Most development environments for embedded software include JTAG support. There are, broadly speaking, three sources of such software:

All such software tends to include basic debugger support: stopping, halting, single stepping, breakpoints, data structure browsing, and so on. Commercial tools tend to provide tools like very accurate simulators and trace analysis, which are not currently available as open source.