Debugging & TRACE32

TRACE32 is the industry-leading debug and trace tool for embedded systems, developed by Lauterbach GmbH (Germany). It consists of: a hardware debug probe (PowerDebug, µTrace) connected to the target via JTAG/SWD/cJTAG, and TRACE32 PowerView software for control and visualization. It supports virtually all automotive MCUs (ARM Cortex, TriCore, PowerPC, RH850) and provides: source-level debugging, trace analysis, flash programming, and RTOS-aware debugging.

JTAG (Joint Test Action Group, IEEE 1149.1) uses 4-5 signals: TCK, TMS, TDI, TDO, and optional TRST. It supports daisy-chaining multiple devices and boundary scan testing. SWD (Serial Wire Debug) is ARM-specific, using only 2 signals: SWDIO and SWCLK - fewer pins, simpler routing. SWD provides similar debug functionality to JTAG for ARM cores but is single-device only. Most Cortex-M targets support both; SWD is preferred for production due to fewer pins.

Hardware breakpoints use dedicated comparator registers in the CPU (typically 2-8 available). They work on any memory including flash - no code modification needed. Software breakpoints replace the instruction at the target address with a debug trap instruction (BKPT on ARM). They require writable memory (RAM), so they don't work directly in flash. For flash-resident code, hardware breakpoints are used, or flash is patched (onchip breakpoints).

A watchpoint triggers a break when a specific memory address is accessed (read, write, or both). It uses hardware comparators in the debug unit. Example: break when variable 'motorSpeed' is written with a value > 5000. This is invaluable for finding memory corruption - who is writing to this address? ARM Cortex-M4 typically provides 4 watchpoints via the DWT (Data Watchpoint and Trace) unit.

Stop-mode (halt-mode): CPU halts on breakpoint - program execution stops completely. Simple but disrupts real-time behavior, watchdogs may fire, and communication stacks timeout. Run-mode (non-intrusive): uses trace hardware to observe execution without stopping. TRACE32 can read memory via DAP while the CPU runs, update variable displays, and log trace data. Run-mode is essential for debugging real-time systems.

ETM is ARM's on-chip trace module that streams a compressed instruction trace through the trace port. It records: every instruction executed (branch addresses and cycle counts), allowing complete program flow reconstruction. ETM generates huge data volumes - external trace memory (TRACE32 PowerTrace) captures it. ETM enables: code coverage analysis without instrumentation, performance profiling, and post-mortem analysis of rare bugs.

Trace records program execution history without stopping the CPU. Types: instruction trace (ETM/PFT - what code ran), data trace (DWT - what data was accessed), system trace (ITM/STM - OS events, printf), and bus trace (AHB/AXI trace). Importance: timing-sensitive bugs in automotive (AUTOSAR OS task scheduling, CAN timing) can't be debugged with breakpoints. Trace shows what happened before a crash, race conditions, and priority inversions.

TRACE32 provides ORTI (OSEK Run-Time Interface) support for AUTOSAR OS debugging. Setup: load the ORTI file describing OS objects. Features: task state display (running, ready, waiting, suspended), task timeline view showing scheduling, stack usage per task, alarm and event monitoring, resource occupation, and interrupt nesting. Commands: TASK.state (show all tasks), TASK.stack (check stack usage), TASK.DTL (task execution timeline).

ITM provides lightweight printf-style tracing on ARM Cortex-M without halting the CPU. Software writes to ITM stimulus registers, and data is output via the SWO (Serial Wire Output) pin or trace port. TRACE32 decodes and timestamps the output. Uses: debug printf (no UART needed), RTOS event tracing, and performance counters. Much faster than semihosting. DWT can also send data trace packets through ITM.

Multi-core MCUs (Infineon AURIX TriCore, NXP S32G) require: one TRACE32 instance per core or PowerView multi-core setup. Synchronized debugging: all cores halt simultaneously on a breakpoint (SMP mode) or independently (AMP mode). Cross-triggers: breakpoint on core 0 can halt core 1. Spinlock visualization: detect deadlocks. Inter-core communication: monitor shared memory. TRACE32 PowerView can display all cores in a single workspace.

TRACE32 programs target flash memory directly via JTAG/SWD. Process: erase flash sector → write data → verify. Flash programming algorithms run on the target CPU (stored in TRACE32 as FLASHfile). Commands: FLASH.ReProgram (intelligent - only erase/program changed sectors), FLASH.Program (full program), FLASH.Erase. Supports: internal flash, external SPI/QSPI flash, and OTP. Production programming uses parallel TRACE32 systems for speed.

PRACTICE is TRACE32's built-in scripting language for automation. It supports: variable declaration, loops, conditionals, file I/O, string manipulation, and all TRACE32 commands. Uses: automated test sequences, flash programming scripts, post-mortem analysis, and custom debug views. Example: script that loads symbol file, programs flash, sets breakpoints, runs to main, and checks a variable value. Scripts have .cmm extension.

Methods: 1) Static analysis: TRACE32 disassembles each function and calculates local variable size + call depth. 2) Stack painting: TRACE32 fills stack with pattern (e.g., 0xCDCDCDCD), runs the application, then checks how much was overwritten - gives actual high-water mark. 3) RTOS task.stack command shows per-task stack usage. Command: TASK.STacK to display stack usage table. Critical for sizing AUTOSAR OS task stacks correctly.

Analyzer windows visualize trace data: Trace.List - instruction-by-instruction execution log with timestamps. Trace.Chart - graphical timeline of function/task execution. Trace.Statistics - function execution time statistics (min, max, avg, count). Trace.Flow - program flow diagram. Analyzer.PortAnalysis - logic analyzer view for external signals. These enable: WCET measurement, code coverage, and scheduling analysis for automotive timing requirements.

Methods: 1) Timestamp trace: ETM/PFT trace with cycle-accurate timestamps. Trace.Statistics shows per-function timing. 2) Runtime measurement: TRACE32 measures time between two breakpoints. Run.PeakReset then Run.Go measures max execution time. 3) Profiling: statistical sampling of the PC at regular intervals - identifies hotspots without trace hardware. 4) Performance counter: DWT CYCCNT gives cycle-accurate timing via register reads.

STM (System Trace Macrocell) provides hardware-assisted system-level tracing. Software writes tagged messages to STM channels, and the hardware outputs timestamped trace data. Unlike ITM (Cortex-M only), STM is used on larger cores (Cortex-A, TriCore). Channels can be assigned to: OS events, communication events, custom debug output. TRACE32 decodes and correlates STM data with instruction trace for complete system visibility.

When a HardFault occurs: 1) Read fault status registers: SCB->HFSR (HardFault), SCB->CFSR (UsageFault/BusFault/MemManage), SCB->BFAR/MMFAR (fault address). 2) Examine the stacked registers (R0-R3, R12, LR, PC, xPSR) on the exception stack frame to find the faulting instruction. 3) In TRACE32: Register.view shows all fault registers, Frame.view /Locals shows the call stack at fault. Common causes: null pointer dereference, stack overflow, unaligned access, division by zero.

Semihosting redirects C library calls (printf, fopen, etc.) from the target to the host debugger via the debug interface. The target executes a breakpoint instruction with a specific parameter, TRACE32 intercepts it, performs the I/O operation, and resumes. Very slow (halts CPU each call) - suitable only for development. For production debugging, use ITM/SWO for printf output, which is non-intrusive and much faster.

TRACE32 aids safety testing: code coverage measurement without instrumentation (using trace), WCET analysis from trace data (required by ISO 26262 Part 6), fault injection (modify registers/memory during execution to test safety mechanisms), stack analysis (verify stack sizing for all tasks), MC/DC coverage from branch trace, and regression test automation via PRACTICE scripts. Coverage reports can be exported for ISO 26262 evidence.

A core dump captures the complete CPU and memory state at a specific point (typically after a crash). TRACE32 can: save a dump (Data.SAVE.Binary) and restore it later (Data.LOAD.Binary). Analysis: load symbol file, examine call stack (Frame.view), inspect all variables and registers, check peripheral register states, and review fault registers. Post-mortem analysis is critical when bugs are intermittent and can't be reproduced with breakpoints.

PowerTrace: high-end trace solution with large external trace memory (up to 4GB), supports parallel trace ports (wide ETM), streaming trace to host, and multiple trace sources simultaneously. Used for complex automotive MCUs. µTrace: compact USB-powered probe, smaller trace buffer, suitable for SWD/SWO trace and basic instruction trace. Both connect to PowerView software. PowerTrace is needed for long trace captures and multi-core trace.

Boot debugging: 1) Connect TRACE32 in reset state (SYStem.Mode Prepare). 2) Configure the debug connection (JTAG/SWD clock, reset behavior). 3) Hold the target in reset (SYStem.Mode Up - halts at reset vector). 4) Single-step through startup code. 5) Set breakpoints at key initialization points (clock setup, memory init, main). For secure boot: may need to authenticate the debugger or use special debug unlock sequences. TRACE32 supports early boot trace capture.

NEXUS (IEEE-ISTO 5001) is a debug and trace standard primarily for PowerPC and some other automotive MCUs. It defines: run-control (breakpoints, single-step), real-time data access, program trace, data trace, and watchpoint trace. Nexus classes (1-4) define feature levels. Lauterbach TRACE32 supports Nexus for NXP MPC/SPC MCUs. For ARM-based automotive MCUs, CoreSight (ETM/ITM/DWT) serves the equivalent role.

Strategies: 1) Continuous trace capture with circular buffer - when the bug occurs, trace shows history. 2) Conditional breakpoints triggered only when anomaly conditions are met. 3) Data watchpoints on suspect variables. 4) Long-running automated test with TRACE32 logging. 5) Statistical profiling to find timing variations. 6) Pin-toggling + oscilloscope for hardware-related timing issues. 7) Memory protection to catch corruption early. Trace is the most powerful tool for intermittent bugs.

On-chip debug hardware built into MCUs: ARM CoreSight (debug + trace infrastructure), Infineon AURIX OCDS (On-Chip Debug Support with multi-core debug), Renesas E2 (on-chip debug with trace), NXP Nexus. Features vary by MCU: number of hardware breakpoints (2-8), watchpoints, trace buffer size, debug authentication, and security restrictions. Higher-end MCUs provide more debug resources. Production devices may have debug locked for security.

Automated regression testing with PRACTICE scripts: 1) Script loads the firmware and symbol file. 2) Configures breakpoints at test points. 3) Runs the application with test stimuli. 4) At breakpoints, reads and validates variable values against expected results. 5) Logs pass/fail results to a file. 6) Script exits with status code for CI integration. TRACE32 can be controlled remotely via API (C, Python) for integration with Jenkins/GitLab CI.

The T32 Remote API allows external programs to control TRACE32 programmatically. Available in C, Python, and .NET. Functions: connect/disconnect, read/write memory and registers, set breakpoints, run/halt, read trace data, and execute PRACTICE commands. Use cases: CI/CD pipeline integration (automated flash + test), custom test frameworks, production programming stations, and interfacing with other test tools (CANoe, dSPACE).

Modern automotive MCUs require debug authentication before access is granted. TRACE32 supports: password-based unlock (write a key to unlock register), certificate-based authentication (exchange certificates via debug interface), and challenge-response protocols. Configuration: SYStem.CONFIG DEBUGPORTAUTH. For production ECUs with debug permanently locked, TRACE32 can still perform limited operations if allowed by the security policy (e.g., read-only access).

Instruction trace (ETM/PFT): records which instructions were executed - program flow, branch decisions, and timing. Enables: code coverage, WCET analysis, and execution path reconstruction. Data trace (DWT): records memory read/write operations - address, data value, and timestamp. Enables: variable history tracking, memory access pattern analysis, and data breakpoint logging. Both together provide complete program behavior visibility.

Speed optimization: 1) Increase JTAG/SWD clock frequency (up to 50MHz for SWD, limited by cable quality). 2) Use adaptive clocking (SYStem.JtagClock CTCK). 3) Enable access port caching. 4) Use block transfers for memory operations. 5) Minimize breakpoint-based debugging (use trace instead). 6) Use FLASH.ReProgram for incremental flash updates. 7) Keep debug cable short and high quality. 8) For multi-core: use parallel JTAG where supported.