Fix unintended power-on, battery shutdown, and charging recovery - #279
Open
TobiasRoeddiger wants to merge 3 commits into
Open
TobiasRoeddiger wants to merge 3 commits into
TobiasRoeddiger wants to merge 3 commits into
Conversation
|
Build output available: |
|
Build output available: |
|
Build output available: |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This fixes several ways the earable could keep consuming battery after being turned off, or stop charging without recovering. The changes target the v2.7 board with the VARTA CP1454 A4X cell.
What changed and why
Turning off on USB now stays in charging-only mode. Previously, button-off and automatic shutdown rebooted the device, and startup interpreted that reboot as a request to run the application again. The firmware now remembers the off request across reset and keeps audio, sensors and Bluetooth operation off while charging. This closes the “turned off, but running again” path.
Startup always initializes the LED mode. Previously, an uninitialized value could select the custom LED mode, whose initial color is black. That could hide later charging/full-charge indications even while the device was running. Startup now explicitly initializes the complete LED state.
Battery-only shutdown disconnects the system supply. Shutdown now requests the power chip's ship mode, stops audio and the network core, and falls back to processor System OFF if the ship command fails. Battery alerts no longer wake an intentionally off device. USB/button wake signals are armed only after cleanup, immediately before System OFF, so USB arriving during cleanup cannot trap shutdown in repeated interrupts.
Low-battery protection runs periodically, including after USB is unplugged. Previously, periodic charger work stopped on unplug, leaving battery shutdown dependent on gauge interrupts. Checks now run on a dedicated battery queue, with one place deciding whether charging is allowed. Normal operation stops at 3.25 V and needs 3.35 V to restart. On USB, low voltage stops application loads but allows charging-only recovery. Failed safety readings stop normal operation on battery and inhibit charging on USB.
Charger settings must actually take effect. Previously, failed writes were ignored; the chip could also acknowledge a voltage-setting write without applying it while the output was enabled. Startup now disables both output-enable sources before setting the peripheral supply to 3.3 V, checks communication errors, and reads settings back. Bus operations are serialized and respect the required delays. Unexpected charger resets are detected and repaired through charging-only startup. Reading status no longer accidentally undoes a charge inhibit.
Fuel-gauge setup cannot wait forever or use frozen measurements. Configuration entry/exit now have time limits, write failures propagate, and charging rejects measurements while configuration mode is active. Profile checks use design capacity instead of learned full-charge capacity, avoiding unnecessary reprogramming as the cell ages. Programming is deferred during depleted-cell recovery. RAM verification also compares only the requested bytes, avoiding an out-of-bounds comparison.
A charger safety-timer fault gets one controlled recovery. Previously, polling the fault did not clear it, so charging could remain stopped. Firmware now uses the charger's disable pin to recover once, only when battery readings and electrical conditions permit it. The hardware safety timer remains enabled. Retry/fault state survives reboots; a reboot after using the retry conservatively blocks charging until USB is disconnected, because the remaining timer budget is lost during startup.
Storage errors and fatal errors no longer leave the device stuck running. A full SD card can return a successful zero-byte write; shutdown previously retried that forever. It now reports the error and still closes the file so shutdown can continue. Fatal errors on this board reboot into the battery/charging path instead of remaining in the debug panic loop.
Battery settings and recovery tool
The v2.7 charger temperature input is a fixed resistor divider, not a battery thermistor. Firmware continues to disable that input, now with verification. The recovery tool does the same and requires valid gauge temperature and safety flags before proceeding. Documentation now explains charging faults without promising that reconnecting USB will always recover the device.
Verification and remaining limits
1bfc940.The final minimized image has not been flashed. Overnight retention and recovery from an actual 2.5 V cell still need hardware validation. The complete “fully charged → dark → deeply discharged while USB stayed powered” incident has not been reproduced, so this PR fixes the demonstrated failure paths without claiming that the entire historical cause is proven.