nRF52 spurious resets with SDK12.2.0 - How to resolve?

[trigerion]

Hello,

we have developed a solar powered LED module with an additional battery. It is based on the nrf52832. The WDT and TWI is mainly used and for BLE the soft device is applied. From time to time, the NRF resets itself. I do not really know, how to debug the problem, as it takes days or even weeks that it happens. Using RTT does not work, as it clears it buffers when reseting. We tried to store every possible error as some int value in the flash, but for that specific error, nothing is written. So we do not know what the problem could be. The TWI implementation uses timeouts and un/init in case of an error. Thus I do not believe that this is the problem.

Any suggestions to gain more insights?

[Update: The RESETREAS register is telling me 0x00000004; thus software reset. I implemented 'assert_nrf_callback(uint16_t, const uint8_t*)', 'app_error_fault_handler(uint32_t, uint32_t, uint32_t)' and 'HardFault_Handler(void)' and have there a while loop. As the WDT is activated, a WDT event should occur if these functions are active. I do not use 'NVIC_SystemReset()'. So how to proceed? Right now it is getting critical, as we get some complains about that spurious resets ... ]

Thanks.

[Hung Bui]

Hi Trigerion,

I assume the issue doesn't happen if you run in debug mode (and set break point in assert handler) ?

You should also check the reset reason (RESETREAS register) when booting up, so you can find the reason of the reset. Is there any possibility that the solar power was not able to provide enough power to keep the chip running ? Or some latency causing the WDT not being served ontime ?

[butch]

Do you have any soft resets in your code? (If not, it must be a hard reset, either from the reset pin or from PowerOnReset POR or BOR if your Vcc falls below 1.7V temporarily?)

Do you have brownout detection implemented? You could write a flag in flash (UICR) in your brownout handler. Note that the system disables flash when it brownouts, but in your handler, you can reenable it. Since you have a battery, I would not expect a brownout but maybe your Vcc has a glitch, a brief dip.
Have you read RESETREAS register?

Do you have a power analyzer instrument?

(I also have struggled with solar powered radio, w/o a battery. It is tough.)

[trigerion]

Thanks for your replies. I deleted the RESETREAS register in the bootloader until now. Thus the value was always zero :( ... Hopefully next time I will see the reason. WDT not served, could be but it is two seconds and I trigger it in 10 Hz timer event and don't use while(1) without timeout condition. BOR I can't believe as I use a Li-Po and disconnect the BLE module when measuring less than 3.2V. The main problem is that the problem does not appear often. Took days or even weeks, thus debugging via debugger is very hard to achieve. I use four modules in parallel to have a better probability ...

[trigerion]

Well, today it happened again and the RESETREAS value is 0x00000004. So reset from software. But in all of my code, I have not used 'NVIC_SystemReset()'. Any further hints?

[Hung Bui]

Have you made sure it's not called from one of the app_error_fault_handler() or app_error_fault_handler() ? Please define DEBUG and DEBUG_NRF in the preprocessor setting. To avoid softreset in the assert handler.