Wakeup from system ON using DETECT

[Pascal Künzi]

Hi there

I am currently trying to wakeup from system On mode using the DETECT signal and Port Event.

According to the product specification:

Trying to put the system to System OFF while DETECT is high will cause a wakeup from System OFF reset.

This is the opposite behaviour when entering system ON.

Putting the system into System ON IDLE while DETECT is high will not cause DETECT to wake the system
up again. Make sure to clear all DETECT sources before entering sleep.

My question is, how can I ensure that I don't end locking up the nRF52832. In my case the nRF52832 is supposed to wakeup from a GPIO sensing on a low level.

When the low level occurs right before entering sd_app_evt_wait() the nRF will not wake up since DETECT is already triggered.

How is it meant to use DETECT in such a scenario? I cannot clear the DETECT signal sourced by the GPIO since it is driven from another device.

To minimize the timespan where this lockup could happen, I read the GPIO and then enter sd_app_evt_wait() only if the GPIO level is still high. Yet there is still the possibility for the GPIO level to go low between reading the GPIO and finally entering sd_app_evt_wait().

// Skip sleep when GPIO is already low
if (nrf_gpio_pin_read(GPIO)) {
    sd_stat = sd_app_evt_wait();
}
else {
   // Stay awake
}

Thank you in advance!

Regards,

Pascal

[haakonsh]

You need a watchdog timer.

If you enter SystemON, Idle and can't exit, the WTD will reset the device.
If you enter SystemOFF and immediately wake up, you will reset the device. 

As long as you clear the DETECT signal before entering sleep you will not experience a large number of resets. 

[Pascal Künzi]

Hi Haakonsh

In system OFF the behaviour of resetting when the DETECT is triggered, also before entering system OFF, makes sense and works the way we expect it to.

For the system ON, I guess it would work if you use a WDT when you know the maximum amount of time the device will be sleeping for. In my case the device will be asleep for an arbitrary amount of time and depends on an externally driven signal. So this wouldn't work.

If the level to sense on already applies at the GPIO, how would enabling the sensing right before entering system ON prevent the DETECT signal from triggering. Once I enable sensing doesn't the DETECT signal trigger right away? So by the time system ON is entered, the DETECT is already triggered.

Is the DETECT signal delayed? Or are there other ways to clear the DETECT signal apart from disabling and reenabling the sensing.

Thank you for the fast reply and help.

Regards,

Pascal

[haakonsh]

The DETECT signal is normally not latched, so you do not need to clear the event. 

I think
"If the level to sense on already applies at the GPIO, how would enabling the sensing right before entering system ON prevent the DETECT signal from triggering. Once I enable sensing doesn't the DETECT signal trigger right away? So by the time system ON is entered, the DETECT is already triggered."
is only valid if you're using latched detect mode for the GPIOs. 

From the GPIO chapter of the prod spec:
"The LDETECT signal will be set high when one or more bits in the LATCH register are '1'. The LDETECT signal will be set low when all bits in the LATCH register are successfully cleared to '0'."

[Pascal Künzi]

haakonsh said:

The DETECT signal is normally not latched, so you do not need to clear the event. 

Thats what I thought. It lasts as long as the level to sense on applies at the GPIO.

haakonsh said:

I think
"If the level to sense on already applies at the GPIO, how would enabling the sensing right before entering system ON prevent the DETECT signal from triggering. Once I enable sensing doesn't the DETECT signal trigger right away? So by the time system ON is entered, the DETECT is already triggered."
is only valid if you're using latched detect mode for the GPIOs. 

I can see in the register that the DETECTMODE is set to the default 0. So I am not using the latched mode. But I would say that this applies for both the LDETECT and the regular DETECT. The only difference with LDETECT is, that when the LATCH register is cleared, another rising edge will be generated where as with DETECT it stays triggered.

[haakonsh]

Well, I suggest you don't use a WDT, but rather an RTC that will periodically wake up the device from SystemON, read the GPIO pin state and go back to sleep if it's not in it's "active" state. 

That way you're assured that you can wake up from SystemON from a pin.  

You can also guarantee to wake up from SystemOFF if you trigger the reset pin. 


Another perhaps easier alternative is to use the LPCOMP — Low power comparator as the wakeup source. It can be configured to trigger on a logical high input, ~0.7xVDD, or whatever you want for that matter. It can run in both SystemON and SystemOFF, and the datasheet says it only uses 0.5µA. 

[Pascal Künzi]

Hi haakonsh

Sorry for the delayed response. I had vacation time.

My problem could be solved with the following approach.

By setting the SEVONPEND flag, it is possible to wake up from disabled interrupts. So by having the GPIOTE IRQ disabled, the port event triggers the GPIOTE IRQ pending flag once the correct sensing level is applied on the GPIO. Hence, when the above occurs right before entering sd_app_evt_wait() the nRF52 will return immediately. Already in sd_app_evt_wait() the nRF52 will wake up from the disbaled IRQ as well.

Thank you for your ideas and help.

Regards,

Pascal

[Shockel]

Could you post code, please ? I believe this race condition is quite serious and a well documented solution would be very helpful !