Debugger Architecture & JTAG/SWD - Debugging & Tracing

JTAG: The IEEE 1149.1 Standard

Signal	Direction	Purpose
TCK	Host → Target	Test Clock: all operations synchronised to TCK edges; max typically 10–50 MHz for automotive MCUs
TMS	Host → Target	Test Mode Select: 5-bit state machine transitions (Run-Test/Idle, Shift-DR, Shift-IR, etc.)
TDI	Host → Target	Test Data In: instruction or data shifted in on TCK rising edge
TDO	Target → Host	Test Data Out: sampled on TCK falling edge; MSB of previous TDI shift
TRST#	Host → Target	Optional async JTAG TAP reset; pull low for ≥5 TCK cycles to force Test-Logic-Reset

💡 Automotive JTAG Pin Protection

Production ECUs often fuse JTAG access: TMS/TDI/TDO pads are disconnected after EOL programming. During bring-up, debug headers expose these signals. Always check the MCU's JTAG disable fuse register before assuming a production board has JTAG access — Infineon Aurix uses HSM_CONFIG_DFLASH fuses; NXP S32K uses JTAG_LOCK in IFR flash.

SWD: ARM Serial Wire Debug

Feature	JTAG	SWD
Pins required	4 (TCK,TMS,TDI,TDO) + optional TRST	2 (SWDCLK, SWDIO) — pin count critical in ECU packaging
Protocol	Parallel shift-register TAP	Serial: 8-bit request packet + ACK + 32-bit data
CoreSight AP access	Via IR/DR scan chains	Direct via DP→AP hierarchy — faster than JTAG for register reads
Maximum speed	~50 MHz TCK	~50 MHz SWDCLK; SWD-DP also supports SWD multi-drop (v2)
Target reset	TRST# pin or srst via nRESET	SWDIO-based line reset; SYSRESETREQ via AIRCR
Use case	Multi-core + ETM trace on JTAG DAP	Single-core Cortex-M on space-constrained ECU boards

Debug Access Port (DAP) Architecture

CoreSight DAP: DP → APs → Debug Resources

  Debug Probe (TRACE32 µTrace / LA-7780)
       │  JTAG or SWD physical interface
       ▼
  Debug Port (DP)  — JTAG-DP or SW-DP
  ├── CTRL/STAT register: power-up, overrun detection, sticky errors
  └── SELECT register: chooses which AP is currently accessed
       │
       ├── AHB-AP (MEM-AP)  → system bus → RAM, peripheral registers
       ├── APB-AP           → CoreSight component registers (ETM, ITM, TPIU, CTI)
       └── JTAG-AP          → legacy JTAG chains (non-ARM debug on same DAP)

  Access sequence example (read memory at 0x20000100):
  1. Write DP SELECT: bank=0, APSEL=0 (MEM-AP)
  2. Write AP TAR:    0x20000100 (target address)
  3. Read  AP DRW:    returns word at 0x20000100 after one extra read (AP pipelining)

TRACE32 Connection Setup

CMMconnect_aurix.cmm

// TRACE32 PowerView: connect to Infineon Aurix TC397 via JTAG
// File: connect_aurix.cmm — run on TRACE32 startup

SYStem.RESet                          // full hardware reset of debugger state

SYStem.CPU TC397                      // select exact CPU; sets correct CoreSight config
SYStem.CONFIG.Debugger NEXUS          // Aurix uses Nexus/MCDS, not ARM CoreSight
SYStem.CONFIG.DAPIRPRE 0.             // no IR-pre bits before TC3xx JTAG TAP
SYStem.JtagClock 10MHz                // safe start; increase after JTAG verified
SYStem.Option INTDIS OFF              // don't disable interrupts on halt (causes watchdog)
SYStem.Option WATCHDOG OFF            // disable STM watchdog during debug session

SYStem.Up                             // power-up DAP; establish JTAG comms

// Verify connection: read JTAG IDCODE
Data.InSFR SYS.JTAGID                 // should return 0x1A56_xxxx for TC397
PRINT "JTAG IDCODE: " Data.Long(SYS.JTAGID)

// Load ELF with full DWARF symbols
Data.LOAD.Elf build/app.elf /NOCODE /RELPATH
PRINT "Connected: " CPUIS()           // prints "TC397" if successful

Summary

JTAG is the 4-wire standard enabling access to the DAP — the gateway to all MCU debug and trace resources. SWD provides equivalent DAP access over 2 wires when pin count is constrained. The DAP's MEM-AP gives the debugger read/write access to the entire system bus; the APB-AP reaches CoreSight ETM and ITM components. In TRACE32, SYStem.CPU selects the correct CoreSight configuration and SYStem.Up establishes the physical link — both must succeed before any debug command is usable.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.