Inconsistent RESETREAS Values on nRF52832 for Power on reset, Brown-Out, and Wake-from-System-OFF (GPIO)

[AlbinMathewC3]

Hi,

I am working on an nRF52832 using nRF5 SDK 16.0 and I am seeing inconsistent behaviour in the RESETREAS register. During a power-on reset, the value is usually 0 but occasionally appears as 4, so I am unsure whether 0 is the correct indication for a true POR. Software resets consistently show 4, which seems correct.

I also see an issue when the device wakes from System OFF. I put the device into deep sleep using sd_power_system_off(), and it wakes through a GPIO interrupt. However, instead of the expected 0x10000 (GPIO wake-up), the RESETREAS register still reports 4, as if it were a software reset. I would also like to understand whether the nRF DFU bootloader reads, clears, or modifies the RESETREAS register before my application starts.

After checking similar issues on the forum, I found suggestions to clear the reset reason register. But when I tested nrf_power_resetreas_clear(), calling it immediately triggers a software reset. I am not sure whether this behaviour is expected or if there are specific constraints when clearing the register.
I would appreciate guidance on how to reliably detect a true power-on reset or brown-out, why System OFF wake-ups appear as software resets, and whether the DFU bootloader affects RESETREAS behaviour.

Thanks & Regards,

Albin Mathew

[Kenneth]

Hello,

So these are the reset reasons: https://docs.nordicsemi.com/bundle/ps_nrf52832/page/power.html#d935e3470 

There is one issue: https://docs.nordicsemi.com/bundle/errata_nRF52832_Rev3/page/ERR/nRF52832/Rev3/latest/anomaly_832_136.html#anomaly_832_136 

Beside that do check if it's possible you have any bootloader that may be running and interfering with the results. Also be aware that if you have just programmed the chip, then the chip is in debug interface mode, so until you do a hard reset I would expect you can't fully trust the reset sources (since for instance it will be in emulated system off if in debug interface mode, which is not really a low power system off mode). Final comment, also be aware that there are a few cases in the system_nrf52.c that a soft reset may occur upon startup, for instance if you have configured to enable pin reset, it may need to perform one soft reset to enable pin reset.

Kenneth

[AlbinMathewC3]

Hi Kenneth,

Thank you for the quick response.

I have reviewed the bootloader, and the suggested workaround has already been implemented.

I am using the sd_power_system_off() API to put the device into sleep mode. My understanding is that waking up from this API call should occur via a GPIO wake-up event.

However, the issue is not limited to the initial startup; it has been observed in multiple scenarios. The unusual part is that when I attempt to clear the previously read reset reason, the system unexpectedly restarts.

I would appreciate your thoughts on this behavior. Please let me know if you require any additional information from my side.

Best regards,
Albin

[Kenneth]

Hello,

With SoftDevice enabled, access to POWER (including RESETREAS) is restricted, and you must clear reset reasons via sd_power_reset_reason_clr().

Kenneth

[Klaus01]

Don't know if it still matters, but I struggled with a very similar issue (GPIO not properly detected after wake-up).

Please see this thread:  Preserving reset reason with NRF bootloader (SDK15.2) 

The bootloader code in components/libraries/bootloader/nrf_bootloader.c (around line 247) does

nrf_power_resetreas_clear(NRF_POWER_RESETREAS_OFF_MASK);

which breaks my application.

I copied the "original" nrf_bootloader.c file into my own repository, disabled that line there and linked my bootloader with this replacement instead of modifying the "original" SDK file.