This topic explains what an application reset is, why it affects breakpoint detection, and provides potential workarounds for debugging HSM (Hardware Security Module) cores effectively.
In the context of AURIX debugging, an application reset refers to a reset initiated by the application code, typically running on the TriCore in the AURIX microcontroller. Unlike a normal PORST (Power-On Reset), an application reset is not detectable by the debugger in real time and is too short to re-apply breakpoints within the HSM core for debugging of the code that is executed shortly after reset (i.e., startup code).
In the case of HSM cores, breakpoints are disabled after an application reset due to the immediate startup of the HSM without waiting for debugger reconnection.
This workaround involves setting breakpoints on the part of the code and placing a breakpoint close to the reset entry on CPU0. After a reset and run, CPU0 will stop, which ensures a big enough timeframe for the breakpoints on the HSM core to be re-applied.
You should also sync the two and enable the option Synchronize this core cores in Hardware | CPU Options | Cores.
This method may not be suitable for time-critical applications and requires manual intervention during debugging.
One approach is to modify the HSM code to introduce delays or wait-loops (e.g., bootCounter) that give the debugger sufficient time to re-enable breakpoints. This method, however, may impact the startup time of the HSM and requires careful consideration of application timing requirements.
Example:
volatile unsigned long bootCounter; while (bootCounter++ < 0x00600000);