nRF52832 resets ~20 s after entering System OFF (watchdog)

[mento]

We are using nRF52832 with NCS(v2.9.2)/Zephyr and the watchdog (20 s timeout). When the application enters System OFF (e.g. after idle), the device goes to sleep but then resets after about 20 seconds. We see the bootloader and application start again, so it looks like a watchdog reset.
We feed the watchdog before starting the shutdown sequence and before writing the SYSTEMOFF register, but the device still resets about 20 seconds later. We cannot disable the watchdog on nRF52832 (no STOP support).
Question: What is the recommended way to enter System OFF on nRF52832 when the watchdog is enabled, so that the device stays off and is not reset by the watchdog after ~20 seconds?
Thank you.

[mento]

Thank you for the earlier replies. You mentioned that the WDT cannot run in System OFF, so a WDT reset would mean the device did not really enter System OFF. We have changed our implementation to use Zephyr’s recommended path and are still seeing the same behavior.What we changed

• Entering System OFF — Before: we wrote NRF_POWER->SYSTEMOFF = 1 directly and then a WFE loop. After: we now call sys_poweroff() from <zephyr/sys/poweroff.h> with CONFIG_POWEROFF=y and CONFIG_PM_DEVICE=y. On nRF52 this goes through zephyr/soc/nordic/common/poweroff.c and calls nrf_power_system_off(NRF_POWER). Before calling sys_poweroff() we optionally suspend the console with pm_device_action_run(cons, PM_DEVICE_ACTION_SUSPEND) as in the samples/boards/nordic/system_off sample.

• Watchdog — We still use the Zephyr WDT driver with WDT_OPT_PAUSE_IN_SLEEP, and we now get the device from DT_ALIAS(watchdog0) when present (same style as Zephyr watchdog sample). We still feed the watchdog once before sys_poweroff().

• Kconfig — We added CONFIG_POWEROFF=y and CONFIG_PM_DEVICE=y.

So we are no longer touching the SYSTEMOFF register directly; we use the Zephyr power manager (sys_poweroff()).Current behaviorWith this setup we still see the device reset about 20 seconds after requesting System OFF. On the next boot we log RESETREAS = 0x00000002 (DOG). So it still looks like the device is not actually entering System OFF, or something is causing it to leave System OFF and then get hit by the watchdog.We can provide an updated fsm_test_min (or patch) that uses sys_poweroff() instead of the register write if that would help. Could you suggest what to check next—e.g. whether there is anything else that could prevent the SoC from entering System OFF even when using sys_poweroff(), or any recommended sequence/Kconfig for nRF52832 with WDT and System OFF in NCS 2.9.x?Thanks.

[Eetu Nevalainen]

We’re seeing the same issue with nRF9160 based boards: watchdog resets after sys_poweroff(). We reduced them a lot by adding k_sleep(K_SECONDS(4)) before calling sys_poweroff(), but they still happen occasionally with nRF SDK v2.9.0. I’ll try to find some time this week to reproduce it and measure the power consumption to see if the device actually goes into system off.

Edit: We first noticed this issue on nRF SDK v2.5.2.

[mento]

Thanks for looking into this.

At the moment I don’t have the equipment to measure current, so I’m focusing on RESETREAS + behavior.

We can reproduce the issue consistently with our minimal app:
- nRF52832, NCS v2.9.2
- sys_poweroff() (CONFIG_POWEROFF=y, CONFIG_PM_DEVICE=y)
- Watchdog enabled (20s, WDT_OPT_PAUSE_IN_SLEEP)

In problematic cases, the next boot reports RESETREAS = DOG (0x00000002) about ~20s after requesting System OFF, instead of RESETREAS = OFF.

If you manage to reproduce and identify the root cause, could you please share:
- How to verify whether the device truly enters System OFF (without current measurement, if possible), and
- The recommended fix / workaround, or the NCS version / commit where it is fixed?

I’m happy to retest any patch or specific version you recommend and report back the results.

[Vidar Berg]

Hello,

I ran your project and see that you are powering OFF the RAM in your enter_system_off() which leads to a lockup reset (you are effectively disabling the RAM while the program is still running) followed by a WDT reset. The device never actually entered System OFF mode.  I recommend you remove this section from your function:

#if defined(NRF52832_XXAA) || defined(NRF52840_XXAA)
    NRF_POWER->RAM[0].POWER = 0;
    NRF_POWER->RAM[1].POWER = 0;
    NRF_POWER->RAM[2].POWER = 0;
    NRF_POWER->RAM[3].POWER = 0;
    NRF_POWER->RAM[4].POWER = 0;
    NRF_POWER->RAM[5].POWER = 0;
    NRF_POWER->RAM[6].POWER = 0;
    NRF_POWER->RAM[7].POWER = 0;
#endif

And instead use the sys_poweroff() call. In addition to entering System OFF, this call turns off RAM retention in System OFF mode as you can see here: https://github.com/nrfconnect/sdk-zephyr/blob/49e3fe1e493137cb9e1c895f8000fe638927d0c3/soc/nordic/common/poweroff.c#L52 

[mento]

Hello Vidar,Update with hard evidence from our fsm_test_min reproduction.We added two persistent breadcrumbs written immediately before sys_poweroff():GPREGRET0 is set to 0xA5 right before calling sys_poweroff().GPREGRET1 bit0 stores debugger_attached() at that moment.After an unexpected restart (no user interaction), the next boot prints:GPREGRET0=0x000000A5GPREGRET1=0x00000000RESETREAS=0x00010000 -> Wake from System OFFSo the device did reach sys_poweroff(), there was no debug interface active, and RESETREAS shows an OFF wake (not DOG). This means the SoC enters System OFF successfully, but later wakes from System OFF unexpectedly.Question:What is the recommended way on nRF52832 to identify which wake source caused the OFF wake (e.g., GPIO LATCH registers or any Zephyr/Nordic API)?Any known pitfalls/best practices to avoid unintended OFF wakes when using GPIO sense?Best regards, 
Mento