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.

BQ27510-G3: Can you please confirm that the I2C Interface on this Battery Gauge uses "Open Drain" drivers?

Part Number: BQ27510-G3
Other Parts Discussed in Thread: EV2400, MSP430F5359

Folks:

I'm pretty sure I know the answer to this question but our Electrical Engineer
has asked me to ask it so here I am.

This post over in the MSP430 forum is discussing a problem we're having
with an I²C Bus that exists entirely between our MSP4305359 and our
BQ27510-G3 Battery Gauge EXCEPT that an ST Microelectronics ST2378E
bidirectional level translator provides access for us to connect a TI EV2400
Battery Gauge programming pod.

The fault we see is a cross-conduction problem on the I²C SDA line where the
MSP430 (the Master) is trying to drive SDA low (to send the 0x16 "ROM Mode"
address but someone else is actively trying to pull it high. We're trying to figure
out where the fault may lie and the ST2378E is the obvious suspect (the
MSP430 operates its I²C Bus using "open-Drain" or "open-drain-equivalent"
drivers and the BQ27510-G3 almost certainly does as well, leaving only the
ST2378E to be actively pulling up SDA) but we want to make sure that our
assumption about the Battery Gauge I/O pin topology is correct. So:

Are we correct in assuming that the BQ27510-G3 only uses open-drain drivers
on its I²C Bus SCL and SDA signals?

Atlant

  • Hello Atlant,

    That's correct, it would not have a means to pull the line high.

    Sincerely,

    Wyatt Keller

  • Hi Atlant,

    Yes these are open drain, refer to the pin function section of d/s.

    Best,

  • Wyatt, Nick:

    Thanks for your responses!

    We've now got pretty good proof that our "cross-conduction" problem is caused by a
    small glitch from the I²C logic of the MSP430F5359 causing the ST2378E bidirectional
    level translator to react badly. Among other evidence, over the weekend, with the
    ST2378E disabled, I ran more than 10,000 cases of programming the Battery Gauge
    without any failures. In other words, the Battery Gauge (which we never really suspected)
    is entirely off the hook. As further evidence, we've also got 'scope shots. Below, I'll show
    you those 'scope shots just for your own future reference if this ever turns up again.

    Here's the MSP430 driving I²C SDA in the absence of the ST2378E chip:

    The Yellow trace is an analog representation of SDA and the Blue trace is an
    analog representation of SCL. Note the little glitch in SDA as the MSP430
    switches from emitting the "Start condition" to emitting the "Address Bit 0"
    (with a value of "0" because this is the MSP430 addressing the Battery
    Gauge at I²C address 0x16).

    Here's what it looks like when the ST2378E is enabled:

    You can see that the '2378 takes that brief little MSP430 glitch, activates its active
    pull-up logic, and drives hard to pull SDA high while the MSP drives hard to pull the
    line low. The result is that the (Yellow) SDA line stays mid-voltage until the MSP430
    finally reaches a "1" bit in the address at which point the active driving logic in the
    '2378 goes back to sleep. (The Green trace is the 3.3 V open-circuited side of the
    ST2378E.)

    We'll solve this problem by re-engineering the '2378 circuit so that the level translator
    is entirely disabled when the EV2400 pod isn't connected.

    If you have no further feedback or questions, we can mark this as "Resolved".

    And thanks again for your help!

    Atlant

  • Hello Atlant,

    Glad you were able to get it resolved, and thanks for posting an explanation for the issue!

    Sincerely,

    Wyatt Keller