9160 Resetting

[Benjamin]

Developing on nrf9160 using NCS 2.1.2 and MFW 1.3.3, is there any sort of Hard Fault detection and handler besides the k_sys_fatal_error_handler hook in lib/fatal_error/fatal_error.c? We're seeing resets again on a non-secure build for the nrf9160 that don't hit the error handler (which in this case, is overwritten by Nordic), so we don't get any information about the reset besides the reset reason being 0x00010000, which is AIRCR.SYSRESETREQ , but isn't coming from the error handler?

I've looked through the documentation, but don't see a list of everything that can cause that. Could it be the modem setting a reset? This has proven difficult to resolve since it isn't coming through the error handler, so there is no information beyond the reset reason register.

[Hakon]

Hello,

Could it be the modem setting a reset?

it's possible. The is a hard fault handler in the modem lib. Have you checked if this is causing it?

[Benjamin]

I'm not seeing the `

LOG_INF("Modem has faulted, re-initializing");

` message at all. I'll try on a debugger in a bit. This is what the debug output looks like:

As you can see, there is no message or error printed out at all. This will happen over and over. The reset reason is the RR value, which you can see is 0x00010000, which is AIRCR.SYSRESETREQ 

[Amanda Hsieh]

Hi, 

Håkon is out of the office, so I take this case. 

nRF9160 performs a "Soft reset" when AIRCR.SYSRESETREQ is set.

https://infocenter.nordicsemi.com/topic/ps_nrf9160/pmureset.html

Do you have any more logs or outputs from when this happens? It would be useful if you could capture a modem trace from when this type of reset occurs. 

Are you able to reproduce the issue when using nRF9160 DK?

Which nRF9160 SiP revision are you using? Is the SiP marked 'B0' or 'B1'?

Would you be able to share the schematic? Has anyone at Nordic performed an HW review? We do this for free on the part of the design related to nRF parts.

Is this a custom board? Is it battery-powered? Have you measured the VDD voltage level?

Looking at the RESETREAS register, we can see that this reset reason is an SREQ(software/soft reset, i.e. NVIC_SystemReset()), so your code likely runs into an error and resets. To debug this further, try:

CONFIG_RESET_ON_FATAL_ERROR=n

CONFIG_DEBUG=y

You could also try:

CONFIG_REBOOT=n

Please keep in mind that the reset reason register is not cleared automatically. You will have to clear it in order to know whether it has happened again.

Regards,
Amanda H.

[Benjamin]

It appears that a 3rd party library we are using is causing the reset. They are investigating this now.

I have tried setting CONFIG_REBOOT=n and it still resets and doesn't go through the fatal error handler. I'm wondering if it ends up being a NULL pointer exception because we are running non-secure and I read that non-secure doesn't properly catch NULL pointer exceptions.

[Amanda Hsieh]

Happy to know you find the cause. Thanks for the update. 

-Amanda H.