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.

[Vidar Berg]

Hello,

The WDT cannot run when the device is in System OFF mode, so if you are getting a WDT reset it would indicate that the device did not really enter System OFF mode. Please try to check the RESETREAS register to confirm what the reset source was. Here is an example of a function you can use for reading this register: https://github.com/nrfconnect/sdk-nrf/blob/456f071a6f638b02e4b18819524feeec1d859dbf/samples/nfc/system_off/src/main.c#L158

Note: It is not possible to enter System OFF while the chip is in debug interface mode, see https://docs.nordicsemi.com/bundle/ps_nrf9151/page/chapters/pmu/doc/operationmodes/system_off_mode_emulated.html. That is, you can't be viewing RTT logs or in an active debug session when testing this mode.

Best regards,

Vidar 

[mento]

We want the firmware to enter low‑power sleep (System OFF) and later wake up from a GPIO pin (P0.11).Before entering System OFF, we configure P0.11 as input with no pull and enable SENSE (HIGH or LOW, depending on the current level).Observed behavior

1. Watchdog reset about 20 seconds after requesting sleep (reason unknown)

• In our application, when the firmware decides to go to sleep, it runs a shutdown path that:

• Turns off some peripherals,

• Configures P0.11 as wakeup source using GPIO SENSE,

• Finally writes NRF_POWER->SYSTEMOFF = 1.

• After calling this sleep path, we sometimes see that about 20 seconds later the system is reset by the watchdog.

• We do not know whether:

• The device actually entered System OFF and then somehow resumed incorrectly, or

• It got stuck during/after the shutdown sequence and never reached a stable low‑power state.

• From our point of view the reset reason is “watchdog timeout after trying to enter sleep”, but the root cause is unknown.

2. Sometimes the code path to enter sleep is executed, but changing P0.11 does not wake the device (reason unknown)

• From internal logging we can see that, before sleeping:

• The decision “go to sleep” is taken,

• The shutdown function is called,

• P0.11 is configured as input + NOPULL + SENSE_HIGH/SENSE_LOW,

• NRF_POWER->SYSTEMOFF = 1 is written.

• However, after this, when we change the level on P0.11, the device does not restart and we do not see any new boot behavior.

• This looks like “no GPIO wakeup occurred”, but we cannot tell whether:

• The device never really entered System OFF, or

• It entered System OFF but the GPIO SENSE wakeup on P0.11 did not work.

• Again, the exact reason is unknown.

Questions for Nordic

1. On nRF52832 with NCS v2.9.2, are there any known conditions where, after configuring a GPIO as wake source and writing NRF_POWER->SYSTEMOFF = 1, the device might:

• Fail to actually enter System OFF, or

• Enter System OFF but ignore GPIO SENSE wakeup on that pin?

2. Are there recommended best practices or restrictions for the sequence right before entering System OFF? For example:

• Types of peripheral operations (timers, interrupts, GPIO configuration, etc.) that should be avoided or handled in a specific way before calling SYSTEMOFF,

• Anything that is known to interfere with System OFF or GPIO wakeup if used incorrectly.

3. Given these two symptoms:

• (a) “After calling the sleep path, the system is reset by the watchdog about 20 seconds later (unknown reason)”, and

• (b) “The code to enter System OFF runs, but later changing the GPIO level on P0.11 does not wake the device (unknown reason)”,

do these match any known issues or typical pitfalls when using System OFF + GPIO SENSE wakeup on nRF52832?Any guidance or debugging tips for this kind of System OFF / GPIO wakeup problem would be very helpful.

[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

[Vidar Berg]

Hello,

It is difficult to track the actual number of reboots when you are powering off RAM as there will be multiple resets until the WD finally times out. Did you remove the code section as I suggested? If you are still experiencing issues after this, please upload your updated project so I can try to run it again.