• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 64 subscribers
  • Views 789 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Original question:

BQ76952: I2C Communication Issue with BQ76952 - SDA Line Stuck Low

BQ76952: BQ76952: I2C Master-Slave communication issues

Karol
Prodigy 30 points
Part Number: BQ76952
Other Parts Discussed in Thread: BQ76942

Tool/software:

Hi! 

 
We have faced a problem regarding I2C communication between STM32 (master) and BQ76952 (slave) that we both have on our battery management system. 

We have two issues with I2C. 

First I2C issue: 

Using the same device and same software we noticed three situations that occur randomly: 

  1. After boot write commands are not returning any errors and further communication is correct. 
  2. After boot few initial write commands are returning error and further communication is correct. However, we have noticed that some devices lost communication after longer period (for example two months) and we don't know what the reason for it is. Only after rebooting STM32 communication is correct. 
  3. Sometimes after boot, few initial write commands are returning error and I2C peripheral locks up. In such a case all communication is failing. Only after rebooting STM32 communication is correct. 
  4. I2C Speed: 100 kHz, pull-up resistors are 10k, also tested with 4.7kΩ with no changes 

We solved this first I2C issue by sending 20 empty clock cycles at the start/restart of the system. Also tried with 9 empty clock cycles but with worse results than with 20 empty clock cycles. These 20 empty clock cycles clear the SDA pulled to GND by BQ76952 and let the communication to start properly. 

 

Second I2C issue: 

ST's HAL during normal operation has a problem with handling communication faults e.g. short between SDA and SCL (e.g. environmental pollution between pull-ups). 

We solved this issue by toggling PE bit to 0 and back to 1 if we detect transmission error and BUSY flag is still set after transmission. 

 

Are there any disadvantages that could be caused by these fixes in relation to the BQ76952? These two solutions resolved our issues but we're not sure, if it's ok for some other aspects and cases for the BQ76952. We tested these two approaches and both gave positive results. 

Kind regards, 

Karol 

  • 0
    TI__Expert 4320 points

    Hello Karol,

    1. Yes sending 20 empty clock cycles will work, you can also drive the RST_SHUT pin high for less than 1 second. That will reset the digital logic which should also recover the communications. For more information on partial reset you can refer to [FAQ] BQ76952: How do I RESET the BQ769x2 device?

    2. I don't quite follow your second method. Can you clarify more in depth the method?

    There is no issue with sending 20 empty clock cycles.

  • 0 in reply to Thomas Rainey
    Prodigy 30 points

    Hello, 

    HAL during operation has a problem with handling I2C communication faults such as:

    1. short between SDA and SCL lines (e.g. enviromental pollution between pull-ups).

    2. short between SCL line to the ground.

    STM32 detects this as arbitration lost (ARLO error) like this would be in a muli-master setup (however, in our case there's no multi-master and we have only one master: one STM32). This leaves BUSY flag set on, waiting for STOP condition from other master. In single master case (so in our case) sending STOP condition never happens (there is no other master) and all next transmissions are blocked. According to reference manual, setting PE bit to 0 is the only option to reset this flag if there is no other master that can generate STOP condition. Here's below screen from the STM32 manual:

    As a workaround we are toggling PE bit to 0 and back to 1 if we detect transmission error and BUSY flag is still set after transmission.Could any disadvantages be caused by this method? We have solved this problem as explained above, but we're not sure if it's ok for some other aspects and cases. We would like not to cause any other problems elsewhere by using our solution.

    Kind regards, 

    Karol 

  • 0 in reply to Karol
    TI__Mastermind 42060 points

    Hello Karol,

    We appreciate the explanation there! I do not believe that would cause problems from our side.

    Now, something I may suggest from the perspective of the BQ76942, is that you check what is the I2C speed configuration of the BQ76942. The part has two modes, 400kHz and 100kHz mode, so the latter probably would want to be used here. I have not personally seen problems with slower clock speeds when using 400kHz, but it may be worth take a look.

    Best Regards,

    Luis Hernandez Salomon