Pointers on how to debug nRF9160 soft reset

RE: Pointers on how to debug nRF9160 soft reset

WoutWG — Fri, 27 Sep 2024 18:42:06 GMT

Hi Vidar,

Thanks, but this doesn't work for me, I assume because I'm on v2.5.0. The only way I 'know' that this secure fault happens is because the application resets, so the only way I have to 'catch' the error is by setting a breakpoint at the start of main(). But at this stage, there is no more exception handler to inspect the call stack of.

So far I have been able to identify errors more quickly now that I know what to look for. If it really starts becoming an issue again, I'll upgrade to v2.6.0+ to enable the fatal error handler which should provide more information as to where the error occurs.

RE: Pointers on how to debug nRF9160 soft reset

Vidar Berg — Wed, 25 Sep 2024 08:36:02 GMT

Hi,

The secure fault handler is implemented in the TF-M application, not in the main application. But you can start a debug session with the main app and inspect the call stack after the secure fault has been raised.

e.g., dereferencing NULL pointer to trigger a secure fault:

RE: Pointers on how to debug nRF9160 soft reset

WoutWG — Tue, 24 Sep 2024 11:20:29 GMT

Hi Vidar,

That's very helpful. I'll consider upgrading to v2.6.0, but in the meantime, is there a way to debug secure faults while on v2.5.0?

Searching the sdk files, I found a reference to a 'secure_fault' function in zephyr>arch>arm>core>aarch32>cortex_m>fault.c, but it is only enabled when CONFIG_ARM_SECURE_FIRMWARE is defined which isn't the case for my application (it's not even mentioned in .config in my build output, not even commented out), so it seems that this is not the error handler that I'm after.

RE: Pointers on how to debug nRF9160 soft reset

Vidar Berg — Tue, 24 Sep 2024 09:27:57 GMT

Hi,

Good catch. I think in v2.6.0 and later, a secure fault in the TF-M will be forwarded to the fatal error handler in the main app. Thus, making it easier to catch secure faults. The CONFIG_RESET_ON_FATAL_ERROR setting is also applied to the error handling in the TF-M image.

[quote user="WoutWG"]I just had another encounter (different from the one that made me open this ticket) and I found that the issue was that I was (re)scheduling a delayable work that I forgot to initialize first. I'm not sure if this would 'normally' (when not using tfm) result in a hard fault or anything that should leave a trace to help with debugging this?[/quote]

I assume this lead to a secure fault. This can happen if the app tries to access secure RAM. For instance, when dereferencing a NULL pointer.

RE: Pointers on how to debug nRF9160 soft reset

WoutWG — Mon, 23 Sep 2024 11:06:50 GMT

Hi Vidar,

Thank you for your feedback. I tried setting the breakpoint both in NVIC_SystemReset() and in sys_arch_reboot() (in scb.c), but the code doesn't seem to hit either of these lines as it's not breaking there.

I checked my .config file in my build folder and CONFIG_RESET_ON_FATAL_ERROR is set to "y".

I just had another encounter (different from the one that made me open this ticket) and I found that the issue was that I was (re)scheduling a delayable work that I forgot to initialize first. I'm not sure if this would 'normally' (when not using tfm) result in a hard fault or anything that should leave a trace to help with debugging this?

RE: Pointers on how to debug nRF9160 soft reset

Vidar Berg — Fri, 20 Sep 2024 12:37:29 GMT

Hello Wout,

Please try to place a breakpoint in NVIC_SystemReset() to see if it may be called elsewhere in your application. Usually it is only called from the fatal error handler when CONFIG_RESET_ON_FATAL_ERROR=y.

Best regards,

Vidar

EDIT: if the debugger won't let you place the breakpoint in the inline function, you can place it in sys_arch_reboot() instead.