Electronics Design AUBQ27220 SoC wildly inaccurate after config — does it really need a full charge/discharge cycle to 'learn' the cell?
Asked by stale_biscuit_03 ·
Bringing up a BQ27220 on a new product board — single-cell Li-ion, 2000 mAh pack, 0.01Ω sense resistor per the reference design. Programmed the gauge configuration through BQ Studio with the EV2300, used the .gg.csv the cell manufacturer's datasheet pointed me to (closest match for chemistry and capacity — not an exact part match, the actual cell isn't in TI's library).
After programming, SoC is all over the place. Sat at 44% for a while at rest, jumped to 61% after ten minutes of light discharge, then back down to 50% a bit later with no obvious reason. RemainingCapacity and FullChargeCapacity registers both look plausible individually but don't track consistently with each other over time.
Is the config just wrong, or is there some kind of "burn-in" process this chip needs before it settles down? I've seen forum posts about fuel gauges needing to "learn" the cell but nothing specific to the BQ27220's actual requirements.
3 Replies
It needs to learn, and what you're describing is exactly what an un-learned Impedance Track gauge looks like — so don't assume the config is wrong yet.
The BQ27220 runs TI's Impedance Track (specifically the GPCCHEM variant on this part), and the .gg.csv you loaded only gives it a starting point — a generic or closest-match chemistry model, not your actual cell's characterised capacity or impedance. Until the gauge completes a genuine learning cycle against your real pack, it's interpolating from that generic model, and any two SoC readings taken at different points in a partial cycle can legitimately disagree with each other the way you're seeing.
What the learning cycle actually requires (check your specific BQ27220 technical reference manual revision for exact thresholds, these vary slightly by firmware version):
- A valid discharge, from a high state of charge down past a low-voltage threshold, at a current above the gauge's minimum qualifying current — the gauge won't log a usable data point from a near-zero trickle discharge, only from current high enough to give it a real dV/dQ signal.
- A relaxation period at rest after that discharge, letting the cell voltage settle to true open-circuit voltage before the next charge.
- A full charge to the taper/termination condition your charger IC actually uses, so the gauge sees a genuine 100% reference point.
Only after that sequence does the gauge update QMax (its estimate of true full capacity) and the Ra (resistance) table from generic defaults to values characterised against your actual pack — and SoC reporting stabilises. Before that, treat every reading as provisional. The fuel gauge IC overview covers the Impedance Track model in more depth if you want the underlying mechanism.
One thing to check separately while your unit is going through its first cycle: confirm your actual application's charge/discharge profile ever exceeds the qualifying current threshold. If this is a low-power sensor node that trickle-charges and trickle-discharges at a very low average current, it may never generate a qualifying data point in normal operation — in which case you need a deliberate bench cycle at a higher current specifically to force the learn, rather than expecting it to happen passively in the field.
Before you burn a cycle chasing the learning-cycle explanation, rule out the other classic BQ27220 bring-up trap: sealed/unsealed access mode. The gauge ships (or re-enters, depending on your config script) SEALED after certain operations, and SEALED mode silently ignores or restricts writes to data-flash parameters that FULL ACCESS mode allows. If any part of your config script ran after the device re-sealed itself — some flows re-seal automatically after a reset — you could have a partially-applied configuration that looks like a learning-cycle symptom but is actually "some of my config never took effect."
Read back the data flash parameters you configured (not just the runtime SoC registers) and confirm they match what you intended to write, using the correct unseal key sequence in BQ Studio if needed to get read access. If those parameters are correct, charge_controller_charlie's explanation is almost certainly your answer and you just need to run the cycle. If any of them reverted to generic defaults, you have a sealing/write-order bug to fix first — running a learning cycle against a wrong config just teaches the gauge the wrong thing accurately.
Also worth setting expectations for whoever's running production test on this board: budget the learning cycle into your test plan, don't just budget it into bring-up. A pack that ships un-learned reports plausible-looking but uncharacterised SoC for its entire first cycle in the field, which is a bad first-use experience if the first thing a customer sees is the fuel gauge swinging around.
Some manufacturers run a forced learning cycle on a test fixture before the unit ships — a controlled discharge/charge specifically to get QMax and Ra characterised against the actual production cell before the product leaves the building, rather than relying on the end user's usage pattern to eventually trigger it. Worth deciding early whether that's a production step you need, especially if — like you said — your normal operating profile might not reliably cross the qualifying current threshold on its own.
Related Discussions
MAX17048 reporting 0% SoC at power-on — reading jumps to ~70% after several seconds
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
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