JTAG Tools

Preface

This article focuses on the software layer of JTAG debugging: the tools that control debug probes, understand CPU debug architecture, and expose interfaces to developers through GDB or integrated development environments.

The goal of this article is not to rank tools by popularity, but to explain capabilities, design trade-offs, and appropriate usage scenarios, particularly for ARM Cortex-A SoCs, Linux systems, and secure firmware development.

---

1. Where JTAG Tools Fit in the Debug Stack

A JTAG tool sits between the debugger frontend (GDB / IDE) and the physical debug probe.

GDB / IDE
   ↓
JTAG Tool (OpenOCD, J-Link, DS, TRACE32)
   ↓
Debug Probe (JTAG Adapter)
   ↓
JTAG / SWD
   ↓
ARM CoreSight Debug Logic

The JTAG tool is responsible for:

• Enumerating the JTAG scan chain
• Discovering CoreSight components (DAP, APs, ROM tables)
• Managing multi-core targets
• Translating debugger commands into low-level debug transactions
• Coordinating resets, halts, and execution control

For Cortex-A systems, a JTAG tool must understand:

• ARMv8-A execution states (EL0–EL3)
• SMP and heterogeneous cores
• MMU, caches, and virtual memory
• Secure vs non-secure state (TrustZone)

---

2. OpenOCD

2.1 Overview

OpenOCD (Open On-Chip Debugger) is an open-source JTAG/SWD tool widely used in embedded development. It supports a large number of adapters and targets and is highly scriptable.

OpenOCD is commonly used for:

• Bare-metal development
• Bootloader debugging
• Early bring-up
• Educational and research environments

2.2 Architecture and Strengths

• Script-based configuration (TCL)
• Broad adapter support
• Transparent internal behavior
• Strong community ecosystem

For Cortex-A targets, OpenOCD provides:

• Basic multi-core awareness
• GDB server integration
• Register and memory access
• Limited SMP coordination

2.3 Practical Considerations

OpenOCD focuses on functional correctness and flexibility rather than deep architectural introspection. On modern Cortex-A SoCs, especially those using TrustZone, its capabilities depend heavily on SoC debug configuration and available CoreSight access.

It is well-suited for:

• Non-secure world debugging
• Early boot stages
• Environments where openness and customization are priorities

---

3. SEGGER J-Link Software

3.1 Overview

SEGGER J-Link software provides a polished debug experience paired tightly with J-Link probes. It offers high performance, stability, and ease of use.

J-Link is widely adopted in:

• Commercial development
• Firmware and OS debugging
• Production-oriented environments

3.2 Architecture and Strengths

• Highly optimized communication stack
• Robust GDB server
• Minimal configuration effort
• Consistent behavior across platforms

For Cortex-A systems, J-Link supports:

• SMP debugging
• Linux kernel debugging
• Stable breakpoint and memory access

3.3 Practical Considerations

J-Link emphasizes debug reliability and speed. Advanced architectural visibility (such as detailed TrustZone transitions or secure firmware context) depends on target configuration and is intentionally abstracted from the user.

It is well-suited for:

• Linux kernel and driver debugging
• Stable day-to-day development
• Teams prioritizing productivity

---

4. Arm Development Studio (DSTREAM)

4.1 Overview

Arm Development Studio (DS), typically used with the DSTREAM probe, is Arm’s reference debug solution for Cortex-A and CoreSight-based systems.

It is commonly used in:

• Silicon bring-up
• Platform enablement
• Firmware and OS co-development

4.2 Architecture and Strengths

• Full CoreSight topology awareness
• Deep multi-core coordination
• EL and exception-level visibility
• Integrated trace and performance analysis

Arm DS provides detailed insight into:

• Secure vs non-secure execution
• Exception routing
• Cache and MMU behavior

4.3 Practical Considerations

Arm DS prioritizes architectural accuracy and completeness. It closely follows ARM specifications and exposes low-level system behavior that may be abstracted in other tools.

It is well-suited for:

• TrustZone-aware debugging
• Secure firmware (TF-A, OP-TEE)
• Platform bring-up and validation

---

5. Lauterbach TRACE32

5.1 Overview

TRACE32 is a professional debug and trace environment designed for complex SoCs and long-term product development.

It is widely used in:

• Automotive and aerospace systems
• Silicon vendors
• Security-sensitive platforms

5.2 Architecture and Strengths

• Extensive scripting and automation
• Precise control over CPU state
• Advanced trace and analysis
• Detailed TrustZone visibility

TRACE32 offers:

• Fine-grained control of secure and non-secure states
• Accurate system-wide halting and stepping
• Robust long-running debug sessions

5.3 Practical Considerations

TRACE32 emphasizes depth, determinism, and observability. It is designed for environments where understanding exact system behavior outweighs simplicity.

It is well-suited for:

• Secure world debugging
• Safety-critical development
• Complex multi-core SoCs

---

6. Comparative Overview

Tool	Openness	Ease of Use	Cortex-A Depth	TrustZone Visibility	Typical Use Case
OpenOCD	High	Medium	Basic	Limited	Bring-up, bootloaders
J-Link	Low	High	Medium	Target-dependent	Kernel, drivers
Arm DS	Low	Medium	High	High	Platform enablement
TRACE32	Low	Medium	Very High	Very High	Secure & safety systems

---

7. Summary

JTAG tools differ primarily in how much architectural detail they expose and how they balance usability versus observability.

• OpenOCD favors openness and flexibility
• J-Link favors speed and stability
• Arm DS favors architectural completeness
• TRACE32 favors depth and determinism

Choosing the right tool depends on:

• Target complexity
• Security requirements
• Development phase
• Team experience

Also need to consider the cost. So OpenOCD is choosed. (ToT)

---