Wake from deep sleep works while debugging but not when running standalone

[andrew_alloy]

I am having a similar issue to the person in this post where the wake from deep sleep on an interrupt sometimes works and sometimes doesn't.  But for me, it's very consistent.

I enter sleep in two cases:

Case 1 works every time when the debugger is running and fails every time when running standalone.

Case 2 works every time without the debugger running.

Case 1: Start scanning, set a timer to timeout in 5 seconds, when that event happens, set an event.  In the event callback, go to deep sleep.

Case 2: Go to deep sleep in the disconnected call back function.

When it fails to wake up, it does not seem to fail to go to sleep as the next line of code is a call to printk which is never executed.  It just won't wake up.

Device tree entry:

	ints {
		compatible = "gpio-keys";
		interrupt0: interrupt_0 {
			gpios = <&gpio0 27 (GPIO_PULL_DOWN | GPIO_ACTIVE_HIGH)>;
			label = "Wakeup Interrupt";
		}; 		
 	};

GPIO configuration:

	nrf_gpio_cfg_input(DT_GPIO_PIN(DT_NODELABEL(interrupt0), gpios),
			   NRF_GPIO_PIN_PULLDOWN);
	nrf_gpio_cfg_sense_set(DT_GPIO_PIN(DT_NODELABEL(interrupt0), gpios),
			       NRF_GPIO_PIN_SENSE_HIGH);

Sleep code:

pm_power_state_force((struct pm_state_info){PM_STATE_SOFT_OFF, 0, 0});

I've tried it both with and without the power management config items in prj.conf:
CONFIG_PM=y
CONFIG_PM_DEVICE=y

Hardware: nRF52-DK

nRF Connect SDK version 1.8.0.

I just tried upgrading to nRF Connect SDK version 1.9.0 to see if things would be different and it won't go to sleep at all (after adding 0 in for the new cpu parameter of pm_power_state_force, of course).  I do see there are bugs filed against Zephyr a month ago reporting issues with this, but I'm not familiar enough the the SDK to know if it was using the problematic version of Zephyr or not.  the subsys/pm/pm.c file doesn't quite match the commit that fixed the issue, but my attempt to make a similar change didn't work.  So probably best to focus on this with SDK version 1.8.0 for now.

[Einar Thorsrud]

Hi,

The nRF is not able to enter system OFF mode while debugging, so in that case it does not actually happen. But without a debugger this should work, as it looks like you have correctly configured the wakeup pin. Could it be that in Case 1 (the failing case), you reconfigure the wakeup pin or similar, so that it is no longer configured as sense? If that is not it, perhaps you can see if you can reproduce this with a minimal sample on a DK so that I can test on my end?

[andrew_alloy]

I've tried calling the same pin configuration functions right before the call to pm_power_state_force just to be absolutely sure but it still fails when the debugger is not attached.

I also tried having it sleep from the main loop rather than an event callback but that didn't work either.

I see that the code executed is:

NRF_STATIC_INLINE void nrf_power_system_off(NRF_POWER_Type * p_reg)
{
    p_reg->SYSTEMOFF = POWER_SYSTEMOFF_SYSTEMOFF_Enter;
    __DSB();

    /* Solution for simulated System OFF in debug mode */
    while (true)
    {
        __WFE();
    }
}

Call stack: 

So in debug mode the SYSTEMOFF register being set to 1 doesn't do anything, and it executes __WFE() to simulate system off mode.  I can recover from that with my wakeup pin.  But in standalone operation it never comes back on.  Something is fishy but I can't think what it could be.

I also tried changing it to active low instead of active high but that didn't make a difference.

[Einar Thorsrud]

Hi Andrew,

It seems wakeup from system off works properly after cleaning up properly before entering system off (stopping BLE activity etc.), and that is anyway a good idea. I am not able to explain why that is needed though, but I have unfortunately not been able to digg properly into this yet.

Einar

[andrew_alloy]

Great.  I had tried to do that unsuccessfully but I was guessing what I should do.

Would you be able to share the cleanup code that worked for you?

[Einar Thorsrud]

It works for me if I take your example and call go_to_sleep() on the on the first line in go_to_sleep() (so line 56 in main.c).

[andrew_alloy]

Line 56 is inside go_to_sleep().  Calling it iteratively doesn't seem to make sense...I think you may have made a typo in your explanation?

[Einar Thorsrud]

Ah, yes, sorry. There is a copy-paste error. It should have been:

It works for me if I take your example and call bt_scan_stop() on the on the first line in go_to_sleep() (so line 56 in main.c).

[Mark Q]

Further clarification from Andrew:

If I place the bt_scan_stop() call after the printk() call, it doesn't work.  So it seems that there needs to be a delay after calling bt_scan_stop() before going to sleep if you want to be able to wake up.  That's a bit odd, but we can work around that.