sd_power_system_off resets?

[nrbrook]

I'm using nrf_pwr_mgmt_shutdown to shut down the system to wake on interrupt. 17.0.2 SDK and 7.2.0 softdevice. When I step through the code with a debugger, it gets to sd_power_system_off and then when I attempt to step over it reboots. The bootloader starts and launches the app. Is this because a debugger is connected? When the softdevice is not enabled, and nrf_power_system_off is called instead, it does shut down correctly.

[Jørgen Holmefjord]

Hi,

Yes, when the debugger is connected, the chip will enter Emulated System OFF mode. The code will return from the function, and the debugger can continue executing code. Normally the return-code from the softdevice functions are passed to APP_ERROR_CHECK, which will put your application in the error handler in case of non-zero return code. sd_power_system_off() will return NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN if you are in debug mode and Emulated system OFF is entered.

If you want to continue debugging in emulated system off mode, remove the APP_ERROR_CHECK(), and replace it with a while(1)-loop, to prevent application from executing unexpected code.

Best regards,
Jørgen

[Jørgen Holmefjord]

Are you able to set and hit a breakpoint after the call to sd_power_system_off? Stepping through the code when the softdevice is enabled will usually cause the softdevice to assert, as the internal timing requirements are violated.

[nrbrook]

No, any breakpoint after sd_power_system_off is not hit (with no breakpoint set on sd_power_system_off). The reboot also happens without the debugger connected.

[Jørgen Holmefjord]

The only thing I can think of then is that the chip enters System OFF, but it is waked up by some of the wakeup sources. Can you check the value of the RESETREAS register after the reset? Note that this may be cleared by the bootloader if that is present, so you may have to modify the bootloader to not clear it (components\libraries\bootloader\nrf_bootloader.c:247 in SDK 17.0.2), or read it out from the bootloader.

[nrbrook]

From the bootloader:

Reset reason: 0x00000001

Which indicates reset by the reset pin.

This pin is configured by defining CONFIG_GPIO_AS_PINRESET and is otherwise disconnected on the board. I thought by default this was configured with internal pull up, but checking the pin config register it doesn't seem to be. However, if I manually configure as an input with internal pull up, the same thing happens. I checked the voltage of pin 21 (nRF52832) and it is constant 3v when the reset occurs.

I replaced sd_power_system_off with nrf_power_system_off so I can test if it is the softdevice, and the same issue occurs, indicating it isn't the softdevice specifically. That points to some difference in state between the two code paths (when softdevice is enabled and when it isn't) that could be affecting this, but the pin configuration for pin 21 is the same when the reset issue occurs and when it doesn't. What other factors could be triggering a pinreset reset?

[Jørgen Holmefjord]

Can you check the value of the PSELRESET[x] registers? Could you also try to pull the reset pin high externally, to remove any possible error sources?

I can't think of anything else that would cause a pin reset. Did you check that the RESETREAS register is cleared (write 1 to set bits to clear) before entering System OFF ?

[nrbrook]

I think the reset reason is actually 0x0010000 (not sure why that flag wasn't set before, but after clearing flags before shutdown that is what I get) which indicates "Reset due to wake up from System OFF mode when wakeup is triggered from DETECT signal from GPIO". My GPIO config is toggle interrupt on a pin with internal pull down. Externally this pin is otherwise disconnected when the shutdown occurs, and remains at 0v.