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.

[mento]

Additionally, when testing with a manual jumper on the wakeup pin, we repeatedly toggle the pin between LOW and HIGH, holding each level for a long time.
Even if the SENSE polarity were initially wrong, we would still expect at least one of these slow transitions to generate an “inactive → active” edge and wake the device.
However, in the problematic firmware, the device never wakes up, which makes us suspect an issue in the System OFF entry/exit behavior rather than just a wrong SENSE configuration.

[Vidar Berg]

Let's focus on the WD reset you reported initially first.

mento said:

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

Please let me know how you determine that it was reset by a WD timeout.

mento said:

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

Have you tried measuring the power consumption in this state? The device should enter System OFF mode as long as is it not in debug interface mode.

[mento]

Thanks for your reply.

> How do you determine it was a WD timeout?

We log RESETREAS on every boot.

- In the problematic cases, the next boot reports:
- RESETREAS = 0x00000002 → DOG (watchdog)
- Not OFF
So in those cases the device is not waking from System OFF, but being reset by the HW watchdog ~20 seconds after we request System OFF.

> Did the device really enter System OFF? Have you measured current?

We agree current is the best proof. On our custom board there is no DCDC circuit; we force LDO (overlay + writing 0x40000578 = 0 in EARLY / PRE_KERNEL_1 / main()).

Without RTT/debugger attached:

- The firmware clearly runs after power-on (we see LED behavior).
- After we request System OFF, the device does not wake correctly, and the next boot shows RESETREAS = DOG instead of OFF.

We are preparing separate current measurements, but in parallel we made a very small test application to make this easier to reproduce.

Minimal test application (fsm_test_min):

- nRF52832, no BLE, just:
- DCDC disabled as in our main project.
- HW watchdog enabled (single channel, 20 s timeout, WDT_OPT_PAUSE_IN_SLEEP).
- Enter System OFF after 10 s idle.
- Wake source = GPIO P0.11 (level SENSE).

Hardware for your side:

- Connect a button (or jumper) to P0.11 so that pressing it changes the level on P0.11.
- This simulates our external wake-up source.
- Optionally connect LEDs to P0.17 / P0.18 / P0.19:
- We turn them on when “active” and off just before entering System OFF, so you can see when the system is awake.

Test sequence we would like you to try with fsm_test_min:

1. Flash fsm_test_min.
2. Wait ~10 seconds until it enters System OFF (LEDs turn off).
3. Change the level on P0.11 (press the button) to wake the device.
4. Observe:
- RESETREAS on the next boot (DOG vs OFF).
- Whether the device ever gets a watchdog reset ~20 s after the System OFF request instead of a clean OFF wake.

We attach the full fsm_test_min project (source + overlay + prj.conf) so you can build and run it as you prefer. Any guidance on why we see RESETREAS = DOG instead of OFF in this scenario would be very helpful.


fsm_test_min.rar

[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.