Using JTAG Beyond Flashing: Hardware-Accelerated Debugging Tricks for Embedded Engineers

Introduction

JTAG (Joint Test Action Group) is a ubiquitous interface in the embedded world, primarily known for programming flash memory and performing boundary scan tests. However, its capabilities extend far beyond these basic functions. For embedded engineers, JTAG can be a powerful tool for hardware-accelerated debugging, real-time tracing, and performance optimization.

In this article, we’ll explore advanced JTAG debugging techniques that go beyond simple flashing.

We’ll cover:

JTAG Fundamentals Recap – A quick refresher on how JTAG works.
Hardware Breakpoints vs. Software Breakpoints – Why hardware breakpoints are superior.
Real-Time Variable Monitoring with JTAG – How to watch memory and registers without halting the CPU.
Trace Debugging with ETM and PTM – Capturing execution flow for complex bugs.
JTAG-Based Performance Profiling – Identifying bottlenecks in real-time systems.
Automated Hardware Testing via JTAG – Using JTAG for validation and regression testing.
Security Considerations – Risks and mitigations when using JTAG in production.

By the end, you’ll have a toolkit of advanced JTAG techniques to debug embedded systems more efficiently.

1. JTAG Fundamentals Recap

Before diving into advanced techniques, let’s quickly recap how JTAG works:

JTAG Interface: Consists of four mandatory signals—TMS (Test Mode Select), TCK (Test Clock), TDI (Test Data In), and TDO (Test Data Out)—plus optional TRST (Test Reset).
TAP Controller: A state machine that manages JTAG operations.
Boundary Scan: Allows testing PCB interconnections without physical probes.
Debug Access Port (DAP): ARM’s implementation for CPU debugging via JTAG/SWD.

While JTAG is commonly used for flashing firmware, its real power lies in hardware-assisted debugging, which we’ll explore next.

2. Hardware Breakpoints vs. Software Breakpoints

Software Breakpoints (The Usual Approach)

Most debuggers use software breakpoints by replacing instructions with a BKPT opcode (e.g., 0xBE on ARM). This works but has limitations:

✅ Easy to implement.
❌ Requires modifying code (problematic in ROM/flash).
❌ Slows execution (CPU must trap into debug mode).
❌ Limited to code sections (can’t break on data access).

Hardware Breakpoints (JTAG’s Hidden Gem)

Many MCUs (ARM Cortex-M, PowerPC, etc.) include hardware breakpoint registers that trigger without modifying code.

✅ No code modification (works in flash/ROM).
✅ Can break on data access (watchpoints).
✅ Near-zero overhead (CPU runs at full speed).

Example: Setting a Hardware Watchpoint in OpenOCD

# Break when variable 'counter' (at 0x20000000) is written
bp 0x20000000 4 hw write

Pro Tip: Cortex-M devices typically have 4-8 hardware breakpoints—use them wisely!

3. Real-Time Variable Monitoring with JTAG

Sometimes, halting the CPU to inspect variables disrupts real-time behavior. Instead, JTAG allows non-intrusive monitoring:

Method 1: Direct Memory Access (DMA-Style Reads)

Some debug probes (like SEGGER J-Link) can read memory while the CPU runs by using JTAG’s low-level access.

Example (J-Link Commander):

> MemU32 0x20000000 4 # Read 4 bytes from 0x20000000

Method 2: Real-Time Watch Expressions

Modern IDEs (Keil, IAR, VSCode + Cortex-Debug) allow live variable tracking via JTAG.

Use Case:

Monitor an ADC buffer without stopping the ISR.
Track stack overflow in real-time.

4. Trace Debugging with ETM and PTM

For complex bugs (race conditions, intermittent faults), execution trace is invaluable. ARM cores support:

ETM (Embedded Trace Macrocell) – Instruction-level trace.
PTM (Program Trace Macrocell) – Similar but optimized for Cortex-M.
ITM (Instrumentation Trace Macrocell) – For printf-style debugging.

How It Works

The CPU streams execution data to a trace buffer.
A high-speed JTAG probe (like Lauterbach or DS-5) captures the trace.
The debugger reconstructs the execution flow.

Example: Finding a Stack Corruption Bug

Trace shows unexpected jumps in the call stack.
Compare against expected execution path.

Limitations:

Requires extra pins (SWO for ITM, 4+ pins for ETM).
Trace buffers fill quickly—use filtering wisely.

5. JTAG-Based Performance Profiling

Optimizing firmware? JTAG can help measure:

Cycle Counting – Exact clock cycles between breakpoints.
Cache Miss Analysis – Using performance monitors (PMU) in ARM cores.
Interrupt Latency – Measure ISR entry/exit times.

Example (ARM Cortex-M with DWT):

// Enable DWT cycle counter CoreDebug->DEMCR |= CoreDebug_DEMCR_TRCENA_Msk; DWT->CYCCNT = 0; DWT->CTRL |= DWT_CTRL_CYCCNTENA_Msk;// Measure function uint32_t start = DWT->CYCCNT; my_function(); uint32_t end = DWT->CYCCNT; printf(“Cycles: %lu\n”, end – start);

JTAG Advantage: No instrumentation needed—just read DWT->CYCCNT via debugger.

6. Automated Hardware Testing via JTAG

JTAG isn’t just for debugging—it’s great for automated testing:

Boundary Scan Testing (BST)

Verify PCB connections (opens/shorts).
Test unpopulated boards.

Firmware Validation

Scripted memory checks.
Register read/write tests.

Example (Using OpenOCD Scripting):

# Power-on test script jtag reset flash write_image firmware.bin 0x08000000 verify_image firmware.bin 0x08000000 mww 0x40021000 0x00000001 # Enable clock mdw 0x40021000 # Verify register

7. Security Considerations

While JTAG is powerful, it’s also a security risk in production:

Disable JTAG in Release Firmware (via fuse bits or RDP on STM32).
Use Secure Debug Unlock (if supported).
Physical Tamper Protection – Cover test points.

Best Practice:

Keep JTAG enabled in development.
Disable (or password-protect) in production.

Conclusion

JTAG is much more than a flashing tool—it’s a high-performance debug interface that can:

✔️ Set non-intrusive hardware breakpoints.
✔️ Monitor variables in real-time.
✔️ Capture execution traces for complex bugs.
✔️ Profile performance without instrumentation.
✔️ Automate hardware testing.

By mastering these techniques, embedded engineers can debug faster, optimize better, and build more reliable systems.

Next Steps: