Hello, You have encountered a trap. To Investigate the cause behind this trap you can use the TRACE32 trap decoding option by selecting to the TRACE32 menu 'TC37x' > 'Special decoders' > 'active trap decoding'. This action will display the Trap Class and Trap Identification Number (TIN) in the AREA window. You can then refer to the "TriCoreTM TC1.6.2 core architecture manual" document, specifically under section "6 Trap System", to gain insight into the trap reason.

Hello Moez Mefteh, It seems that there is a misunderstanding. When MCU is running application and receives a “go to boot loader” command from CAN bus, MCU should reset and then go to boot loader. MCU should keep running, should go to boot loader and should not halt after reset. If MCU halts after reset, the software in PC or laptop will detect that MCU doesn’t response future commands and the updating application through CAN bus will fail. Currently, I set RESetBehavior to RunRestore, but TRACE32 will halt MCU when TRACE32 detects that there is MCU software reset. I don’t want TRACE32 to halt MCU when TRACE32 detects that there is MCU software reset. I want TRACE32 to keep MCU running when TRACE32 detects that there is MCU software reset.

Hello, Actually, the application is halted by a software breakpoint (debug16 instruction). If you simply want to skip the debug instructions, you can use the command “TrOnchip.SoftWare OFF”. This will silently disable all software breakpoints, as all debug instructions will be treated by the CPU as nop instructions.