Case Study: Debugging Traps on TriCore™ AURIX™

 Category: Debug

 Background Information: Traps in TriCore™ AURIX™

In the TriCore™ AURIX™ architecture, traps are special events triggered by specific conditions, such as:

• Instruction Exceptions
  
  
• Illegal Memory Accesses, including:
  
  
  • Attempts to access memory regions that are not mapped or peripherals that have not yet been initialized
    
    
  • Bus operations that result in ECC errors
    
    
• Non-Maskable Interrupts (NMI)
  
  

Traps are always enabled and cannot be disabled or masked via software. The trap vector handler resides in code memory, while the BTV (Base Trap Vector) register defines the starting address of the trap vector table. This register’s value can be examined in the Register.view window.

The TriCore architecture specifies eight main trap classes, each associated with its own dedicated handler. The trap class determines the offset of the corresponding handler within program memory, relative to the base address indicated by the BTV register.

Each trap is assigned a distinct Trap Identification Number (TIN). When a trap occurs, this TIN is automatically loaded into register D15, enabling the Trap Service Routine (TSR) to recognize the specific trap and execute the necessary response within the application software.

Trap Types:

By Source:

• Hardware traps: Triggered by exception conditions detected by the hardware, such as illegal instructions or memory protection violations.
  
  
• Software traps: Deliberately generated through a system call or an assertion instruction.
  
  

By Timing:

• Synchronous traps: Happen during the execution (or attempted execution) of a particular instruction. The exact instruction causing the trap is known, and the trap is handled immediately before execution proceeds.
  
  
• Asynchronous traps: Caused by externally detected hardware conditions signaled to the core. The exact instruction responsible may not be identifiable because the CPU stops at an arbitrary point, and the instruction shown may not be related to the trap.
  
  

For further details, refer to the Core Architecture Manual.

Case Study – Trap Debugging
 This case study illustrates how to debug a trap using TRACE32 PowerView on a TriBoard featuring a TC397XE processor.

Initial Observations
 We begin with a trap scenario where symbolic information indicates that the application has halted at a Bus Error Trap.

The TRACE32 PowerView status bar shows that the target is currently “stopped at a software breakpoint.” Meanwhile, the List window confirms that the program counter (PC) is positioned immediately after the debug16 instruction.

Note:
 Debug instructions are usually embedded within error-handling routines. When a debugger is connected, these instructions halt the CPU for inspection. If no debugger is attached, they effectively act as NOP (no operation) instructions.

Looking into the Frame.view window, we can see an exception has occurred, followed by a call to the corresponding trap-handling function.

Using TRACE32 Trap Decoding
 TRACE32 PowerView offers a dedicated menu to determine the cause of a trap:
 Navigate to TC39x > Special decoders > Active Trap Decoding to access this functionality.

If the CPU is stopped within the Trap Service Routine rather than at the trap vector itself, the AREA window might show “No exception detected.” This is normal, as the core has already progressed beyond the trap vector.

To properly decode the cause of the trap, the target must be halted at the trap vector. TRACE32 PowerView offers a menu option to set a program breakpoint over the entire trap vector range:
 TC39x > Special triggers > Break on Trap Entry (whole table).

Caution is required because compilers can place standard application code (for example, the encode function) into unused portions of the trap vector.

In this example, the program breakpoint needs to be adjusted as follows:
 Break.Set IfxCpu_Trap_vectorTable0++0xF3 /Program /Onchip

When the CPU is properly halted within the trap vector range, the “Active Trap Decoding” menu will display detailed information, including the trap class, TIN, and other trap-specific data.

Accessing Additional Trap Details
 While the Core Architecture Manual provides an overview of general trap mechanisms, specific implementation details are found in the Family User’s Manual. For instance, the TC3xx User’s Manual explains that detailed information about DIE traps can be obtained from the DIEAR (Data Integrity Error Address Register) and DIETR (Data Integrity Error Trap Register).

By using the Peripheral View, engineers can gain further insights into the error, such as the exact memory address that triggered the trap.

Using the Peripheral View in TRACE32, we can inspect the following registers:

• DIETR: CPUx Data Integrity Error Trap Register
  
  
  • IED: Indicates that a data integrity error condition has been detected
    
    
  • IE_S: Integrity Error in Scratchpad Memory
    
    
  • Dual-bit error detected
    
    
• DIEAR: Data Integrity Error Address Register
  
  

In this case, the memory access that triggered the trap is 0x7000001C.

For synchronous traps, the Stack Frame window can provide additional details, including the exact instruction that caused the trap. However, since a DIE trap is asynchronous, the precise instruction responsible cannot be directly determined. The trap may occur several instructions after the problematic access. Using Frame.Up in such scenarios may therefore lead to incorrect conclusions.

In the following example, the stack unwinding reveals that the DIE trap occurred while the CPU attempted to read from address 0x70000020, whereas the Data Integrity Error Address Register (DIEAR) shows that the error was actually caused by an earlier read at 0x7000001C.

Using Trace
 Another effective debugging method is to utilize MCDS tracing.
 Because this trap was triggered by a memory access, tracing both the program flow and data accesses provides a more complete understanding of the issue.

In the Trace.List window, a trap marker appears shortly after a byte write operation to the DSPR (Data Scratch-Pad RAM) of TriCore0.

Root Cause & Solution
 The DSPR (Data Scratchpad RAM) is protected by ECC and must be properly initialized before any read operation. Initialization can be carried out either by software or automatically by hardware through UCB_DFLASH.PROCONRAM.

For half-word or larger write operations, ECC bits are pre-calculated and written together with the data. However, byte write operations are internally converted into a half-word read–modify–write sequence within the DMI module, which led to the detection of uncorrectable memory integrity errors.

Solution:
 This issue can be resolved by enabling RAM initialization via the Startup Software (SSW – the boot ROM) in UCB_DFLASH.