Infineon TriCore: How to detect software resets

30-Jul-2024

Below you can find a few solutions on how to detect software resets before they occur or figure out why they happen. 



Possible solutions

Place Execution Breakpoint in startup code

This method will help you understand which agent triggered the reset.

1. Locate your startup code.

2. Place a breakpoint there and wait for a reset. Breakpoints will stay enabled through both Application and System reset.

3. After the breakpoint is hit, inspect the RCU plugin via View | [SoC] AURIX | RCU. With the help of the RCU_RSTSTAT register, you will be able to determine what triggered the reset.


This method can also be used for external resets (e.g. ESR reset).

This method cannot be used for LBIST reset, as LBIST clears breakpoints and is not observable externally.



Place an Access Breakpoint on write to SWRSTCON register

This method will help you understand why your application triggered the reset.

1. Open the Hardware Breakpoints dialog via Debug | Hardware Breakpoints.

2. Configure a breakpoint to trigger when a write to SWRSTCON is made:

a. Address should be set to address of SWRSTCON register (0xF0036060 in case of TC38x; consult your MCU's user manual for the correct address.

b. Hit only on WRite access.

c. Event associated should be Halt.

d. CDC suspend-out will suspend other cores and peripherals.

e. Break before make will halt the core before the instruction is executed (instead of after)



    3. Wait until your breakpoint is hit. After the CPU stops, inspect the Callstack Window via View | Debug | Callstack to find out why the reset was initiated.



    This method can only be used for software resets and not for external resets (e.g. ESR).

    Was this answer helpful?