Skip to main content

[TriCore] Debugging safety-critical applications - Knowledgebase / FAQs by core architecture / TriCore - Lauterbach Support

[TriCore] Debugging safety-critical applications

When debugging with SMU enabled, unwanted security/safety alerts may be reported. To understand the cause of a reported alarm, please consult Infineon documentation for your chip. Nevertheless, in the following, the most common issues are discussed.

Bus Errors

If the SMU is set up strict, some debugger accesses might cause SMU Alarms (bus errors). The reason is that the chip can not differentiate between illegal and debugger accesses. 

The solution is to prevent all debugger accesses to problematic memory ranges.

  • Prevent debugger access to:
    • Non-initialized peripheral modules
    • Non-mapped or non-initialized memory
    • Erased PFLASH (returns bus errors due to wrong ECC). It is to be considered that List.auto window also reads before the displayed code range for the correct functioning of the disassembler. This is often a problem at the reset vector given that its address is set at the start of PFLASH or following an erased PFLASH range. The command MAP.DenyAccess <addressrange> can be used.
  • Prevent the debugger from trying to set software breakpoints on PFLASH. Newer TRACE32 versions (starting from R.2019.09) use an improved FLASH address range model to decide whether a program breakpoint is to be implemented as an onchip breakpoint.
    • Use Break.CONFIG to configure the behavior of different breakpoint types as well as their scope.
    • Use MAP.BOnchip <addressrange> to force the debugger to set onchip breakpoints in the respective memory range.

TriCore Watchdog Timer

By default, the TriCore watchdog timer is disabled when OCDS is enabled, i.e. when the debugger is attached. Some safety tests (e.g. SafeTLib) report this as a failure.
The solution is to keep the TriCore watchdog timer enabled and link it to the suspend bus for synchronous start/stop with the TriCore cores.
Set:

  • SYStem.Option.WDTSUS ON
  • SYStem.Option.PERSTOP ON

TRACE32 Cache Handling

Cache evaluation and cache inspection require that TRACE32 can read the cache tags and contents. AURIX CPUs allow reading this by mapping the cache into the CPU address space using the MTU. As soon as the cache is mapped by TRACE32, the CPU will clean the cache content due to security reasons. This might be reported as a security/safety alarm.

  • Cache mapping can be disabled using the command SYStem.Option.MAPCACHE OFF in case of unwanted security/safety alerts.
  • TRACE32 R.2020.09 or newer avoids safety alarms originating from mapping the cache into memory by temporarily disabling these alarms.
Helpful Unhelpful

6 of 6 people found this page helpful

Add a comment

ID-0
To prove you are a human, please tell us the text you see in the CAPTCHA image