CPU Trap Recognition 1 for KIT_AURIX_TC297_TFT

Scope of Work

This example demonstrates how to identify the root cause of a trap. The tutorial describes the types of traps supported by the AURIX™ microcontroller, their root causes, and methods for identification. The AURIX™ architecture supports various trap types. Three distinct traps can be provoked using this example, and the tutorial guides the user through the necessary steps to observe the root cause of each trap.

Introduction

• A trap occurs as a result of an event such as a Non-Maskable Interrupt (NMI), an instruction exception, a memory management exception, or an illegal access. Traps are always active and cannot be disabled by software.
• The TriCore™ architecture specifies eight general classes for traps. Each trap class has its own trap handler. Within each class, specific traps are distinguished by a Trap Identification Number (TIN).
• Traps can be further classified as synchronous or asynchronous, and as hardware or software generated.
• Three different combinations of trap types are supported:
  • Synchronous and hardware generated
  • Asynchronous and hardware generated
  • Synchronous and software generated

Hardware Setup

This code example has been developed for the board KIT_AURIX_TC297_TFT_BC-Step.

[Description of PCB image: The image displays the KIT_AURIX_TC297_TFT_BC-Step development board, featuring a red printed circuit board with numerous electronic components, including microcontrollers, memory chips, passive components, and a display screen.]

Implementation: Supported Traps

The following table provides an overview of all supported traps and their types:

Please refer to the TriCore™ TC1.6.1 core architecture manual and the AURIX™ TC29x B-Step User's Manual for detailed information about each trap.

Implementation: Trap Types

Synchronous Traps: Synchronous traps are associated with the execution or attempted execution of specific instructions or with attempts to access a virtual address that requires the intervention of the memory-management system. The trap is triggered and serviced immediately.

Asynchronous Traps: Asynchronous traps are associated with hardware conditions and are similar to interrupts. They are routed via the trap vector. Some asynchronous traps are triggered indirectly from instructions previously executed, but the direct association with the causing instructions is lost.

Hardware Traps: Hardware traps are generated in response to exception conditions detected by the hardware. In most cases, these conditions are associated with the attempted execution of a particular instruction.

Software Traps: Software traps are generated intentionally as a result of executing a system call or an assertion instruction.

Implementation: Trap Handling

• When a trap occurs, a trap identifier is generated by hardware. This identifier has two components used to determine more information about the trap and its cause (refer to the 'Supported Traps' section):
  • The Trap Class Number (TCN)
  • The Trap Identification Number (TIN)
• In most cases, the debugger will stop code execution within one of eight trap handlers (implemented in the iLLD header IfxCpu_Trap.c).
• An instance of the structure IfxCpu_Trap is declared within each trap handler. When a trap occurs, this instance provides four information fields about the trap:
  • tCpu: Identifies which CPU caused the trap.
  • tClass: TCN, the Class of the trap (refer to 'Supported Traps').
  • tId: TIN, the Id of the trap (refer to 'Supported Traps').
  • tAddr: The Return Address (RA) (refer to the next section).

Implementation: Return Address

The Return Address (RA) can help locate the specific line of code that caused the trap. The return address is stored in the IfxCpu_Trap structure instance and read from the return address register A[11].

The return address differs depending on the trap type:

• For most synchronous traps, the return address is the 32-bit Program Counter (PC) of the instruction that caused the trap. The PC holds the address of the instruction currently running when the core is halted.
• On a System Call (SYS) trap, triggered by the SYSCALL instruction, the return address points to the instruction immediately following SYSCALL.
• A Free Context List Depletion (FCD) trap is generated after a context save operation that makes the free context list nearly empty. The FCD trap can be caused by a hardware interrupt or a trap handler. The context save operation is typically completed before the FCD trap executes. Consequently, the return address for an FCD trap is the first instruction of the trap/interrupt/called routine or the instruction following a Save Lower Context (SVLCX) or Begin Interrupt Service Routine (BISR) instruction.
• For an asynchronous trap, the return address is the address of the instruction that would have been executed next had the asynchronous trap not been triggered.

Implementation: Additional Debug Information

• The ERROR_ADDRESS bit field in the Data Error Address Register (DEADD) contains trap address information for data memory. The DEADD content is valid if the Data Synchronous Trap Register (DSTR) or the Data Asynchronous Trap Register (DATR) are non-zero (depending on the trap type). The bit fields in DSTR and DATR can provide additional information about the trap (refer to the TC29x B-Step User's Manual).
• This information is valid for the following traps:
  • Data Address Alignment (ALN)
  • Data Access Synchronous Error (DSE)
  • Data Access Asynchronous Error (DAE)
  • Invalid Local Memory Address (MEM)
  • Memory Protection Write (MPW)
  • Memory Protection Read (MPR)
  • Memory Protection Peripheral Access (MPP)
  • Memory Protection Null Address (MPN)
• The Program Memory Interface Synchronous Trap Register (PSTR) contains synchronous trap information for the program memory system and is updated with trap information for Program Fetch Synchronous Error traps (PSE).
• The Program (or Data) Integrity Error Address Register (PIEAR / DIEAR) and the Program (or Data) Integrity Error Trap Register (PIETR / DIETR) can be interrogated to determine the source of the Program (or Data) Memory Integrity Error (PIE / DIE) more precisely.

Implementation: Trap Provocation

• Three different combinations of trap types can be provoked in this example:
  • Synchronous Hardware trap
  • Asynchronous Hardware trap
  • Synchronous Software trap
• Trap provocation is implemented in the function `run_trap_provocation()` and can be initiated by setting one of the three `g_provokeXYTrap` variables (where X = Synchronous / Asynchronous; Y = Hardware / Software).
• The code for the first two traps is based on the MTU_MBIST_1 and SMU_IR_Alarm_1 examples. Refer to specific tutorials for more information on the code.
• The third trap is provoked using two instructions: `_mtcr()` (Move To Core Register) and `trapv` (assembly code). Consult the TriCore™ TC1.6.1 core architecture manual - Instruction set manual for details on these instructions.
• For a better understanding of trap behavior, the required code instructions to avoid trap causes are implemented and can be activated by setting the `AVOID_PROVOCATION` macro to true.

Run and Test

After code compilation and flashing the device, perform the following steps:

• Add the variables `g_provokeSynchronousHardwareTrap`, `g_provokeAsynchronousHardwareTrap`, and `g_provokeSynchronousSoftwareTrap` in the Expressions window of the debugger.
• Add the registers DEADD, DATR, and DSTR in the Expressions window of the debugger.

1.1 Synchronous Hardware Trap

• Provoke the synchronous hardware trap by setting the value of `g_provokeSynchronousHardwareTrap` in the Expressions window to `1`.
• Press the Resume button to start the program.
• Observe the following information:
  • The debugger stops in the `IfxCpu_Trap_busError()` function (`IfxCpu_Trap.c`).
  • The Variables window of the debugger displays the `trapWatch` structure and its parameter values.
  • The trap is provoked by CPU0, is a trap of class 4, has trap ID 2, and the Return Address (RA) is `0x80000042` (2147483714₁₀).
  • It is a Data Access Synchronous Error (refer to Trap table, class 4 and tin 2).

1.2 Synchronous Hardware Trap (Debug View)

Observe the following information:

• The call stack in the Debug window displays the function called before the trap occurred (in this case, `run_trap_provocation()`). The address displayed behind this function equals the Return Address (RA).
• Clicking on this function in the debugger navigates to the specific code line in the `CPU_Trap_Recognition.c` file and the corresponding assembly line in the Disassembly window. The address of the assembly line matches the Return Address (RA).

1.3 Synchronous Hardware Trap (Additional Information)

Observe the following additional information:

• The LBE bit field in the DSTR register is set (Load Bus Error - Data load from bus causing error, refer to AURIX™ TC29x B-Step User's Manual).
• The DEADD register displays the address `0xf00663a0`, which is the address of the modified register that caused the trap.
• By performing a file search (Search -> File) for the address `0xf00663a0`, the search finds the specific RDBFL0 register, which corresponds to the modified MBIST DMA register.

2.1 Asynchronous Hardware Trap

• Restart the program by pressing the Restart button in the debugger.
• Provoke the asynchronous hardware trap by setting the value of `g_provokeAsynchronousHardwareTrap` in the Expressions window to `1`.
• Press the Resume button to start the program.
• Observe the following information:
  • The debugger stops in the `IfxCpu_Trap_busError()` function (`IfxCpu_Trap.c`).
  • The Variables window of the debugger displays the `trapWatch` structure and its parameter values.
  • The trap is provoked by CPU0, is a trap of class 4, has trap ID 3, and the Return Address (RA) is `0x80000038` (2147483704₁₀).
  • It is a Data Access Asynchronous Error (refer to Trap table, class 4 and tin 3).

2.2 Asynchronous Hardware Trap (Debug View)

Observe the following information:

• The call stack in the Debug window displays the function called before the trap occurred (in this case, `run_trap_provocation()`). The address displayed behind this function equals the Return Address (RA).
• Clicking on this function in the debugger navigates to the specific code line in the `CPU_Trap_Recognition.c` file and the corresponding assembly line in the Disassembly window. The address of the assembly line matches the return address.
• Because it is an asynchronous trap, the specific code line does not point to the instruction causing the trap. Instead, it points to the instruction that would have been executed next had the asynchronous trap not been triggered.
• Since there are no other instructions within the `run_trap_provocation()` function in this example, it is impossible to find the exact line of code using the Return Address (RA).

2.3 Asynchronous Hardware Trap (Additional Information)

Due to the fact that the Return Address (RA) cannot be directly used to pinpoint the cause, the following information may help locate the trap's origin:

• The SBE bit field in the DATR register is set (Store Bus Error - Data store to bus causing error, refer to AURIX™ TC29x B-Step User's Manual).
• The DEADD register displays the address `0xf003682c`, which is the address of the modified register that caused the trap.
• By performing a file search (Search -> File) for the address `0xf003682c`, the search finds the specific SMU_AGC register, which matches the modified register. The name of the modified register (SMU_AGC) aids in finding the code line causing the trap, potentially through another search for "AGC".

3.1 Synchronous Software Trap

• Restart the program by pressing the Restart button in the debugger.
• Provoke the synchronous software trap by setting the value of `g_provokeSynchronousSoftwareTrap` in the Expressions window to `1`.
• Press the Resume button to start the program.
• Observe the following information:
  • The debugger stops in the `IfxCpu_Trap_assertion()` function (`IfxCpu_Trap.c`).
  • The Variables window of the debugger displays the `trapWatch` structure and its parameter values.
  • The trap is provoked by CPU0, is a trap of class 5, has trap ID 1, and the Return Address (RA) is `0x80000090` (2147483792₁₀).
  • It is an Arithmetic Overflow Error (refer to Trap table, class 5 and tin 1).

3.2 Synchronous Software Trap (Debug View)

Observe the following information:

• The call stack in the Debug window displays the function called before the trap occurred (in this case, `run_trap_provocation()`). The address displayed behind this function equals the Return Address (RA).
• Clicking on this function in the debugger navigates to the specific code line in the `CPU_Trap_Recognition.c` file and the corresponding assembly line in the Disassembly window. The address of the assembly line matches the Return Address (RA).

References

• AURIX™ Development Studio is available online: https://www.infineon.com/aurixdevelopmentstudio. Use the „Import..." function to access more code examples.
• More code examples can be found on the GIT repository: https://github.com/Infineon/AURIX_code_examples.
• For additional trainings, visit our webpage: https://www.infineon.com/aurix-expert-training.
• For questions and support, use the AURIX™ Forum: https://www.infineonforums.com/forums/13-Aurix-Forum.

Revision History

Trademarks and Notices

All referenced product or service names and trademarks are the property of their respective owners.

Edition: 2020-12

Published by: Infineon Technologies AG, 81726 Munich, Germany

© 2020 Infineon Technologies AG. All Rights Reserved.

Document reference: CPU_Trap_Recognition_1, _KIT_TC297_TFT

Questions about this document? Email: erratum@infineon.com

Important Notice: The information provided in this document is not a guarantee of conditions or characteristics. Infineon Technologies disclaims all warranties and liabilities regarding examples, hints, or typical values stated herein, including warranties of non-infringement of intellectual property rights. All information is subject to customer compliance with obligations and applicable legal requirements.

The data is intended exclusively for technically trained staff. It is the responsibility of customer's technical departments to evaluate product suitability for intended applications and completeness of information.

For further information on products, technology, delivery terms, conditions, and prices, please contact your nearest Infineon Technologies office (www.infineon.com).

Warnings: Products may contain dangerous substances due to technical requirements. Contact Infineon Technologies for information on such substances. Infineon Technologies' products must not be used in applications where failure could reasonably result in personal injury, unless explicitly approved in writing by Infineon Technologies.