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

[nrbrook]

This would be fine, but it isn't what happens. The sd_power_system_off is not returning, it is rebooting immediately.

Here is the (slightly modified) code from nrf_pwr_mgmt.c

ret_code_t ret_code = sd_power_system_off();
//            ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED) || (ret_code == NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN));
            UNUSED_VARIABLE(ret_code);
#ifdef DEBUG
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wmissing-noreturn"
            while (true)
            {
                /* Since the CPU is kept on in an emulated System OFF mode, it is recommended
                 * to add an infinite loop directly after entering System OFF, to prevent
                 * the CPU from executing code that normally should not be executed. */
                __WFE();

            }

I can place a breakpoint on sd_power_system_off and it will be hit, but stepping over it results immediately in a reboot. I want that function to either power off or return (which will be handled by the loop), not reboot.

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