Strange behavior after go_to_sleep()
-
Errors like this one were reported a few times already, and while trying to help someone from this community, I found a reason: The problem is, that go_to_sleep() switches off the power of the xxPy boards, but the ESP32 continues to run, while Vin in dropping. For a combination of Pysense and LoPy4, it took about 16 ms to drop from 4.5V to 3V, and another 12-14 ms to further drop down to 2V, at which time the falling slope changed. I assume that then the ESP32 stopped. The first time frame should be still safe, but between 3V and 2V the behavior is definitely undefined. Screen shot below. I cure that by calling machine.deepsleep() immediately after go_to_sleep(). machine.deepsleep() stops the ESP32. But maybe that could be put in the driver.
-
@HenroRitchie If you have a single ESP32, machine.deepsleep() is sufficient. In combination with the Pycom expansion boards go_to_sleep() ensures proper deactivation of the respective sensors and set-up of the interrupt sources. It then switches off the power to ESP32. In summary, that results in a very low standby current - with the above side effect. Since the PIC on the expansion board also can control the EN (Reset) pin of the ESP32, it may pull that low before switching off the power. That may be a better solution than calling machine.deepsleep(), because it switches the ESP32 off immediately, and the PIC stays powered and therefore in a defined state during deepsleep.
-
@robert-hh Thank you for alerting me to this thread. I do agree this could be added to the driver. Why do you call both go_to_sleep() and machine.deepsleep()? Does machine.deepsleep() not cover all the bases?
