The primary advantages of using a debugger with JTAG access are:
* The JTAG connection provides direct access to the otherwise hidden CPU core
* The JTAG interface consumes no system I/O ports (serial, Ethernet)
* The JTAG debug method uses little or no system memory allocation (as in monitors)
* There is no monitor to crash along with a system crash (not useful at board bring-up)
* The JTAG connection does not require target system power (except some USB-only probes)
* A JTAG debugger can "steal cycles" to read registers/memory without stopping CPU (assuming that the debug logic built into the CPU provides this capability)
* A JTAG debug session can reset and/or initialize the system (Note: System reset is not part of JTAG. Rather, it is an adjunct to using JTAG for remote debugging, enabling a remote reset of a JTAG probe and target over a network.)
* A JTAG debugger can connect to the debug logic without perturbing the system
* Provides the only reasonable means to connect to targets that do not yet have working bootcode or I/O drivers
JTAG Debug Limitations
The JTAG debug connection does not solve all the world's debug problems because of some serious limitations:
1) Code download over JTAG is not the fastest way to download large programs (>20MB), especially for target systems that rely on 10/100BaseT Ethernet access.
2) Multicore system debug where multiple CPU cores are daisy-chained on the same scan chain and can be individually accessed, but implementing a synchronous debug operation requires additional on-chip hardware to circumvent skidding associated with JTAG operations.
Subsequently, hundreds of CPU cycles may go by after an asynchronous JTAG stop command is issued. Examples of these capabilities are now beginning to appear, e.g., the global inter-processor control logic in Cavium Networks Octeon family, with up to 16 64-bit cnMIPS cores.
3) "Printf" still provides an easy complement for extracting a variety of debug status reports.
JTAG to the Rescue - Boundary Scan Testing
The Joint Test Action Group (JTAG) began solving board-level test problems in the 1990's by standardizing a serial scan chain method (JTAG; IEEE 1149.1) for accessing on-chip resources and additional shift registers built into the I/O paths of every IC for boundary scan testing.
Before the emergence of boundary scan testing, debugging of potential solder bump issues underneath a chip assembly was difficult. Prior to board assembly, every IC is tested to assure its flawless operation. Thus, if the assembled printed circuit board PCB does not work properly, the malfunction must be caused by a solder bridge, gap or a flaw in the printed circuit board. But what if the flaw is underneath the chip assembly, where it can't be seen or repaired easily?
The boundary scan testing methodology addresses this issue. As illustrated in Figure 1, a serial scan path through I/O registers was added and exercised by a sophisticated test program unique to each board to help identify a faulty chip or other device, so that these can be reworked or replaced. In the diagram in Figure 1, each grey box represents a category of device function, e.g., flash, peripherals, I/O ports, etc.
Figure 1. JTAG connection used for boundary scan testing
The JTAG approach provides a method to test very complex systems, while keeping the pin count low. Specifically, the IEEE1149.1 specification requires only 5 pins for the JTAG connection, no matter how long the scan chain register path is. The standard pin functions for the JTAG Test Access Port include:
TRST Test Reset (output from JTAG probe to chip to reset JTAG test logic)
TCK Test Clock (output from JTAG probe to chip to set JTAG scan rate)
TDI Test Data Input (serial test data input to chip)
TDO Test Data Output (serial test data output from chip)
TMS Test Mode Select (determines run or debug mode by state at TCK rising edge)
Several companies focus almost exclusively on boundary scan testing, specializing in both the JTAG hardware connection devices and host-based test software tools to adapt the test program to each board design.
The 2nd Role of JTAG - CPU Core Access for Software/Hardware Debug
Given that the CPU processor core is now hidden from observation or control by integrated caches in the core, by local on chip busses, by an MMU that dynamically allocates memory, and by other SOC peripherals and I/O blocks, the JTAG path provides a direct connection into the debug logic inside the CPU. Thus, we now have a means of observing and controlling program execution. Since caches and peripherals have moved on chip, so must the debug logic (Figure 2 below).
Figure 2. JTAG connection use for software debug/development
With this direct core access, host-based debugger software can now assert a "debug exception", redirecting the processor to get the next instruction from the debug logic registers instead of the program counter, thus effectively taking control of the processor to perform software debug operations:
* Run-control: Start, Stop, Single-Step, Step Into/Over (source or instruction)
* Set hardware and software breakpoints
* Specify conditions to be met or scripts to be executed at breakpoints
* Control reset and initialization of the target system
* Download code to be debugged or code to be programmed into flash
* Execute flash programming and other semi-hosting utilities
Note that in both of the above applications, boundary scan and software debug, the role of JTAG is only to provide the physical layer communications interface, analogous to the PHY layer in the ISO Open Systems Interconnect model.
The protocol for what debug functions are supported is embodied in the debug logic, designed into the CPU core and the debugger software capabilities running on the host computer.
[1][2][3][4]
Source: Tutorial: The Role of JTAG in system debug & test throughout the embedded system development lifecycle by Lyle Pittroff
Posts
