Page 1 of 1

Missing the first rising edge when waking up

Posted: Sat Jun 12, 2021 8:10 am
by zhaozhaozhao
Hello,

I want to detect edge interrupts when the board is in deep sleep mode. I am using two light barriers to detect human motion direction. Both barriers output low when no object detected, and output high when something breaks the barrier. When a human walks pass two barriers, It is expected that the board will receive a series of rising/falling edge interrupts on two pins. I set the wake up source to "any high".

My problem is about the first rising edge interrupt. The following interrupts, since the board is already awake, are detected just as normal interrupt events. However, the first rising edge that wakes the board up is not detected. I think that is because the isr service must be installed after every wake up, the first rising edge has already passed away.

Is there any way to handle this, I do not want to miss any interrupt. Could you tell me if the wake-stub is suitable for this? Or should I assume the wakeup event as a rising edge event?

Best Regards
Zhao

Re: Missing the first rising edge when waking up

Posted: Wed Jun 16, 2021 11:14 pm
by rfleming
Just spit-balling here...

Since a deep sleep is effectively a restart of the esp (minus a handful of registers), this would mean once it wakes on the rising edge, the edge has already passed by the time you reinstall the ISR.
Wouldn't it be better to just test for a "high" on that IO at start? If you test for the HIGH + confirm the wakeup reason is from deep sleep. Then you should be able to start your application using this information. Reinstall your ISR and use it to grab all future edges?

Re: Missing the first rising edge when waking up

Posted: Thu Jun 17, 2021 4:52 am
by Victoria Nope
Optionally you can use the ULP coprocessor, which is designed just for the apps running when the main cores are deep sleeping.

Re: Missing the first rising edge when waking up

Posted: Mon Jun 21, 2021 8:22 pm
by zhaozhaozhao
Thank you. I am also using the same solution mentioned by rfleming, detecting pin level by waking up and treating a high pin level as rising edge event. Since it only takes a few milliseconds to wake up, this solution works for me. And I have also tried the ULP some time ago to poll from I2C, but for the pin wake-up I feel it is an overkill to use ULP.

I don't know whether Xtensa CPU have those interrupt flags stored in hardware registers and need to be cleared manually. If this is case then I can read the bit in registor to see if there was an rising/falling interrupt on that pin. But anyway I don't see any problem with the current solution so that is sufficient for me.

Re: Missing the first rising edge when waking up

Posted: Tue Jun 22, 2021 9:53 am
by Victoria Nope
To me waiting for the two GPIO rising edges, storing direction bit based on which one came first, waking up the main cores with the ULP and reading that bit from the wake up interrupt would be elegant, not overkill.

But I'm just an old assembler writer :D

Re: Missing the first rising edge when waking up

Posted: Thu Jun 24, 2021 8:45 pm
by zhaozhaozhao
Victoria Nope wrote:
Tue Jun 22, 2021 9:53 am
To me waiting for the two GPIO rising edges, storing direction bit based on which one came first, waking up the main cores with the ULP and reading that bit from the wake up interrupt would be elegant, not overkill.

But I'm just an old assembler writer :D
Hi Victor,

yeah, at last I have to turn to use ULP. Because waiting for the board to wake up is too slow. I set another pair of pins as RTC GPIO and connect them to the same signal source.

Do you know if it is possible to use the same pin as a diginal GPIO to attach isr service on, as well as a RTC pin so that it is still powered on during sleep mode? It seems that gpio_config() and rtc_gpio_init() will overwrite each other.

Best Regards
Zhao

Re: Missing the first rising edge when waking up

Posted: Fri Jun 25, 2021 8:45 pm
by Victoria Nope
zhaozhaozhao wrote:
Thu Jun 24, 2021 8:45 pm
Do you know if it is possible to use the same pin as a diginal GPIO to attach isr service on, as well as a RTC pin so that it is still powered on during sleep mode? It seems that gpio_config() and rtc_gpio_init() will overwrite each other.

I would say (never tried) that you can switch between pin's RTC and DIGITAL GPIO function right before you enter deep sleep or after you wake up the main chip.

But if you wanted to monitor those barriers constantly, you could use the ULP coprocessor exclusively for this task and to get notified in the main program hook up the RTC interrupt service. It's because the coprocessor's WAKE instruction either wakes up the main chip, or triggers RTC interrupt when the main chip is already awake.