• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 62 subscribers
  • Views 200 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

BQ76920: occasional bad ADC read on VC5

Dimitri Butvinik
Prodigy 50 points
Part Number: BQ76920

Hi,

we have a BMS design based on TI reference for BQ76920. It's a 4S battery, so we tie VC3 and VC4, skipping VC4 data ( which reads zero as expected ), only using VC1, VC2, VC3, VC5

MCU software reads VCx registers in pairs, as atomic value, returning 16bit word value. Data is read every 250ms when CC_READY bit is set, indicating fresh ADC data is available.

99% of the boards work fine, no issues, but there have been 2 boards so far which exhibit occasional bad ADC read on VC5, see sample below.

Sample only shows data from VC5, since VC1-VC3 are always good. Each line has 3 sequential samples, so about 750ms per line.

Board is just sitting idle, connected to a nominally charged battery, no charge or load, but both FETs are on. There are no transients, actual voltage on VC5 is very steady.

Any idea what could be causing VC5 value to randomly jump up by a certain number, approx. 3175 ? Seems to always happen in short bursts with normal periods in between.

8713,8712,8712
8713,8712,8712
8713,8712,8712
8712,8712,8713
8712,8712,8713
8712,8713,8714
8712,8713,8714
8713,8714,8715
8713,8714,8715
8714,8715,11888
8714,8715,11888
8715,11888,8714
8715,11888,8714
8714,8714,8714
8714,8714,8714
8714,8714,8714
8714,8714,8714
8714,8714,8716
8714,8714,8716
8716,8716,8717
8716,8716,8717
8716,8717,8716
8716,8717,8716
8717,8716,8716
8717,8716,8716
8716,8716,8716
8716,8716,8716
8716,8716,8717
8716,8716,8717
8716,8717,8717
8716,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,8717
8717,8717,11896
8717,8717,11896
8717,8717,8718
8717,8717,8718
8717,8718,8718
8717,8718,8718
8718,8718,8716
8718,8718,8716
8716,8716,8716
8716,8716,8716
8716,8716,8716
8716,8716,8716
8716,8716,8718
8716,8716,8718
8716,8716,8716
8716,8716,8716
8716,8716,11893
8716,8716,11893
8716,11893,8717
8716,11893,8717
8717,8717,8717
8717,8717,8717
8717,8717,8716
8717,8717,8716
8717,8716,8718
8717,8716,8718
8716,8716,8716
8716,8716,8716
8716,8716,8715
8716,8716,8715
8716,8715,8713
8716,8715,8713
8715,8713,8714
8715,8713,8714
8713,8714,8717
8713,8714,8717
8714,8717,8714
8714,8717,8714
8717,8716,8716
8717,8716,8716
8716,8716,8715
8716,8716,8715
8716,8715,8716
8716,8715,8716
8716,8716,8716
8716,8716,8716
8716,8716,8715
8716,8716,8715
8716,8715,11891
8716,8715,11891
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8715
8715,8715,8713
8715,8715,8713
8715,8715,8715
8715,8715,8715
8715,8715,11893
8715,8715,11893
8715,11893,8715
8715,11893,8715
8715,8715,8716
8715,8715,8716
8715,8716,8715

  • 0
    TI__Guru 54715 points

    Hi Dimitri,

    From the description the implementation sounds correct.  The common problem with jumping data is when voltages are read in 2 separate byte transactions near a byte boundary with a jump from 00 to FF, but that can jump in either direction and does not match your data values. 

    Another variation can occur when a diode is used from VC5 to BAT and the BAT is pulled down.  This will typically load the cell voltage to cause it to read low, your data is that it reads high.  Temperature is read every 2 seconds and will cause a slight load on the BAT pin voltage. When temperature affects a reading it normally is one reading and is gone until the next sample.

    The EVM shares the power filter with BAT and REGSRC, it reduces a component but causes variation of the BAT supply based on load.

    You might check the solder to see if anything seems incorrect related to the cells or power pins.  Inspect the signals with a scope to see if there is a periodic variation in VC4, VC5, BAT, REGSRC, or CAP1 voltage. Check the I2C clock edges to see if there is variation or if the rising edges look different from good boards.  If there are other things on the bus look for bus collisions although data collisions normally make the values read low.  Check that the bus addressing is correct on the errant data. It is certainly unexpected as your other systems show.   You might try swapping the part with a good board to see if the issue follows the part.

    Please let us know what you find, this seems very odd.

  • 0 in reply to WM5295
    Prodigy 50 points

    Thanks for your quick and detailed response. Your response made me look closer at our BOM and I found that Rf value into BAT pin was 10k instead of recommended 100 Ohm. REGSRC pin is routed separately from BAT, so it's not affected and its not tied to BAT. After I changed Rf on affected board to 100 Ohm, the issue was resolved.

    This brings an obvious question, why are 99% of boards with Rf=10k are not affected? I would have spotted the problem much earlier if the issue was more common.

    Also, after many 100s of boards were produced and shipped, we need to asses the risk of failures in the field. So far only 2 boards were spotted which passed all QC at production, but started exhibiting the issue later on. What could possibly trigger the issue at a later time, not immediately after manufacturing?

    What else could be affected by this mistake, other than bad ADC read on VC5?

    We don't actually use BAT value from ADC, we just sum up values from VC1-VC5 to get the pack voltage.

    Thanks

  • 0 in reply to Dimitri Butvinik
    TI__Guru 54715 points

    Hi Dimitri,

    Glad you found a fix.  From your description I would expect that some operation pulls down the BAT pin from extra current and if it aligns with the VC5 sample there may be a common mode issue giving a wrong ADC value.  Since the internal operation of the part is asynchronous with the MCU operation that may be the reason for the variation.  The TS1 sample will draw current from the BAT pin if an external thermistor is used.  If the thermisor is hot it will draw more current and the BAT pin would pull down more.  The pattern above though does not look like 2 second intervals of the TS1 sample.  You might look at a system with the 10k Rf to correlate a droop in the battery with TS1, I2C or other activity.  I2C buffers use the REGOUT supply sourced from REGSRC, but internal register activity will use current from REG1 sourced from BAT.   The BAT pin current in the data sheet is an average and can vary part to part.

    You might see if an extra dip in the BAT pin aligns with register reads and the TS1 sample (if thermistor is used). With a large R a noticeable RC response might be expected.

    If the dip pulls below the VC4 level the measurement of the next lower cell could be affected. If the dip pulls low enough to cause a drop in CAP1 the operation of the part could be affected. If the voltage reading is high for multiple sequential readings which meet the OV delay, the part could trip an unexpected OV fault.  I don't know how to assist with risk analysis, we certainly suggest operating the part within the recommended conditions.

    While you are not using the BAT battery voltage register, the part sums the individual voltages and divides by 4 to accommodate the requires data space for all members of the family. So the battery register would include the  higher value for the BQ76920's cell 5 as well as any residual value in its cell 4 which your system would not likely include.