• State TI Thinks Resolved
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 288 views
  • Users 0 members are here
Support feedback
Options
Options
Related

400kHz I2C quirks: SDA glitches, lower SCL frequency, excessive clock stretching

Vasily Shmatalyuk
Prodigy 150 points
Part Number: BQ76972

Tool/software:

Greetings,

I'm using BQ76972 for a 4S smart battery design, with the STM32H7 host MCU communicating with the battery monitor over I2C bus configured for 400kHz fast mode. I observed a few peculiar I2C communication features while analyzing the bus traffic, and would like to request your guidance on which of these are to be expected. Ultimately, I would like to validate my hardware design. A few notes on the latter:

- Host MCU I2C peripheral is configured to 400kHz master mode, clock stretching enabled

- Host MCU communicates with the battery monitor over a pair of LTC4331 differential extenders, with the total bus spanning multiple PCBs. Notably, the link rate on both the local and remote LTC4331 extenders are configured to 500kHz. See the bus visualized below:
                                 [MCU] <-I2C 400k, 2k2 pullups-> [local LTC4331] <-twisted differential pair-> [remote LTC4331] <-I2C 400k, 2k7 pullups-> [BQ76972]
All oscilliscope/logic analyzer captures attached below were taken on the segment in bold.

(1) SDA glitches

While the communication appears to be working correctly, my scope/logic analyzer are showing unusual "glitches" on the SDA line. These glitches are very short pulses that occur between the SCL clock pulses, specifically when the SCL line is low. SDA signal appears to be stable during the rising edge of SCL and these glitches appear to not occur when SCL is high.

Question: are the glitches expected and harmless?

(2) Lower than expected clock frequency

I consistently measured the SCL frequency to be ~355kHz, which is lower than the expected 400kHz. The datasheet doesn't clearly specify the expected frequency tolerance. As mentioned above, the differential I2C link is configured to 500kHz, while host MCU to 400kHz, suggesting they are not the bottleneck.

Question: is it expected that the actual BQ76972 SCL frequency is 355kHz when the device is configured in 400kHz I2C fast mode? If not, would you suspect the lower frequency to be caused by the host/diff I2C link?

 

(3) Excessive clock stretching

I am observing significant clock stretching when communicating with BQ76972 over I2C at 400kHz, which is substantially impacting my bus throughput. As shown in the attached logic analyzer capture, the device holds the SCL line low between bytes for periods that are often longer than the time it takes to transmit an entire byte, effectively doubling the transmission time.

Question: Is this aggressive clock stretching considered normal operating behavior for the BQ76972, or could it indicate an issue with my setup?

Thank you in advance for your time and support.

Kind regards,
Vasily

  • 0
    Prodigy 150 points

    Friendly ping on my questions since I haven't received a response yet.

  • 0
    TI__Intellectual 1350 points

    Hello Vasily,

    Apologies for the delayed response.

    1. These SDA glitches are not typically expected, but it is not uncommon at the same time. This could be seen due to a few reasons. One could be if you are not using the proper external pull-up resistors (which in your case is fine). Another could simply be the measurement errors of the scope you are using. Finally, some people may see this at the end of a cycle when the bus is being released.

    This should not cause any communication issues as it only occurs when the CLK is low so I would not worry about it.

    2. This drop in frequency is not expected as well. This may tie into your question below with the aggressive clock stretching which could cause this decrease in frequency. I have made a suggestion below which could improve this as well.

    3. The clock stretching time can be long, but this does seem a little aggressive. I have attached a reference for you below which will allow you to reduce the clock stretching. You can configure this in the device.

    Regards,

    Rohin Nair

  • 0 in reply to Rohin Nair
    Prodigy 150 points

    Hello Rohin,

    Thanks a lot for getting back to me. Could you please re-upload your attachment? It doesn't render for me.

    Kind regards,

    Vasily

  • 0 in reply to Vasily Shmatalyuk
    TI__Intellectual 1350 points

    Hello Vasily,

    Apologies. I have attached it again below. If this does not work, you can also view this in Section 13.3.2.8 of the TRM.

    Regards,

    Rohin Nair

  • 0 in reply to Rohin Nair
    Prodigy 150 points

    Hello Rohin,

    I forgot to mention in my original message, I've already configured this setting to the maximum value of 255 for the comms timings reported above. Would you have any other suggestions for further investigation?

    Kind regards,
    Vasily

  • 0 in reply to Vasily Shmatalyuk
    TI__Expert 5715 points

    Hello Rohin,

    A friendly ping also from my side.

    Best regards,

    Daniel Waleniak

  • 0 in reply to Daniel Waleniak
    TI__Intellectual 1350 points

    Hello,

    Unfortunately, besides the suggestion mentioned above, we do not have any other way to reduce the clock stretching on our device.

    Regards,

    Rohin Nair

  • 0 in reply to Rohin Nair
    Prodigy 150 points

    Hello Rohin,

    Could you please crystallize your conclusion about the points 2 and 3 I reported above? You mentioned that both the 1) SCL frequency and 2) degree of clock stretching are not expected, can you please confirm that BQ76972 is not operating nominally in my case?

    Do you suspect the causes of this behavior lie in my design?

    Thank you for your time in advance,
    Vasily

  • 0 in reply to Vasily Shmatalyuk
    TI__Intellectual 1350 points

    Hello Vasily,

    The SCL frequency and degree of clock stretching are not typically expected from the device. This is most likely due to how the device is setup, and the interfacing used to communicate with the device. I am not quite sure how the differential extenders may come into play with the communication protocol, but maybe reaching out to that team could help as I am unfamiliar with that device and its effects.

    Regards,

    Rohin Nair