BQ78350-R1A: SMBus read bug in BQ78350-r1a with BQ76940 at 32768mV

What does the gauge report for each individual cell voltage when you run this test?

Hi Dominik,

Here's the full log from BQ studio.

Initially my charger manufacturer saw this issue on a complete pack, and I re-created it with a test jig that lets me ramp "pack voltage" with 0.1% resistors dividers as the "cells". That lets me get right to 32768 (0x8000) on the voltage and get the weirdness. It's pretty obvious when I hit it.

2023-03-03_voltage_tests.csv

The cell voltages look fine, an example is:

voltage reports as 17345, while the cell voltages are:

Here's the chip info from BQ studio

Regards,

-Adrian

I'm very sorry for the delay in my response.

The gauge just sums up the cell voltages and multiplies this with a scaling factor. I don't see a way for the result to get corrupted as you report. I understand that you can reproduce this with both the EV2400 and bit-banged smbus but I'm wondering if there's a problem with SDA voltage level integrity. Can you try stronger pull-ups?

I logged a voltage reading transaction between BQ studio and the battery. This is a "wrong" reading of voltage.

I noticed the EV2400 uses SMBus CRC, so I would have expected BQ Studio to choke if the SDA data wasn't correct.

I've been swamped this week, but I have a plan to very slowly discharge a pack past 32.768V while logging cell and pack voltage.Then I will see if the data when the cells sum to 32768mV is glitchy.

Thanks for the communications plot. I'll assign this back to Shirish who is the expert on bqStudio.

Hello Adrian,

The data in the waveform is Data low=0xD6 Data high=0x83. This translates to 33750mV. What value did bqStudio report at this point?

HI Shirish,

BQ Studio is correctly reporting 33750mV.

If you look at the CSV file in the second comment, you can see the individual cell voltages and what BQ Studio is reporting for overall voltage.

As far as I can see the "bad" voltages are correctly coming over the SMBus with correct CRC from the gauge. We have seen this with both BQ studio and bit-banged PIC comms.

This is why I think the issue is in the gauge itself. It looks like there is a discontinuity in the reported voltage. If the cell voltages add up to 32768 (0x8000) the gauge will corrupt the voltage data.

I'm hoping to set up a test this weekend to slowly discharge the pack past 32768mV and log via BQ Studio. Plotting that data should reveal any discontinuity.

Hi Shirish,

I logged some data over the weekend and have pretty good data showing the issue:

First, here is the raw CSV from BQ Studio.

/cfs-file/__key/communityserver-discussions-components-files/196/2023_2D00_03_2D00_26_5F00_slow_5F00_dchg_5F00_past32768.csv

This is recorded from a real pack with real cells, and is the 3rd chip showing this issue (every chip I have tried shows the issue). The issue shows up with and without CRC, and shows up with and without the EV2400.

This is with EV2400 using CRC. No CRC errors are recorded from BQ Studio, the ".log.err" file has one entry for a NACK on a temperature read. No other errors in thousands of reads.

2023-03-26 15:29:38,TS1 Temp,772,No acknowledge from device.

I discharged the pack slowly at -200mA past 32768mV, then gently applied a charge +100mA to hover around 32768 to get lots of corrupt data.

Here are some images plotted from that data,

I plotted the sum of the reported cell voltage in BLACK, and the reported cell voltage in RED. After tens of thousands of readings (remember BQ Studio is polling the full data set, not just voltages) the only bad data is on Voltage and is when the cells will sum to 32768mV. CRC's are correct, but voltage data is trash.

I am very convinced the BQ firmware has a bug in the code that generates the reported voltage from the individual cell data.

Zooming the Y axis you can more clearly see the issue:

Hello Adrian,

Thank you for the log. Since you are able to reproduce with bqStudio on multiple EVMs, we should be able to try it and get the same results.

I am in the process of trying to get an EVM to test it

Thanks Shirish, I can privately share my SREC golden file and schematic to show how I configured the AFE if you need either.

Hello Adrian,

Thanks. I am able to reproduce some bad readings with a similar setup.

Thanks Shirish,

I'm somewhat relieved it's not my setup... there's so many places to go wrong between the hardware and firmware I'm usually convinced I've done something wrong!

But at the same time hopefully this hasn't created a huge amount of work for you.

Hello Adrian,

I have entered a ticket for this and waiting for a schedule.

Hello Adrian,

I think you will need to use the workaround of summing up the cell voltages on the host to get pack voltage to avoid this issue. I think you may have already implemented that by now :-)

Shrish,

My end customer doesn't use the voltage to make any decisions, however my charger manufacturer was using the voltage as a double-check for their charging algorithm. They have added error checking to their algorithm to look at the difference between successive voltage readings.

They can't just go and read the individual cell voltages because there is a second source for the battery pack that doesn't use a Texas Instruments chip. The individual cell voltages are not part of the SMBus standard, and are not part of the second source battery. Otherwise we would have to get into coding SMBus routines for each vendor's chips.

Part of the beauty of an SMBus battery pack is that you basically get good A-D data "for free" from the pack. A charger or end device can use the voltage and current instead of putting in their own A-D chips. But if the data is corrupt, it defeats the purpose of SMBus.

So we're nominally "OK" for now, however I would really like to see this come out as an Errata for the chip. Little bugs like this take forever to find, and eat up development time and money.