nrf_pwr_mgmt bug

[Benjamin]

I think I've found a bug in the power management that occurs only when a softdevice and the debug interface are active. In SDK v17.0.2, nrf_pwr_mgmt.c lines 417-429:

            ret_code_t ret_code = sd_power_system_off();    // Expected ret_code is NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN
            ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED));
            UNUSED_VARIABLE(ret_code);
#ifdef DEBUG
            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();
            }
#endif

The ASSERT statement fails to catch the case where sd_power_system_off returns NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN with a debugger connected.

[Amanda Hsieh]

Hi Benjamin, 

Do you add SOFTDEVICE_PRESENT into the preprocessor Definitions as the figure? 

The code should work when the SOFTDEVICE_PRESENT is added into the preprocessor Definitions. 

#ifdef SOFTDEVICE_PRESENT
        if (nrf_sdh_is_enabled())
        {
            ret_code_t ret_code = sd_power_system_off();
            ASSERT((ret_code == NRF_SUCCESS) || (ret_code == NRF_ERROR_SOFTDEVICE_NOT_ENABLED));
            UNUSED_VARIABLE(ret_code);
#ifdef DEBUG
            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();

            }
#endif
        }
#endif // SOFTDEVICE_PRESENT

-Amanda H.

[Benjamin]

Yes, without SOFTDEVICE_PRESENT set none of this code would be executed.

The primary issue is that, per nrf_soc.h, the syscall sd_power_system_off() returns NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN, but only when there's a debugger attached (because of https://infocenter.nordicsemi.com/topic/ps_nrf52840/power.html?cp=4_0_0_4_2_2_0#unique_142049681). sd_power_system_off() will never return NRF_SUCCESS.

Swapping NRF_SUCCESS for NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN eliminates the erroneous assert error.

[Amanda Hsieh]

Hi Benjamin, 

The chip will enter Emulated System OFF mode if it is in debug interface mode, and in that case, immediately return from the sd_power_system_off() call instead of entering sleep. So you need to make sure the debug interface is disabled to properly test System OFF mode on your device. See this post and this post. 

-Amanda H.

[Benjamin]

In the case where a debug interface is enabled (along with the softdevice), the syscall sd_power_system_off() returns NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN, not NRF_SUCCESS, which is what the ASSERT statement checks for.

[Amanda Hsieh]

That works as the Emulated System OFF mode documentation describes. If the device is in debug interface mode, System OFF will be emulated to secure that all required resources needed for debugging are available during System OFF.

In debug mode the debugger will keep the chip stay awake surpassing the command to put the chip to system off. Hence the code caused an assert. 

Please try to test without running the debugger (use logging to debug) you should see the chip working normally. 

-Amanda H.

[Benjamin]

Perhaps you're misunderstanding the problem: the code throws an ASSERT error when no error is warranted.

The ASSERT statement is assuming the expected result from sd_power_system_off() is NRF_SUCCESS, but that syscall NEVER returns NRF_SUCCESS. However, sd_power_system_off() DOES return NRF_ERROR_SOC_POWER_OFF_SHOULD_NOT_RETURN if and only if the debug module is connected.

With the current bug, it's impossible to debug waking from system off because the erroneous ASSERT prevents the chip from entering the 'simulated' power system off that consists of an infinite loop around __WFE.

[Amanda Hsieh]

Hi Benjamin, 

Sorry for the delay. I agree with that. 

I have reported to the internal. Thanks for the feedback. 

-Amanda H.