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.

BQ40Z50: SMB dataline pulled low for depleted battery

Genius 17165 points
Part Number: BQ40Z50
Other Parts Discussed in Thread: BQ25730, BQ25710

Hi all

My customer is using the BQ40Z50 and they find that the SMB line is permanently pulled low as soon as the battery is judged to be depleted.

Looking at the datasheet they don't find any information as to how to change / control this.

On page 6 / figure 2 they find SMBCEN / SMBDEN that can generate a pull-down.

However they don't find further information as to how to control these signals.

Please comment and clarify.

Best regards

Ueli

  • Hello Ueli,

    Can you please explain the test conditions and what they are seeing? Are they using an EVM or their own board? Can you share the schematic? The gauge does not have pull-ups, this is an external requirement. If you tie the pull-ups to a supply that collapses when the battery is low communication will not be able to continue.

    Sincerely,

    Wyatt Keller

  • Hello Wyatt

    Thank you for the quick reply. I will have the customer answer your questions.

    Best regards

    Ueli

  • Hello Wyatt

    Thanks for picking up this question. I'm the customer that Ueli was mentioning.

    We see this behaviour on our own board.

    There are external pull-ups (10k) on both lines. Communication is working fine until in register bit FD (0x16.4) is indicating, that the battery is fully discharged. We have set that level to 10% of the full capacitance of the battery pack. The battery pack has 5Ah, so 10% is roughly 500mAh (4s2p configuration).

    Right after this bit was read, the communication on the SMB breaks down. The oscilloscope shows that SMBD is constantly pulled-down. We have really checked that it is the SMBD line only that is pulled down. Luckely, there are series resistors in the SMB lines, such that we can easily detach the pins. And if we do so, the other components sitting on the same bus can be accessed. The SMBC is not affected, which is expected because it is an input.

    There it currently no load but the MCU and some sensors. The 3.3V supply we generate from the battery voltage. The minimal load and the 500mAh remaining capacitance ensure, that the 3.3V remains stable even further. And we see that the communication to the MCU is still ok.

    I can share the scematics, but there is not really much to see that is relevant for this topic. There are two external pull-ups with 10k, and in total 4 slaves on the SMB, one of them being BQ40Z50 and another TI chip, BQ25710. The latter will be replaced by BQ25730 in the next release.

    Best Regards
    Reto

  • Reto,

    This is odd sounding. The gauge setting the FD bit has no relevance to the communication lines. Have you confirmed it is the gauge holding the line low? When you say you have series resistors so it is easy to detach, Are you physically removing them from the PCM?

    Thanks,

    Eric Vos

  • Hello Eric

    Sorry for the late reply. I somehow must have missed the notification.

    There are 4 slaves on the I2C bus. After having detected battery depeltion by the fuel gauge, communication to all the slaves broke down. We have phyiscally removed the series resistor in the data line and then the communication to the other components was ok.

    We have though of the following setup:
    1) Determine the voltage at which the fuel gauge flags depletion.
    2) Detach I2C data line from remaining of the system an pull it up locally, so close to the fuel gauge.
    3) Measure this line while discharging. So we can observe that at that particular voltage level, the line is going down.

    Unfortunatley, we cannot remove that series resistor and still read the state of the gauge.

    Best Regards,
    Reot

  • Reto,

    The effect is immediate once the FD flag gets set? And it is 100% reproducible? 

    Please share your srec file that I can program into one of my own boards to try and reproduce. The gauge does do some clock stretching, but in no instance should it hold the data line low for any amount of time. 

    Thanks,

    Eric Vos

  • Hello Vos

    Sorry for the late reply. While isolating the gauge from the rest of the system, we are facing some other issues, which are not related to the gauge but inhibit the further debugging.

    I'll keep you posted on the progress
    Best Regards
    Reto