BQ27426: Parameters reset and incorrect measurements for the faulty pack

#1: This indicates that the gauge was reset. Possible causes:

* reset command.
* power cycle.
* voltage on LDO dropped too low (below UVLO-). This should not happen on the EVM but can happen if a different HW design uses an inadequate capacitor on VDD.
* too many commands issued on the I2C bus during an active discharge or charge.

This can be checked with ITPOR (if this is 1, the gauge was reset) and WDRESET (if this is 1, then the watchdog timer reset was triggered most likely due to excessive commands on the I2C).

#2: SOH isn't based on FCC but on FCC for a specific load (SOH Load I) and 25 deg.C. If you discharge with a higher load or a different temperature, FCC can be significantly different, while SOH stays the same. FCC can even be zero, if the predicted capacity for a specific load is zero but FCC for SOH can still be close to Design Capacity for SOH Load I at 25deg.C/

Thanks for the comment.

> Too many commands issued on the I2C bus during an active discharge or charge.

I'm evaluating the devkit with EV2400 and bqstudio, but I presume it may be an issue in the production design. Do you have any recommendations for avoiding that in the production, maybe some appnote?

Regarding case 2. Thank you for the clarification, but my point was that I was throwing a bad battery to the gauge, and after chg-dsg cycle, the gauge couldn't detect its bad. The SOH feature is my project's primary point of interest, so evaluating that the gauge can tell the difference is vital. Can you advise the conditions in which the gauge will update the SOH value so that I can adjust my testing method?

The TI datasheet limits standard commands during regular use to no more than 2 per second. The gauge is intended to report SOC. It runs on a 1s cycle so it's pointless reading SOC often. Sometimes customers want to use it as an instrumentation device (which it really isn't) and poll current, voltage and temperature more often than once a second. As the gauge runs on a 1s cycle, none of these parameters will update more often than once a second.

The gauge will update SOH once it measured Qmax and cell resistance. Qmax requires a change in DOD of at least 0.35 (which corresponds to 35% of configured Qmax) with temperatures between 10deg.C and 40deg.C and relaxed voltage outside the flat zone of the OCV. Cell resistance updates require a Qmax update and discharge that lasts long enough for depth of discharge to change by at least 0.1 with a load exceeding C/10.

Ok, no more questions regarding the polling period. Thanks.

Regarding the SOH - in my case, it seems like the battery is too damaged to operate adequately with the gauge. I'll replace it with a less damaged one and repeat the test, but it's unclear if it will perform the same in a "natural" aging case.

For now, it seems like a heavily damaged battery can produce incorrect SOH. Suppose the battery's capacity is less than 35% of the design capacity, and there is a power loss event (which is possible with the heavily damaged ones). In that case, I'll program the golden image again, and the gauge will never reach the SOH update event, producing an incorrect SOH value.

If I've got a correct idea about this case, is there some workaround to deal with heavily damaged batteries?

Yes, if the gauge loses power before it measured cell resistance and chemical capacity, then the gauge will not update SOH. One possible workaround would be for the host controller to monitor cell voltage and if it drops too low turn off as many components as possible (ideally go into a standby state) to let the cell relax so that the gauge can measure chemical capacity.

Not sure that your proposal can be applied in my case, but thanks for the hint.

There is one question without an answer regarding the golden image.

I'm working on the image taken for operating conditions (discharge at 250 mA, charge at 600 mA, minimum system voltage 3500 mV) and wondering if I should re-take it as per pack's datasheet (C/10 currents, cut-off at 3000 mV)? At first, I assumed that the golden image should be taken for actual operating conditions, but after reading the SLUA903 I'm not so sure. :)