LoPy unable to recover from full battery discharge when powered from solar panel/charger

[agotsis]

Dear community,

I am experiencing an issue with my LoPy4/Expansion Board 3.1:

First a few things about my setup: I have a LoPy4/Expansion Board 3.1 powered through a solar charger circuit (in particular the one in https://www.adafruit.com/product/390).
In the battery output I have connected a LiPo whereas in the load output a 5V USB Buck-Boost Verter (the one in https://www.adafruit.com/product/2190), the latter feeding theUSB input of the LoPy4/Expansion Board 3.1.
The setups operates smoothly (reads out a PIN output every 10 minutes and then goes to deep sleep).

However in case the battery drops at low levels (in case of a few days lack of sunshine), for example at 2-3V, hence it is fully discharged, when the battery starts charging again (at bright sunshine conditions), the board fails to restart and remains deactivated. If I manually remove the Verter and reconnect-it to the board (thus forcing hard reset) then the board reboots and starts operating smoothly. By the way I have also configured the sw watchdog. To my understanding after full discharge the LoPy enters an "irrecoverable" state from which it cannot exit without hard reset.

Had anyone similar experiences with solar charger circuits and Pycom's modules? I have reproduced the same behavior for 4-5 times, using LoPy4, LoPy1 and FiPy, so it seems to be common for all modules.

Cheers,

Antonis

[Martinnn]

@agotsis I woudln't expect your setup to work without an external supervisor. Add a supervisor to generate a reset below 3...? V. While you're at it, add a battery protection to prevent discharge below 2.5 V.

[agotsis]

@Martinnn That's what i was also thinking about, to use an external watchdog. But i was hopping that i could avoid it.
Thanks!

[Martinnn]

@agotsis Primarily you need a voltage supervisor. But as robert also just observed, you should use a hardware watchdog as well (that needs to be periodically retriggered and otherwise generates a hardware reset), so I'd recommend using a device that has both functions.

As a side note, this "brownout" condition (supply dropping to 1-2 V - not zero!) and rising again can put many microcontrollers in a hung-up state which can't even be recovered by a hardware reset (!), but needs a power cycle (down to 0 V) to restart the microcontroller. This is pretty nasty, fortunately I have not observed this yet with the ESP32 (nor have I tested it).