Last updated

JTAG (named after the Joint Test Action Group which codified it) is an industry standard for verifying designs and testing printed circuit boards after manufacture.

A technical standard is an established norm or requirement in regard to technical systems. It is usually a formal document that establishes uniform engineering or technical criteria, methods, processes, and practices. In contrast, a custom, convention, company product, corporate standard, and so forth that becomes generally accepted and dominant is often called a de facto standard.

Printed circuit board board to support and connect electronic components

A printed circuit board (PCB) mechanically supports and electrically connects electronic components or electrical components using conductive tracks, pads and other features etched from one or more sheet layers of copper laminated onto and/or between sheet layers of a non-conductive substrate. Components are generally soldered onto the PCB to both electrically connect and mechanically fasten them to it.


JTAG implements standards for on-chip instrumentation in electronic design automation (EDA) as a complementary tool to digital simulation. [1] It specifies the use of a dedicated debug port implementing a serial communications interface for low-overhead access without requiring direct external access to the system address and data buses. The interface connects to an on-chip Test Access Port (TAP) that implements a stateful protocol to access a set of test registers that present chip logic levels and device capabilities of various parts.

Electronic design automation (EDA), also referred to as electronic computer-aided design (ECAD), is a category of software tools for designing electronic systems such as integrated circuits and printed circuit boards. The tools work together in a design flow that chip designers use to design and analyze entire semiconductor chips. Since a modern semiconductor chip can have billions of components, EDA tools are essential for their design.

Logic simulation is the use of simulation software to predict the behavior of digital circuits and hardware description languages. Simulation can be performed at varying degrees of physical abstraction, such as at the transistor level, gate level, register-transfer level (RTL), electronic system-level (ESL), or behavioral level.

Serial communication Type of data transfer

In telecommunication and data transmission, serial communication is the process of sending data one bit at a time, sequentially, over a communication channel or computer bus. This is in contrast to parallel communication, where several bits are sent as a whole, on a link with several parallel channels.

The Joint Test Action Group formed in 1985 to develop a method of verifying designs and testing printed circuit boards after manufacture. In 1990 the Institute of Electrical and Electronics Engineers codified the results of the effort in IEEE Standard 1149.1-1990, entitled Standard Test Access Port and Boundary-Scan Architecture.

Institute of Electrical and Electronics Engineers scholarly society, publisher and standards organization, headquartered in US

The Institute of Electrical and Electronics Engineers (IEEE) is a professional association with its corporate office in New York City and its operations center in Piscataway, New Jersey. It was formed in 1963 from the amalgamation of the American Institute of Electrical Engineers and the Institute of Radio Engineers.

The JTAG standards have been extended by many semiconductor chip manufacturers with specialized variants to provide vendor-specific features. [2]


In the 1980s, multi-layer circuit boards and non-lead-frame integrated circuits (ICs) were becoming standard and connections were being made between ICs that were not available to probes. The majority of manufacturing and field faults in circuit boards were due to poor solder joints on the boards, imperfections among board connections, or the bonds and bond wires from IC pads to pin lead frames. The Joint Test Action Group (JTAG) was formed in 1985 to provide a pins-out view from one IC pad to another so these faults could be discovered.

Integrated circuit electronic circuit manufactured by lithography; set of electronic circuits on one small flat piece (or "chip") of semiconductor material, normally silicon 639-1 ısoo

An integrated circuit or monolithic integrated circuit is a set of electronic circuits on one small flat piece of semiconductor material that is normally silicon. The integration of large numbers of tiny transistors into a small chip results in circuits that are orders of magnitude smaller, cheaper, and faster than those constructed of discrete electronic components. The IC's mass production capability, reliability and building-block approach to circuit design has ensured the rapid adoption of standardized ICs in place of designs using discrete transistors. ICs are now used in virtually all electronic equipment and have revolutionized the world of electronics. Computers, mobile phones, and other digital home appliances are now inextricable parts of the structure of modern societies, made possible by the small size and low cost of ICs.

Solder metal alloy used to join together metal pieces with higher melting points

Solder is a fusible metal alloy used to create a permanent bond between metal workpieces. The word solder comes from the Middle English word soudur, via Old French solduree and soulder, from the Latin solidare, meaning "to make solid". In fact, solder must first be melted in order to adhere to and connect the pieces together after cooling, which requires that an alloy suitable for use as solder have a lower melting point than the pieces being joined. The solder should also be resistant to oxidative and corrosive effects that would degrade the joint over time. Solder used in making electrical connections also needs to have favorable electrical characteristics.

The industry standard became an IEEE standard in 1990 as IEEE Std. 1149.1-1990 [3] after many years of initial use. In the same year, Intel released their first processor with JTAG (the 80486) which led to quicker industry adoption by all manufacturers. In 1994, a supplement that contains a description of the boundary scan description language (BSDL) was added. Further refinements regarding the use of all-zeros for EXTEST, separating the use of SAMPLE from PRELOAD and better implementation for OBSERVE_ONLY cells were made and released in 2001. [4] Since 1990, this standard has been adopted by electronics companies around the world. Boundary scan is now mostly synonymous with JTAG, but JTAG has essential uses beyond such manufacturing applications.

Intel American semiconductor company

Intel Corporation is an American multinational corporation and technology company headquartered in Santa Clara, California, in the Silicon Valley. It is the world's second largest and second highest valued semiconductor chip manufacturer based on revenue after being overtaken by Samsung, and is the inventor of the x86 series of microprocessors, the processors found in most personal computers (PCs). Intel ranked No. 46 in the 2018 Fortune 500 list of the largest United States corporations by total revenue.

Central processing unit electronic circuitry within a computer that carries out the instructions of a computer program by performing the basic arithmetic, logical, control and input/output (I/O) operations specified by the instructions

A central processing unit (CPU), also called a central processor or main processor, is the electronic circuitry within a computer that carries out the instructions of a computer program by performing the basic arithmetic, logic, controlling, and input/output (I/O) operations specified by the instructions. The computer industry has used the term "central processing unit" at least since the early 1960s. Traditionally, the term "CPU" refers to a processor, more specifically to its processing unit and control unit (CU), distinguishing these core elements of a computer from external components such as main memory and I/O circuitry.

Boundary scan description language (BSDL) is a hardware description language for electronics testing using JTAG. It has been added to the IEEE Std. 1149.1, and BSDL files are increasingly well supported by JTAG tools for boundary scan applications, and by test case generators.


Although JTAG's early applications targeted board level testing, here the JTAG standard was designed to assist with device, board, and system testing, diagnosis, and fault isolation. Today JTAG is used as the primary means of accessing sub-blocks of integrated circuits, making it an essential mechanism for debugging embedded systems which may not have any other debug-capable communications channel.[ citation needed ] On most systems, JTAG-based debugging is available from the very first instruction after CPU reset, letting it assist with development of early boot software which runs before anything is set up. An in-circuit emulator (or, more correctly, a "JTAG adapter") uses JTAG as the transport mechanism to access on-chip debug modules inside the target CPU. Those modules let software developers debug the software of an embedded system directly at the machine instruction level when needed, or (more typically) in terms of high level language source code.

System software debug support is for many software developers the main reason to be interested in JTAG. Many silicon architectures such as PowerPC, MIPS, ARM, x86 built an entire software debug, instruction tracing, and data tracing infrastructure around the basic JTAG protocol. Frequently individual silicon vendors however only implement parts of these extensions. Some examples are ARM CoreSight and Nexus as well as Intel's BTS (Branch Trace Storage), LBR (Last Branch Record), and IPT (Intel Processor Trace) implementations. There are many other such silicon vendor-specific extensions that may not be documented except under NDA. The adoption of the JTAG standard helped move JTAG-centric debugging environments away from early processor-specific designs. Processors can normally be halted, single stepped, or let run freely. One can set code breakpoints, both for code in RAM (often using a special machine instruction) and in ROM/flash. Data breakpoints are often available, as is bulk data download to RAM. Most designs have "halt mode debugging", but some allow debuggers to access registers and data buses without needing to halt the core being debugged. Some toolchains can use ARM Embedded Trace Macrocell (ETM) modules, or equivalent implementations in other architectures to trigger debugger (or tracing) activity on complex hardware events, like a logic analyzer programmed to ignore the first seven accesses to a register from one particular subroutine.

Sometimes FPGA developers also use JTAG to develop debugging tools. [5] The same JTAG techniques used to debug software running inside a CPU can help debug other digital design blocks inside an FPGA. For example, custom JTAG instructions can be provided to allow reading registers built from arbitrary sets of signals inside the FPGA, providing visibility for behaviors which are invisible to boundary scan operations. Similarly, writing such registers could provide controllability which is not otherwise available.

Storing firmware

JTAG allows device programmer hardware to transfer data into internal non-volatile device memory (e.g. CPLDs). Some device programmers serve a double purpose for programming as well as debugging the device. In the case of FPGAs, volatile memory devices can also be programmed via the JTAG port, normally during development work. In addition, internal monitoring capabilities (temperature, voltage and current) may be accessible via the JTAG port.

JTAG programmers are also used to write software and data into flash memory. This is usually done using data bus access like the CPU would use, and is sometimes actually handled by a CPU, but in other cases memory chips have JTAG interfaces themselves. 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.

As a practical matter, when developing an embedded system, emulating the instruction store is the fastest way to implement the "debug cycle" (edit, compile, download, test, and debug).[ citation needed ] This is because the in-circuit emulator simulating an instruction store can be updated very quickly from the development host via, say, USB. Using a serial UART port and bootloader to upload firmware to Flash makes this debug cycle quite slow and possibly expensive in terms of tools; installing firmware into Flash (or SRAM instead of Flash) via JTAG is an intermediate solution between these extremes.

Boundary scan testing

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.

When combined with built-in self-test (BIST), the JTAG scan chain enables a low overhead, embedded solution to testing an IC for certain static faults (shorts, opens, and logic errors). The scan chain mechanism does not generally help diagnose or test for timing, temperature or other dynamic operational errors that may occur. Test cases are often provided in standardized formats such as SVF, or its binary sibling XSVF, and used in production tests. The ability to perform such testing on finished boards is an essential part of Design For Test in today's products, increasing the number of faults that can be found before products ship to customers.

Electrical characteristics

A JTAG interface is a special interface added to a chip. Depending on the version of JTAG, two, four, or five pins are added. The four and five pin interfaces are designed so that multiple chips on a board can have their JTAG lines daisy-chained together if specific conditions are met. [6] The two pin interface is designed so that multiple chips can be connected in a star topology. In either case a test probe need only connect to a single "JTAG port" to have access to all chips on a circuit board.

Daisy-chained JTAG (IEEE 1149.1)

Example of JTAG chain. Test reset signal is not shown Jtag chain.svg
Example of JTAG chain. Test reset signal is not shown

The connector pins are:

  1. TDI (Test Data In)
  2. TDO (Test Data Out)
  3. TCK (Test Clock)
  4. TMS (Test Mode Select)
  5. TRST (Test Reset) optional.

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).

As with any clocked signal, data presented to TDI must be valid for some chip-specific Setup time before and Hold time after the relevant (here, rising) clock edge. TDO data is valid for some chip-specific time after the falling edge of TCK.

The maximum operating frequency of TCK varies depending on all chips in the chain (the lowest speed must be used), but it is typically 10-100 MHz (100-10 ns per bit). Also TCK frequencies depend on board layout and JTAG adapter capabilities and state. One chip might have a 40 MHz JTAG clock, but only if it is using a 200 MHz clock for non-JTAG operations; and it might need to use a much slower clock when it is in a low power mode. Accordingly, some JTAG adapters have adaptive clocking using an RTCK (Return TCK) signal. Faster TCK frequencies are most useful when JTAG is used to transfer lots of data, such as when storing a program executable into flash memory.

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.

Even though few consumer products provide an explicit JTAG port connector, the connections are often available on the printed circuit board as a remnant from development prototyping and/or production. When exploited, these connections often provide the most viable means for reverse engineering.

Reduced pin count JTAG (IEEE 1149.7)

Example of JTAG with reduced pin count Example of reduced pin count JTAG interface.svg
Example of JTAG with reduced pin count

Reduced pin count JTAG uses only two wires, a clock wire and a data wire. This is defined as part of the IEEE 1149.7 standard. [7] The connector pins are:

  1. TMSC (Test Serial Data)
  2. TCKC (Test Clock)

It is called cJTAG for compact JTAG.

The two wire interface reduced pressure on the number of pins, and devices can be connected in a star topology. [8] The star topology enables some parts of the system to be powered down, while others can still be accessed over JTAG; a daisy chain requires all JTAG interfaces to be powered. Other two-wire interfaces exist, such as Serial Wire Debug.

Communications model

In JTAG, devices expose one or more test access ports (TAPs). The picture above shows three TAPs, which might be individual chips or might be modules inside one chip. A daisy chain of TAPs is called a scan chain, or (loosely) a target. Scan chains can be arbitrarily long, but in practice twenty TAPs is unusually long.[ citation needed ]

To use JTAG, a host is connected to the target's JTAG signals (TMS, TCK, TDI, TDO, etc.) through some kind of JTAG adapter, which may need to handle issues like level shifting and galvanic isolation. The adapter connects to the host using some interface such as USB, PCI, Ethernet, and so forth.


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.

Most JTAG hosts use the shortest path between two states, perhaps constrained by quirks of the adapter. (For example, one adapter[ which? ] only handles paths whose lengths are multiples of seven bits.) Some layers built on top of JTAG monitor the state transitions, and use uncommon paths to trigger higher level operations. Some ARM cores use such sequences to enter and exit a two-wire (non-JTAG) SWD mode. A Zero Bit Scan (ZBS) sequence is used in IEEE 1149.7 [7] to access advanced functionality such as switching TAPs into and out of scan chains, power management, and a different two-wire mode.

JTAG IEEE Std 1149.1 (boundary scan) instructions

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:

IEEE-defined "Optional" instructions 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.

Boundary scan register

Devices communicate to the world via a set of input and output pins. By themselves, these pins provide limited visibility into the workings of the device. However, devices that support boundary scan contain a shift-register cell for each signal pin of the device. These registers are connected in a dedicated path around the device's boundary (hence the name). The path creates a virtual access capability that circumvents the normal inputs and outputs, providing direct control of the device and detailed visibility for signals. [9]

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.

Example: ARM11 debug TAP

An example helps show the operation of JTAG in real systems. The example here is the debug TAP of an ARM11 processor, the ARM1136 [10] core. The processor itself has extensive JTAG capability, similar to what is found in other CPU cores, and it is integrated into chips with even more extensive capabilities accessed through JTAG.

This is a non-trivial example, which is representative of a significant cross section of JTAG-enabled systems. In addition, it shows how control mechanisms are built using JTAG's register read/write primitives, and how those combine to facilitate testing and debugging complex logic elements; CPUs are common, but FPGAs and ASICs include other complex elements which need to be debugged.

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:

Those processors are both intended for use in wireless handsets such as cell phones, which is part of the reason they include TAP controllers which modify the JTAG scan chain: Debugging low power operation requires accessing chips when they are largely powered off, and thus when not all TAPs are operational. That scan chain modification is one subject of a forthcoming IEEE 1149.7 [7] standard.

JTAG facilities

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.

Older ARM7 and ARM9 cores include an EmbeddedICE module [13] which combines most of those facilities, but has an awkward mechanism for instruction execution: the debugger must drive the CPU instruction pipeline, clock by clock, and directly access the data buses to read and write data to the CPU. The ARM11 uses the same model for trace support (ETM, ETB) as those older cores.

Newer ARM Cortex cores closely resemble this debug model, but build on a Debug Access Port (DAP) instead of direct CPU access. In this architecture (named CoreSight Technology), core and JTAG module is completely independent. They are also decoupled from JTAG so they can be hosted over ARM's two-wire SWD interface (see below) instead of just the six-wire JTAG interface. (ARM takes the four standard JTAG signals and adds the optional TRST, plus the RTCK signal used for adaptive clocking.) The CoreSight JTAG-DP is asynchronous to the core clocks, and does not implement RTCK. [14] Also, the newer cores have updated trace support.

Halt mode debugging

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.

Monitor mode debugging

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.

ARM processors support an alternative debug mode, called Monitor Mode, to work with such situations. (This is distinct from the Secure Monitor Mode implemented as part of security extensions on newer ARM cores; it manages debug operations, not security transitions.) In those cases, breakpoints and watchpoints trigger a special kind of hardware exception, transferring control to a "debug monitor" running as part of the system software. This monitor communicates with the debugger using the DCC, and could arrange for example to single step only a single process while other processes (and interrupt handlers) continue running.

Common extensions

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.

Freescale has COP and OnCE (On-Chip Emulation). OnCE includes a JTAG command which makes a TAP enter a special mode where the IR holds OnCE debugging commands [15] for operations such as single stepping, breakpointing, and accessing registers or memory. It also defines EOnCE (Enhanced On-Chip Emulation) [16] presented as addressing real time concerns.

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.)

Nexus defines a processor debug infrastructure which is largely vendor-independent. One of its hardware interfaces is JTAG. It also defines a high speed auxiliary port interface, used for tracing and more. Nexus is used with some newer platforms, such as the Atmel AVR32 and Freescale MPC5500 series processors.


Client support

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.


A Netgear FVS336G firewall with a 14 pin JTAG header at lower left. Netgear ProSafe Dual WAN VPN Gigabit Firewall FVS336G JTAG interface.jpeg
A Netgear FVS336G firewall with a 14 pin JTAG header at lower left.
A Netgear DG632 ADSL modem with an 8 pin JTAG header at location "5". ADSL modem router internals labeled.jpg
A Netgear DG632 ADSL modem with an 8 pin JTAG header at location "5".

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 shares 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.

Some common pinouts [19] for 2.54 mm (0.100 in) pin headers are:

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.

Higher end products frequently use dense connectors (frequently 38-pin MICTOR connectors) to support high-speed tracing in conjunction with JTAG operations. A recent trend is to have development boards integrate a USB interface to JTAG, where a second channel is used for a serial port. (Smaller boards can also be powered through USB. Since modern PCs tend to omit serial ports, such integrated debug links can significantly reduce clutter for developers.) Production boards often rely on bed-of-nails connections to test points for testing and programming.

Adapter hardware

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.

As of 2018, adapters with a USB link from the host are the most common approach. Higher end products often support Ethernet, with the advantage that the debug host can be quite remote. Adapters which support high speed trace ports generally include several megabytes of trace buffer and provide high speed links (USB or Ethernet) to get that data to the host.

Parallel port adapters are simple and inexpensive, but they are relatively slow because they use the host CPU to change each bit ("bit banging"). They have declined in usefulness because most computers in recent years don't have a parallel port. Driver support is also a problem, because pin usage by adapters varied widely. Since the parallel port is based on 5V logic level, most adapters lacked voltage translation support for 3.3V or 1.8V target voltages.

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.

Software development

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.

Similar interface standards

Serial Wire Debug (SWD) is an alternative 2-pin electrical interface that uses the same protocol. It uses the existing GND connection. SWD uses an ARM CPU standard bi-directional wire protocol, defined in the ARM Debug Interface v5. [20] This enables the debugger to become another AMBA bus master for access to system memory and peripheral or debug registers. Data rate is up to 4 Mbytes/secat 50 MHz. SWD also has built-in error detection. On JTAG devices with SWD capability, the TMS and TCK are used as SWDIO and SWCLK signals, providing for dual-mode programmers.

See also

Related Research Articles

Microcontroller small computer on a single integrated circuit

A microcontroller is a small computer on a single integrated circuit. In modern terminology, it is similar to, but less sophisticated than, a system on a chip (SoC); an SoC may include a microcontroller as one of its components. A microcontroller contains one or more CPUs along with memory and programmable input/output peripherals. Program memory in the form of ferroelectric RAM, NOR flash or OTP ROM is also often included on chip, as well as a small amount of RAM. Microcontrollers are designed for embedded applications, in contrast to the microprocessors used in personal computers or other general purpose applications consisting of various discrete chips.

ARM, previously Advanced RISC Machine, originally Acorn RISC Machine, is a family of reduced instruction set computing (RISC) architectures for computer processors, configured for various environments. Arm Holdings develops the architecture and licenses it to other companies, who design their own products that implement one of those architectures‍—‌including systems-on-chips (SoC) and systems-on-modules (SoM) that incorporate memory, interfaces, radios, etc. It also designs cores that implement this instruction set and licenses these designs to a number of companies that incorporate those core designs into their own products.

AVR microcontrollers family of microcontrollers

AVR is a family of microcontrollers developed since 1996 by Atmel, acquired by Microchip Technology in 2016. These are modified Harvard architecture 8-bit RISC single-chip microcontrollers. AVR was one of the first microcontroller families to use on-chip flash memory for program storage, as opposed to one-time programmable ROM, EPROM, or EEPROM used by other microcontrollers at the time.

PIC microcontrollers

PIC is a family of microcontrollers made by Microchip Technology, derived from the PIC1650 originally developed by General Instrument's Microelectronics Division. The name PIC initially referred to Peripheral Interface Controller, then it was corrected as Programmable Intelligent Computer. The first parts of the family were available in 1976; by 2013 the company had shipped more than twelve billion individual parts, used in a wide variety of embedded systems.

TI MSP430 mixed-signal microcontroller family

The MSP430 is a mixed-signal microcontroller family from Texas Instruments. Built around a 16-bit CPU, the MSP430 is designed for low cost and, specifically, low power consumption embedded applications.

In-circuit emulation (ICE) is the use of a hardware device or in-circuit emulator used to debug the software of an embedded system. It operates by using a processor with the additional ability to support debugging operations, as well as to carry out the main function of the system. Particularly for older systems, with limited processors, this usually involved replacing the processor temporarily with a hardware emulator: a more powerful although more expensive version. It was historically in the form of bond-out processor which has many internal signals brought out for the purpose of debugging. These signals provide information about the state of the processor.

The Serial Peripheral Interface (SPI) is a synchronous serial communication interface specification used for short-distance communication, primarily in embedded systems. The interface was developed by Motorola in the mid-1980s and has become a de facto standard. Typical applications include Secure Digital cards and liquid crystal displays.

Nios II is a 32-bit embedded-processor architecture designed specifically for the Altera family of field-programmable gate array (FPGA) integrated circuits. Nios II incorporates many enhancements over the original Nios architecture, making it more suitable for a wider range of embedded computing applications, from digital signal processing (DSP) to system-control.

ARM7 is a group of older 32-bit RISC ARM processor cores licensed by ARM Holdings for microcontroller use. The ARM7 core family consists of ARM700, ARM710, ARM7DI, ARM710a, ARM720T, ARM740T, ARM710T, ARM7TDMI, ARM7TDMI-S, ARM7EJ-S. The ARM7TDMI and ARM7TDMI-S were the most popular cores of the family. Since ARM7 cores were released from 1993 to 2001, they are no longer recommended for new IC designs; instead ARM Cortex-M or ARM Cortex-R cores are preferred.

Programmable system-on-chip

PSoC is a family of microcontroller integrated circuits by Cypress Semiconductor. These chips include a CPU core and mixed-signal arrays of configurable integrated analog and digital peripherals.

Background debug mode (BDM) interface is an electronic interface that allows debugging of embedded systems. Specifically, it provides in-circuit debugging functionality in microcontrollers. It requires a single wire and specialized electronics in the system being debugged. It appears in many Freescale Semiconductor products.

Nexus or IEEE-ISTO 5001-2003 is a standard debugging interface for embedded systems.

Serial Vector Format (SVF) is a file format that contains boundary scan vectors to be sent to an electronic circuit using a JTAG interface. Boundary scan vectors consist of the following data:

ARM Cortex-M ARM Cortex-M0+

The ARM Cortex-M is a group of 32-bit RISC ARM processor cores licensed by Arm Holdings. They are intended for microcontroller use, and have been shipped in tens of billions of devices. The cores consist of the Cortex-M0, Cortex-M0+, Cortex-M1, Cortex-M3, Cortex-M4, Cortex-M7, Cortex-M23, Cortex-M33, Cortex-M35P. The Cortex-M4 / M7 / M33 / M35P cores have an FPU silicon option, and when included in the silicon these cores are known as "Cortex-Mx with FPU" or "Cortex-MxF", where 'x' is the core number.

NXP LPC ARM Cortex-M based Microcontrollers by NXP

LPC is a family of 32-bit microcontroller integrated circuits by NXP Semiconductors. The LPC chips are grouped into related series that are based around the same 32-bit ARM processor core, such as the Cortex-M4F, Cortex-M3, Cortex-M0+, or Cortex-M0. Internally, each microcontroller consists of the processor core, static RAM memory, flash memory, debugging interface, and various peripherals. The earliest LPC series were based on the Intel 8-bit 80C51 core. As of February 2011, NXP had shipped over one billion ARM processor-based chips.

In the electronics industry, embedded instrumentation refers to the integration of test and measurement instrumentation into semiconductor chips. Embedded instrumentation differs from embedded system, which are electronic systems or subsystems that usually comprise the control portion of a larger electronic system. Instrumentation embedded into chips is employed in a variety of electronic test applications, including validating and testing chips themselves, validating, testing and debugging the circuit boards where these chips are deployed, and troubleshooting systems once they have been installed in the field.

MIPI Alliance Debug Architecture provides a standardized infrastructure for debugging deeply embedded systems in the mobile and mobile-influenced space. The MIPI Alliance MIPI Debug Working Group released therefore a portfolio of specifications. Their objective is to provide standard debug protocols and standard interfaces from the System on a chip (SoC) to the debug tool. The whitepaper Architecture Overview for Debug summarizes all efforts. In the last years the group focused on specifying protocols that improve the visibility of internal operations in deeply embedded systems, standardizing debug solutions via the functional interfaces of form factor devices and specifying the use of I3C as debug bus.

The MSP432 is a mixed-signal microcontroller family from Texas Instruments. It is based on a 32-bit ARM Cortex-M4F CPU, and extends their 16-bit MSP430 line, with a larger address space for code and data, and faster integer and floating point calculation than the MSP430. Like the MSP430, it has a number of built-in peripheral devices, and is designed for low power requirements.


  1. Neal Stollon (2011). On-Chip Instrumentation. Springer.
  2. Randy Johnson, Steward Christie (Intel Corporation, 2009), JTAG 101—IEEE 1149.x and Software Debug
  3. Copies of IEEE 1149.1-1990 or its 2001 update may be bought from the IEEE.
  4. 1 2 "IEEE 1149.1-2001".
  5. Select the right FPGA debug method presents one of the models for such tools.
  6. "FAQ: Under what conditions can I daisy-chain JTAG?". www.jtagtest.com.
  7. 1 2 3 Texas Instruments is one adopter behind this standard, and has an IEEE 1149.7 wiki page with more information.
  8. "Major Benefits of IEEE 1149.7".
  9. Oshana, Rob (29 October 2002). "Introduction to JTAG". Embedded Systems Design. Retrieved 5 April 2007.
  10. ARM1136JF-S and ARM1136J-S Technical Reference Manual revision r1p5, ARM DDI 0211K. Chapter 14 presents the Debug TAP. Other ARM11 cores present the same model through their Debug TAPs.
  11. Documentation for the OMAP2420 is not publicly available. However, a Texas Instruments document The User's Guide to DBGJTAG discussing a JTAG diagnostic tool presents this OMAP2420 scan chain example (and others).
  12. See "i.MX35 (MCIMX35) Multimedia Applications Processor Reference Manual" from the Freescale web site. Chapter 44 presents its "Secure JTAG Controller" (SJC).
  13. ARM9EJ-S Technical Reference Manual revision r1p2. Appendix B "Debug in Depth" presents the EmbeddedICE-RT module, as seen in the popular ARM926ejs core.
  14. "CoreSight Components Technical Reference Manual: 2.3.2. Implementation specific details". infocenter.arm.com.
  15. AN1817/D, "MMC20xx M•CORE OnCE Port Communication and Control Sequences"; Freescale Semiconductor, Inc.; 2004. Not all processors support the same OnCE module.
  16. AN2073 "Differences Between the EOnCE and OnCE Ports"; Freescale Semiconductor, Inc.; 2005.
  17. "PCI Local Bus Technical Summary, 4.10 JTAG/Boundary Scan Pins".
  18. "Serial PCI Express Bus 16x Pinout and PCIe Pin out Signal names". www.interfacebus.com.
  19. JTAG Pinouts lists a few JTAG-only header layouts that have widespread tool support.
  20. "ARM Information Center". infocenter.arm.com. Retrieved 2017-08-10.