Electronics Design AUMAX17048 reporting 0% SoC at power-on — reading jumps to ~70% after several seconds
Asked by stale_biscuit_03 ·
Adding a MAX17048 to an ESP32 project — single 18650 cell, standard SOT-23 breakout board, I2C on pins 21/22. Address 0x36, confirmed with a scanner. Cell is sitting at 3.82V on the multimeter so it's definitely not flat.
Problem: the SOC register (0x04) reads 0x0000 on every boot. Stays at 0% no matter what.
I found the QuickStart command in the datasheet — write 0x4000 to the MODE register (0x06) — so I put that in my init. If I wait after calling it, the reading eventually jumps up to somewhere between 60 and 75%. But the timing is all over the place. Sometimes it updates after 2 seconds. Sometimes I'm waiting 8–10 seconds. Once or twice it just stayed at 0% until I reset the board.
Current init sequence:
- I2C init
- Read VCELL (0x02) — reads ~3.82V, looks right
- Write QuickStart to MODE register
- delay(500)
- Read SOC register
Is 500ms not long enough? Is there a register I should be polling instead of a fixed delay? VCELL reads correctly straight away, which makes me think the IC is alive — but SOC is clearly not ready at that point.
2 Replies
The timing is the issue, and there's a more reliable approach than a fixed delay.
The MAX17048 uses a ModelGauge algorithm that needs a settled open-circuit voltage to establish initial SoC. When the chip first powers on, it sets a Reset Indicator (RI) flag in the STATUS register (0x1A) to signal that no valid SoC has been computed yet. If you read the SOC register while that flag is set, you get 0x0000 — not because the battery is empty, but because the model hasn't run. That 0% is a placeholder, not a measurement.
A more reliable init sequence
- Power on. Wait for the IC to complete its first ADC conversion — the datasheet specifies the conversion timing; it's typically in the hundreds of milliseconds range, so check the current datasheet revision for the exact figure.
- Read the STATUS register (0x1A) and check the RI flag. While it's set, the IC is still in reset state and SOC is not valid.
- Issue QuickStart (your 0x4000 write to MODE). This forces the IC to immediately resample OCV and recalculate SoC rather than waiting for the next scheduled conversion window.
- Wait for another full conversion cycle to complete after QuickStart before reading SOC. Again, the datasheet gives the precise timing — but it's in the same hundreds-of-milliseconds range.
- Clear the RI flag by writing it back as 0 in the STATUS register once you're satisfied the reading is stable.
Your 500ms delay is the problem: you're calling QuickStart, then waiting 500ms — but that wait needs to cover the time after QuickStart triggers a new conversion, not before. Depending on where you are in the IC's internal timing cycle when QuickStart fires, your 500ms might land in the middle of a conversion rather than after it completes. Polling the STATUS register until RI clears is cleaner and timing-agnostic.
Why the reading jumps to 60–75%
The jump from 0% to mid-range is the gauge catching up once it has a valid OCV sample. The 0% was a placeholder; once the ModelGauge algorithm runs against the actual cell voltage, it looks up the OCV on the discharge curve and gives you the real estimate. The jump is correct behaviour — the problem was the 0% before it.
Cell model
While you're in there: the CONFIG register (0x0C) high byte is RCOMP, a compensation coefficient calibrated to a specific reference cell. If your 18650 chemistry doesn't match the default, your SoC readings may be consistently off by several percent after the startup issue is resolved. The fuel gauge IC overview covers cell model quality and how to use Maxim's EZ tool to generate a custom model for your specific cell — worth reading if the accuracy matters to you once the init timing is fixed.
The jump to 60–75% is also consistent with OCV not having settled from a recent charge. After a Li-ion cell finishes charging — even after the charger terminates cleanly — the terminal voltage sits above the true equilibrium OCV for a while. Surface charge bleeds off over time, and until it does, any voltage-based estimate is optimistic. The MAX17048 samples that elevated voltage, maps it to the OCV-to-SoC curve, and reports a reading that's higher than the true SoC. If you power cycle again 30 minutes later without charging, the initial reading will come in lower and more accurate.
The Li-ion charging article explains the CV tail and why terminal voltage diverges from equilibrium OCV after a charge completes — same root cause.
Quick test: discharge the cell lightly (run your board for 10 minutes), let it sit for half an hour with nothing connected, then check the initial SOC reading after the RI flag clears. If it's noticeably different from the post-charge reading, OCV settling is part of your bring-up noise.
One other thing while you're debugging bring-up: the ALRT pin on the MAX17048 is open-drain active-low. If you've routed it to an ESP32 GPIO and haven't enabled the MCU's internal pull-up or added an external one, the pin floats and you'll get spurious interrupts or undefined GPIO state during init. Not related to the SOC reading issue, but it catches people at exactly this stage.
Related Discussions
TP4056 CHRG LED stays on for hours — is the charge ever going to terminate?
Built a small Li-ion charger using one of those cheap blue TP4056 modules from AliExpress. Battery is a single-cell 2000 mAh flat LiPo (nomi
LDO overheating and shutting down on a 2S Li-ion powered board
Got a board running off a 2S Li-ion pack (7.4V nominal, up to 8.4V fresh off the charger) feeding an LDO down to 3.3V for the MCU and a coup