Other Parts Discussed in Thread: MSP430F5359, BQSTUDIO, EV2400
We build a board that contains a BQ27510-G3 Battery Gauge (accessed by an MSP430F5359 microprocessor).
For this board, we have designed a “Board Test” program that executes on the three microprocessors on the module and exercises essentially all of the critical module functionality. As part of this, it does some simple operations with the Battery Gauge proving out basic I²C functionality, the competence and correct connection of the Current Shunt Resistor, etc.
In the past, we've always been able to run this Board Test before the Battery Gauge chips have been programmed. Because we use a 0.02Ω Current Shunt Resistor rather than the Gauge's expected default of 0.01Ω, we wrote our test to be tolerant of current readings that are twice as large as the board's electrical design would imply; no problem there; we've probably run a hundred of these boards through this test with no failures attributable to the Battery Gauge portion of the testing.
But we just received a batch of boards with Battery Gauge date code “051C”. Many of these boards failed intermittently failed our Board Test claiming that the INST_CUR (Instantaneous Current) reading from the Battery Gauge was too low. Whereas we would have expected readings (considering the “wrong” shunt resistor) of about 60-70 mA, the gauges would intermittently report much lower readings ranging down to just 5mA. By comparison, the AVG_CUR (Average Current) reading was always pretty much the nominal expected value of twice the real average current flow.
When we programmed these Battery Gauges with our usual Data Flash programming, the intermittent problem went away. This surprised us because we weren't aware of any aspect of the programming that would affect the way that the current measurements worked that would have produced these intermittent, seemingly time-dependent effects.
We used BQStudio to analyze both the Data Flash and Instruction Flash memories of these new gauges and couldn't see any significant difference between much older gauges (e.g., date codes “66ZH” and “99TD”) and these newer gauges. The contents of the Instruction Flash memory areas looks identical; the contents of the Data Flash memory areas looks to only have differences in the Cell Profile regions and the “CC Offset” value.
(Assuming that we've correctly proven that the Battery Gauge firmware is the same,) Has anything changed in the Battery Gauge silicon that would explain this? Do you have any hints for us as to what's going on? Are there subtleties in how the current measurement is done? (See my note below.)
We could modify our test procedure so that we always program the Battery Gauge before testing but we'd rather not do that if we could avoid it.
Atlant
-=-=-=-=-=-
Just for reference, SLUUA97, the “bq27510-G3 System-Side Impedance Track
Fuel Gauge With Integrated LDO Technical Reference Manual” describes Instantaneous Current thusly:
2.18 InstantaneousCurrent( ): 0x22 and 0x23
This read-only function returns a signed integer value that is the instantaneous current flow through the
sense resistor. The conversion time is 125 ms. It is updated every second. Units are mA.
It sounds like the conversion is too slow to see any effects that might be caused by, for example, our use of a switch-mode voltage regulator to step down the LiIon supply voltage to the 2.5V utilization voltage but we'd be open to suggestions as to where to look for things that might now be tricking the Battery Gauge's current measurements.
