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.

bq24725 not accepting smbus commands from battery

Other Parts Discussed in Thread: BQ24725

Our bq24725evm seems to work perfectly except for one very big problem...  It isn't actually accepting the ChargeCurrent and ChargeVoltage commands from our battery (Inspired Energy ND2054).

The battery is looks like it sending well formed messages (though they have PEC, which is probably wrong).   Everything looks fine up through the 1nd data byte, at which point the bq24725 doesn't ack.  The transaction looks like:
S 00010010 A 00010100 A 11101110 N 00000010 A 11011001 N P
in other words... 
Start 0x09+R Ack 0x14 Ack 0xEE Nack 0x02 Ack 0x9D Nack Stop

Oddly, from an attached system, I can read the appropriate values from the battery and issue ChargeCurrent and ChargeVoltage to the charger.  It will start charging and keep going until the battery sends out the commands, at which point the controller sets both values to 0 and stops charging.

My guess would have been that the PEC byte the battery seems to insist on sending is causing the problem... but using the attached system to send the same message doesn't have trigger strange Nack issue.  The only other difference I see is that the battery's messages are at about 75kHz instead of 100kHz.

Anyway, I've banged my head against this long enough and just don't see what could be causing this problem.  It really looks like it should be working...  Any clues would be most appreciated.

PS: If I ever figure out how to do screen captures on the oscope, I'll post the comparison of the successful transaction from the system->charger and the failing battery->charger.  That Nack and the slightly slower rate are the only really obvious differences though.

PPS: Of course, I'll also contact the battery supplier with this... but the Nack is the charger, not the battery.

  • An SMbus signal rising time issue could cause the problem between battery and charger. 

    Every switching charger has ground noise between switching FET ground and the control IC ground during the charge. The charger IC gets SMbus commands from SCL and SDA pins. But, the ground noise is added to those pins. The switching ground noise is added to the SCL or SDA voltage ramp.

    If the rising time is much longer (slow) than SMBus spec, the SMbus signal could cross the logic level threshold two times. For example, the SCL signal rises up higher than logic high threshold, the charger IC counts it as one clock. But, the ground noise brings it down lower than logic low threshold. When ground noise is gone and SCL goes back, the charger IC counts another clock signal. So, the SMbus communication could be hurt. 

    The solution is: speed up the SCL clock rising time to meet SMbus spec.

    1. Reduce the pull -up resistor. 2. Add a very small cap (doesn't change rising time too much) to reduce the SCL and SDA noise. So, the cap groud should be very close to IC ground. 

  • I have used lower pull-ups.  No change.

    However, I was incorrectly reading the SMBUS exchange.  I misinterpreted a clock-stretching as a NACK... 
    So it now seems most likely that the problem is the battery using PEC (error checking byte) and the charger not accepting that.

    The battery should not be using PEC with a device that doesn't support it, but the charger should probably be designed in such a way that it is tolerant of a host using PEC even if it doesn't actually check it.

    I'll see what the battery supplier has to say. 

  • The bq24725 doesn't support PEC. So, the PEC may cause the issue. Yes, please ask the battery maker disable it to verfy the SMbus communication between battery and charger or make the host IC talk to the charger only.