BQ24725A: BQ24725ARG pulls SCL to low level for more than 40ms

Hi Peng,

This is unusual. To help us better understand the issue, can you please answer the following questions?

1) Is the AM3358 able to configure the BQ24725A's registers, or is SMBus communication not working at all?

2) What do you mean by "sparsely"? Does this mean that the 43 ms SCL low event only occurs some of the time?

3) Can you please provide your schematic and indicate where SCL and SDA are being probed?

Best regards,

Angelo

Hi, Angelo,

Please answers to your questions.

1). AM3358 is able to access BQ24725A before and after this 40ms SCL low Interval.  SMbus is working normally beyond that interval.

2). "sparsely" means this happens randomly with very low occurrence rate---happen but very seldom.

3) The measurement point is the I2C signals at the CPU side (circled in red, CPU side schematic is not attached). there is one 3.3V-2.5V I2C level shifter between CPU and BS24725A and battery.

Hi, Angelo,

If the I2C master does not issue BQ24725A address with WRITE bit set and set the register address to read back first,  the master just issues BQ24725A address with READ bit set to preform read operation directly, what 16-bit value will BQ24725A return ？is it 0x01FF?

Thanks,

Peng

Hi Peng,

Thanks for the info. At POR, the BQ24725A registers should read back the values shown in Table 2 below:

Since you mentioned that the 40 ms SCL low event only occurs rarely, it's possible that this behavior is noise related. Can you please capture a zoomed-in SMBus communication waveform so we can make sure the rise times and fall times are fast/crisp enough, as shown in the SMBus timing characteristics below?

I see that the schematic includes a PCA9306 voltage translator, so when you capture waveforms, please probe SCL1/SDA1 instead of SCL2/SDA2. We want to examine the SDA/SCL lines on the BQ24725A side just in case the PCA9306 is affecting the communication signal.

Best regards,

Angelo

Hi, Angelo,

We measured the important timing parameters at the charger side (2.5V level), all meets the datasheet. There is no signal integrity issue . please see the attached captured waveform.

If the charger is too busy, will it stretch the SCL signals for longer than 35ms and reset its SCL logic module? We also suspect 0x01FF is a default value for registers other than those listed in the table 2.

Peng,

Hi Peng,

Thanks for sending the waveform and the detailed SMBus timing measurements. I apologize for the delayed response.

The SMBus spec allows slave devices (such as the BQ24725A) to perform clock stretching. This indicates to the host that the slave device is busy, which allows slower slave devices to communicate with faster master devices. However, SCL cannot be held low for too long due to the SMBus release timeout. If SCL is held low for >25 ms, this is interpreted as a timeout condition. Devices that have detected this SMBus release timeout must reset their communication within 10 ms. The 35 ms maximum SMBus release timeout value comes from combining the stretch limit for a slave (25 ms) and a master (10 ms).

In my testing with the BQ24725A EVM, I have not been able to reproduce the behavior that you describe with the registers PORing with 0x01FF. The registers' POR values match Table 2, as expected.

In your testing, do all of the registers POR with 0x01FF, or does this only happen with some of the registers? Is this behavior consistent?

Also, are you able to reproduce this behavior on a BQ24725A EVM, or does this only occur on your own board? If it only occurs on your own board, then is it possible to remove the PCA9306 voltage translator and see if the behavior is the same? The battery charger team and the TRX team have discussed this case with the FAE over email, and it's difficult to rule out that the voltage translator circuit might have some impact.

Best regards,

Angelo