Repository navigation
Power: PaperMono: do not touch the charger when it is in LED mode - #394
Merged
Merged
Conversation
The IP2316 latches its mode when VIN is applied: I2C mode only if SCL and SDA are both High at that moment, otherwise LED mode until VIN is removed. On PaperMono the lines are only pulled High while the level-shifter gate (IOE1 GPIO11) is open, so plugging USB in with the gate closed, which is always the case while powered off, gives LED mode. In LED mode the charger drives LED1/LED2 (= SCL/SDA) at about 500 Hz. getChargeState() and setBatteryCharge() opened the gate and polled 0x75 up to 64 times on that disturbed bus, which stalled the board until the power key was pressed; writes in that state can also land corrupted. The gate is now opened with the IOE1 output byte saved first, and the bus is checked with plain GPIO reads (own outputs disabled) for 4.5 ms before any I2C traffic; a watch with a long gap between reads is repeated, and a bus that could not be watched is an io_error. If a line goes Low, the charger is in LED mode: the gate is closed again between the charger pulses and the whole byte is confirmed by reading it back (up to 20 tries). A gate that cannot be confirmed closed is remembered with the byte to restore, and both APIs retry closing it before any other bus access (io_error / false until it succeeds). LED mode is remembered, only on a clean judgement with VIN present, until the PM1 reports no VIN; both getChargeState() and setBatteryCharge() read the power source for this. In LED mode getChargeState() returns undetermined and setBatteryCharge() returns false. The sequence assumes no other task uses the internal bus meanwhile, like the rest of the power functions. Limits: VIN removed and reapplied between two calls is not seen, so LED mode stays remembered; only these two APIs retry an unconfirmed close.
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
2 participants
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.
On PaperMono,
M5.Power.getChargeState()/isCharging()/setBatteryCharge()can stall the board (screen frozen, USB port gone, only the power key recovers it) when the USB charger is in LED mode.Why it happens
0x75up to 64 times on that disturbed internal bus, which stalls the board. Writes in that state can also land corrupted (an IOE1 output byte written as0x30read back as0x1A).What this changes
getChargeState()returnsundeterminedandsetBatteryCharge()returnsfalse.Tested on PaperMono
getChargeState()x100undeterminedx100, IOE1 output byte unchangedsetBatteryCharge(true)false, byte unchangednot_charginggetChargeState()x20chargingx20, as beforeLimits (also in the code): VIN removed and reapplied between two calls is not seen, so LED mode stays remembered; only these two APIs retry an unconfirmed close.