ESP8266 NONOS SDK - Light Sleep

[Thom]

Hello!

I started to play around using an ESP01. My goal is to keep the module in Light Sleep, and wake up to GPIO0 level changes. When the module is awake, it should still keep track of level changes, and report them through wifi.

I have a level change detector interrupt on my GPIO, working fine. I've got a buffer set up for wifi messages, when it gets empty, the wifi driver initiates a sleep sequence. I disable my GPIO IRQ, disconnect the wifi station, and set the opmode to NULL. Then, I try to set a wake up on GPIO0, setting the wake level to high, if the GPIO is currently LOW, and vice versa. I also have a wake up process, everything is set up as described in the API reference.

It works nicely, the system goes to sleep, and wakes as it should most of the time, but sometimes, once in about 5 trials, the system wakes up immediately after the do_sleep call, sometimes more than once, then goes to sleep indefinitely as it should (the wake up happens right after calling do_sleep, and the wake up cb is called). As I send a message immediately after wake with the gpio value, this behavior creates several false messages (and power consumption).

I tried everything that came to my mind to resolve the problem, tried clearing interrpts before going to sleep, disabling and re-enabling gpio_wakeup, disarming all os_timers, but nothing seems to help.

Did anyone have an issue like this? What could solve the problem?

[Thom]

Some additional info:
- Tried to run the disconnection and sleep sequence from a separate task instead of the tcp disconnection cb.
- Tried to remove all os_print function calls, and tried to shut os_printf down all together using system_os_set_print
- As I am using SNTP, I tried to turn it off / not start it at all
- Moved the GPIO interrupt and wake to GPIO2
- Removed the GPIO interrupt

None of the above solved the problem, the device still returned (sometimes several times) from forced light sleep instantly after calling do_sleep.

The only solution I've found now is to revert my SDK back to the 2.0.0 version, it seems the bug is not present there.