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]

Thank you.  That makes sense it can't really sleep while debugging.  But it seems to do a good job of pretending, as it does reboot when I "wake" it.  So I suppose it's going through the motions but not really shutting down the power, understandably.

The wakeup pin is only configured by those lines of code in one place at startup and never changed again.

I'm struggling to think what could be different when running "for real".

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

I see you are running this on a DK. Can you upload your (preferably minimal failing) project here along with instructions on how to run it to reproduce the issue?

[andrew_alloy]

Hi,

I stripped down a version to post here.

Be sure to use SDK version 1.8.0.  Open the project from the central folder.

Run it and wait for 5 seconds after you see the message "Scanning successfully started" on the UART console.

After 5 seconds you should see:

Scan timer expired

I: e: sleep_event Sleep Event

Going to system off...

That's when you need to connect P0.27 (top left on dev kit) to 3.3V to wake it up.

With the debugger connected you will see it boot up again. Without the debugger connected, you will not.

4034.example.zip

[Einar Thorsrud]

Hi,

Thanks for the sample. I see the same in my end. I will look more into it and get back to you.