• State
  • Locked Locked
  • Replies 5 replies
  • Subscribers 65 subscribers
  • Views 778 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.

BQ76952: bq76952

Mohit Aggarwal
Prodigy 90 points

Part Number: BQ76952

Hello TI Team

We are using BQ76952 for the low voltage BMS application.

In this we are using I2C communication to interface with the mico-controller. We are facing one problem that is for some communication is working fine but after some time it stop working.At stop condition SDA will be low and SCK will high.

In this condition to start the communication only method is we have make RSHUT pin High then it will start communication again.

Can you please give me the idea why i2c is stop working and only RSHUT pin it start working.

Is there anything which we are missing,

Thank you & Regards

Mohit Aggarwal 

  • 0
    TI__Guru* 81035 points

    Hi Mohit,

    The microcontroller should control the SCL pin. The BQ76952 may hold the SCL pin low if it needs to clock stretch, but only the microcontroller could hold it high. The BQ76952 I2C should never freeze.

    Regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 40 points

    Hi Matt,

    Mohit and I are working on the same project. 

    1. Our microcontroller (RH850) does support clock stretching as is mentioned in the below snap from the datasheet:



    But still, during transmission, either of the two- SCL or SDA is held low and is not recovered.

    2. Also, in STM32, using the same code as given in the example code. We observed a similar issue and for verification, we disconnected I2C lines from BQ76952 IC and observed toggling of SDA and SCL was happening as expected. But after reconnecting BQ76952 IC, the issue exists and SCL line was not held high.

    3. With both controllers, the situation was recovered when RST_SHUT pin was manually reset.

  • 0 in reply to Neetika Verma
    TI__Guru* 81035 points

    Hi Neetika,

    It sounds like maybe a transaction was not completed (if the RST_SHUT pin is able to recover communications). The standard method to recover the I2C bus is to send 9 clocks from the microcontroller. 

    I have never seen this issue from other users using the STM32 and I have done much testing myself with this microcontroller.

    Regards,

    Matt

  • 0 in reply to Matt Sunna
    Prodigy 20 points

    Hi Matt,

    1. Can you please elaborate on how we detect that a transaction is not completed? After sending 9 clocks does the AFE resume from where it has stopped?

    2. Do we have a possibility that the AFE could be busy sampling and may take some time to respond? Our MCU definitely supports clock stretching. If we put the clock stretching aside for a while, does the possibility of the MCU not responding occur during the sampling of voltage, current, and temperatures?

    3. We are using a super loop architecture where we read voltages, current, and temperature every 100ms. Irrespective of the full scan we are reading these values for every 100ms. The internal sampling of BQ76952 is for every 63 ms. Would this be a concern or a possible cause for the communication to halt or freeze?

  • 0 in reply to Manikanta Lakkaraju
    TI__Guru* 81035 points
    1. I do not know of a way to detect if a transaction has not completed. Sending 9 clocks to recover an I2C bus is not unique to this device - this is a common practice for I2C to reset the transaction. 
    2. The AFE will clock stretch as needed, but it should not be for a long time as you are describing. The MCU controls the clock, so if the MCU stops sending the clock during one of these transactions, this could also explain what you are seeing.
    3. This method of reading values at a fixed interval is fine - many users use a method like this.

    Best regards,

    Matt