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.

BQ24707: SMBUS command unstable

Part Number: BQ24707

Hi Team,

I design a battery charger with BQ24707 solution for 4S2P battery pack. 

The charger is unstable during the charging. 

Thus I used EV2300 and TI charging tool for debug. 

I found SMBUS waveform is different between charging and stop charging (Inhibit charger). 

My question is why SMBUS waveform is different at charging and stop charging?

Stop charging 

We got the same SMBUS waveform every time when press charger current command.

 

Charging enable

Some time we got correct command but some time we got incorrect command when press charger current command.

      

   

Best regards,

Jason

  • Hi Jason,

    What do you mean the charger is unstable during charging? Can you show IBAT, PHASE, SRN and ACN waveform?

    Please me know what what your battery current, input voltage, and battery voltage are as well.

    For SMBus, you may find more coupling from the power stage switching to the communication lines when it is charging.

    Thanks,

    Peng

  • Hi Peng,

    Charger unstable means sometimes charging and sometimes doesn't (SMBUS lockout keep low).

    About charger design target as below:

    1. Maximum charging : 3A

    2. Input voltage : 19V

    3. Battery voltage : 14.8V (4S2P)

    I know communication line coupling has a little bit of switching noise, does it cause the write command to send different bytes (1, 2 and 4 bytes)?

    I tried to capture the waveform as you mention please see below. 

    960 mA charging current:

    Ch1: ACN to GND, Ch2: SRN to GND, Ch3: phase to GND, CH4: Ibat

    3000mA charging current:

    Ch1: ACN to GND, Ch2: SRN to GND, Ch3: phase to GND, CH4: Ibat

  • Hi Jason,

    The charging waveform looks good to me.

    The amount of bytes you see on the communication line is purely a firmware design decision. The charger is a slave so it is not capable of sending any byte signals on the communication line. The switching noise, however, could cause the charger to not acknowledge a certain transaction or the MCU could misinterpret the switching noise as something else on the line (other master trying to take over the line, MCU thinks the charger is not acknowledging, etc.) so it does something weird.

    At the moment, I would recommend going that route and checking communication integrity between the MCU and the charger. I would recommend checking SDA and SCL bit more closely. You want to start with logic analyzer and see if there are obvious errors before moving on to a scope to see if it is noise related.

    Thanks,

    Peng