BQ27421-G1: Occasional readings where StateOfCharge() > 100%

Hello Stephen,

I am inclined more in 2, I have never seen output value of SOC over 100%. This might be  a communication issue. 

Are you using EV2400 along with bqStudio or your own MCU?

Regards,
Jose Couso

Hi Jose,

Thanks.  If possible, I'd love it if you could review the IC design to see if it's possible to get a value greater than 100 to confirm that #1 is impossible.

We are using our own MCU.

Hi Stephen,

Sure, you can share your IC design. This is most likely a host issue.

As I mentioned before, I have never seen a gauge report more than 100% in SOC. This has to be on how you are reading from the gauge.

I'd recommend looking at the I2C timing stated in datasheet, or using our bqStudio and comparing the result, and possible comparing the timing diagrams.

When you read from address 0x1C, what do you see? It returns a hex value in reverse byte format. For example, right now the cell is 92% and I read 5C 00 from 0x1C. Then I swap the bytes, so 00 5C. Convert this value to decimal, I get 92%

Regards,
Jose Couso

Hi Jose,

I think you misunderstood.  I asked if you could review the IC design, meaning the design of the BQ27421-G1, to see if it is possible to get a value greater than 100.  I understand you have never seen it, but having never seen something doesn't mean it is impossible that it can occur.  It would be helpful to know if there is digital logic in the chip that limits the maximum value, or there is a calculation that could result in output > 100, if for instance there was a transient voltage or current that was unexpected.  Is it possible to request the BQ27421-G1 designers to check this?

We understand the hex value is in reverse byte format.  Almost all of the time, we get the correct value, it is only occasionally that we get the wrong one.  We haven't been able to reproduce this on the bench, only in the field, where we don't have physical access to the device.  To give you an idea of the frequency, see the plot below.  Those spikes up are > 100% (sorry the y axis labels are cutoff here).  This also means we can't use the bqStudio to reproduce this.

Jose and I verified that the gauge will not allow values higher than 100% (it's limited to 0%...100%). If your host uC reads values >100%, it's likely that the data transfer between the gauge and the host uC was corrupted. If possible, please use an I2C analyzer to check if there's a problem on the bus. Note that the gauge uses clock stretching so the host uC must be able to handle this.

Thanks for confirming that.

The bus looks fine to me.  Would you be able to take a second look to see if anything looks problematic for the bq27421?  In particular the timing restrictions between transactions. 

The attached files show a typical capture (not a problematic one, like I said the problematic ones are hard to reproduce) of the transactions we perform every time we read battery percentage (StateOfCharge()).  The scope shot is just as a high level summary, you'll probably need to plot the CSV to see the SCL and SDA timing.  I also attached an I2C analyzer decoded version so you can easily see the timing between the I2C writes and reads.

scope_7.csvscope_8.csv

It's difficult to analyze this without data that shows the problem. It's not "normal" behavior of the gauge (this gauge is used in very large volumes in many applications and I haven't seen this particular problem) so this is likely related to an incompatibility between the I2C host and the gauge. The most likely culprit is clock stretching, which the gauge requires in case it needs to spin up its HFO when the host uC reads from the gauge when the gauge is in a low power state.

For a test, I recommend disabling any low power modes of the gauge and restricting it to normal mode. This should prevent clock stretching and if this "fixes" (works around) the glitches, then it's a strong indicator that your host trips up when the gauge indeed clock stretches.