Low battery shutdown and wake strategies.   - Page 1
Forum section: electronics / projects

author: viper
author_rank: Regular Contributor
timestamp: September 25, 2025, 06:03:33 pm
content: I will try not to go too deep. low power battery device with Li batt and primarily PV charge support. Will be using a charger IC with charge parameters and authority given to an ESP32. IE, the ESP will see batt temp and dictate charge parameters. Part of design is at critical low power (batt damage), system is designed to fully power down. Not sleep, but off, to stop all batt drains, even if small, unless I can find a strategy that pulls next to nothing in terms of power.The issue is recovery strategies once a charge source is provided again. I've been through things like a comparator circuit with FET to trickle batt to a safe state before allowing MCU to wake, thus talking to the charger IC and doing proper charging. However, I am now questioning my sanity.The batt is a 2-series so critical low is 5V, so still enough to technically run the MCU. Would it be more sane to just detect that a charge source is present, allow the MCU to come up, and carry on? One caveat is I have to reject charging below 0C regardless. This is why the complexity is mounting on a low batt trickle circuit because I still have to look at a batt temp to make a decision.

author: jwet
author_rank: Frequent Contributor
timestamp: September 26, 2025, 03:45:28 pm
content: I've built a lot of remote camera gear for biologists that have these problems and helped a lot of Maxim customers with similar problems as an FAE. There are mechanisms in batteries that cause them to self discharge, you don't need absolute zero current draw- you can draw a few uA (same order as self discharge currents). TI and Maxim make lots of flea power cmos comparators, etc that do the job. You need high impedance voltage dividers 22M resistors, etc to keep sense currents down. I've made "zero" power circuits but they generally require a reset to get going again. High side FET's, PMOS usually or even mini latching relays are zero power off. You can have a coin cell in your system that can wake the micro once in a while in power fail mode. I have a lot of systems that run a real time clock on a coin cell that have alarm out to try to wake the uP every hour or so in this coma mode. You can also use a flea powered comparator to generate a wake. Don't overthink it.

author: viper
author_rank: Regular Contributor
timestamp: September 26, 2025, 05:39:45 pm
content: Quote from: jwet on September 26, 2025, 03:45:28 pmI appreciate the reply! I'm working on it. I had to ditch my selected MPS charger IC because in looking at so many, I realized it didn't have I2C. Now hovering the BQ25672 and one nice feature is I can put the chip in shutdown from the MCU, and it's designed to wake with a charge input. In shutdown, it's less than 1 uA. At even 10uA, I think I can build a strategy that shuts the device down well above a fully drained battery, giving months of time to recover without issue. I'm probably good with that. I would guess I can exploit the wake strategy of the charger to decide when to wake the MCU. It appears I can work a strategy with the MCU in deep sleep rather than 'off' down to 7uA, so I think I can work with that.However, there is a bit of concern with that charger. I'm still trying to learn if all register data is volatile memory, in which it reverts to default charge settings, which would damage our battery. I'm trying to consider something like an MCU failure. I'm surely not the only one to run into that potential question/concern.

author: jwet
author_rank: Frequent Contributor
timestamp: September 26, 2025, 06:40:43 pm
content: Data integrity of hardware like this is important, this is how you make exploding cell phones, etc. I would do a checksum of the registers in your write routine driver for it and stash it somewhere. On wake up, etc, run a checksum and if you fail, provide fail safe defaults from ROM, etc. Use the simplest charger you can and never trust it.Good luck.