Memory View & Register Inspection - Debugging & Tracing

Memory Map and Address Spaces

Aurix TC3xx Memory Map (TC397)

  0xA0000000 - 0xA0FFFFFF  Program Flash (PFlash, 16 MB) — cached
  0x80000000 - 0x80FFFFFF  Program Flash (PFlash, 16 MB) — uncached alias
  0xAF000000 - 0xAF0FFFFF  Data Flash EEPROM (DFLASH, 1 MB) — EEPROM emulation
  0x70000000 - 0x700FFFFF  LMU RAM (1 MB) — shared between all cores
  0x60000000 - 0x6003FFFF  Core0 PSPR (256 kB) — CPU0 local program scratchpad
  0x50000000 - 0x5003FFFF  Core0 DSPR (256 kB) — CPU0 local data scratchpad
  0x30000000 - 0x3003FFFF  Core1 PSPR (256 kB)
  0x10000000 - 0x1003FFFF  Core2 PSPR (256 kB)
  0xF0000000 - 0xFFFFFFFF  SFR space — peripheral registers (CAN, GTM, ADC, etc.)

  TRACE32 address prefixes:
  C:0xA0000000  = Cached PFlash (default for code)
  NC:0x80000000 = Non-cached PFlash alias
  D:0x70000000  = LMU RAM (data)
  SFR:CAN0.MCR  = Symbolic SFR access via .per file

TRACE32 Data Window Commands

CMMmemory_inspection.cmm

// Memory inspection in TRACE32 PowerView

// View raw memory as 32-bit words (hex + ASCII)
Data.dump 0x70001000 /Long /Hex

// Structured view of a C struct at known address
Var.View %Open %Expand (MyStructType *)0x70001000

// View array of 100 CAN RX frames
Var.View g_canRxBuf[0..99]

// Compare two memory regions: useful for NVM corruption diagnosis
Data.COMPARE 0x70001000 0x70001000+0x200 0x70002000

// Memory fill: zero-fill a buffer to reproduce initial conditions
Data.Set 0x70001000--0x70011FFF 0x00 /Long

// Search memory for a pattern (e.g., find magic word 0xDEADBEEF)
Data.FIND 0x70000000--0x700FFFFF 0xDEADBEEF

// Dump memory to file for offline analysis
Data.SAVE.Binary dump_lmu.bin 0x70000000--0x700FFFFF

// Verify NVM CRC by computing over flash range
Data.SUM 0x80000000--0x800FFFFF /Long /CRC32

SFR Register Inspection

CMMsfr_inspect.cmm

// SFR (Special Function Register) inspection in TRACE32
// SFR files (.per) provide symbolic names; loaded with CPU definition

// View CAN0 module register block
Per CAN0                         // opens SFR browser for CAN0

// Read individual SFR field by name
PRINT "CAN0 MCR.CCE=" SFR:CAN0.MCR.CCE      // Configuration Change Enable bit
PRINT "CAN0 SR.TXO="  SFR:CAN0.SR.TXO       // TX object pending flag

// Watch a GTM timer counter live (auto-refreshes when CPU is running)
Var.Watch %Hex SFR:GTM.TIM0.CH0.GPR0        // General Purpose Register 0

// Snapshot all CAN SFRs to file (for issue report or comparison)
Per.SAVE can0_snapshot.txt CAN0

// Set SFR bit: enable CAN loopback for bench testing
Data.Set SFR:CAN0.MCR.TEST 1
Data.Set SFR:CAN0.TEST.LBCK 1

// Compare SFR snapshot before/after: detect unexpected register changes
Per.SAVE before.txt CAN0
// ... run some code ...
Per.SAVE after.txt CAN0
// diff before.txt after.txt

Live Watch and Variable Symbols

CMMlive_watch.cmm

// Live Watch: continuously update variable display while CPU runs
// Requires: ELF loaded with DWARF debug info (/Debug flag in Data.LOAD.Elf)

// Open live watch window for key application variables
Var.Watch g_vehicleSpeed_mps g_brakeRequest g_throttlePos

// Watch with type cast: display raw address as named struct
Var.Watch %Open %Long (CanFrame_t *)g_pCanRxPtr

// Track OS task states (requires AUTOSAR-aware TRACE32 package)
TASK.List                          // list all OSEK/AUTOSAR tasks + states

// Update period: watch refreshes every 100ms while CPU is running
Var.Watch.RefreshPeriod 100ms

// Scripted poll: log value every 50ms to CSV for trend analysis
LOCAL &cnt
&cnt=0.
WHILE &cnt<200.
(
    LOCAL &speed
    &speed=Var.VALUE(g_vehicleSpeed_mps)
    WRITE #1 FORMAT.FLOAT(2.,3.,&speed)
    WAIT 50ms
    &cnt=&cnt+1.
)

Summary

The Aurix TC3xx memory map separates cached PFlash (0xA0…), LMU RAM (0x70…), core-local DSPR/PSPR (0x50/0x60…), and SFR space (0xF0…). Understanding which alias to use matters: writing to the non-cached alias bypasses the cache and guarantees the debugger sees the same value the CPU would. Data.dump and Var.View complement each other — the former is best for raw memory inspection; the latter renders typed struct/array views using DWARF info. SFR inspection via symbolic .per files is faster than looking up register addresses in datasheets and less error-prone.

🔬 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.