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.

BQ27542-G1: Fuel Gauge Holding the SCL line to Low and I2C bus locked - Working only by doing a Power reset that is not possible in our device

Part Number: BQ27542-G1

Hi TI Team,

We are using BQ27542 FG in our system and we understand that this is the Pack side gauge and we are using the LiPO cell and made a Battery pack by using this FG.

There are almost 20K devices that we made and started delivering to the customers.

We now start seeing one of the random issues in which FG is holding the SCL line to Low and not releasing it without a Power reset. And this issue is occurring at longer run.

IN all of the units, one of the common behavior we have seen that the battery is 100% charged and still we have seen this bus lock issue.

Can you please help us to solve this issue?

Also please see below are a few more concerns -

1. We wanted to understand that in which condition, FG makes the SCL line low and making the I2C bus locked?

2. As FG goes to Sleep mode automatically, for Ex - If FG is in the Sleep mode when the Overcharge Mosfet of the Battery Protection is OFF and also there is no discharge, DF updates inside the FG occurs at every 20 seconds but what if we are reading the data at every 10 seconds still?

Below is the Circuit diagram for reference -

Thanks

Saumil

  • Hello Saumil,

    So the issue only occurs when the battery is fully charged?

    Our gas gauges will clock stretch the SCL line while they're processing requests, it could be possible the firmware becomes locked up under certain conditions.

    Have you tried holding the lines low for 2 seconds for the fuel gauge to release the communication lines?

    DF won't update every 20 seconds, but the RAM will when it reads IVT data.

    Sincerely,

    Wyatt Keller

  • Hi Wyatt Keller,

    Thank you for your response.

    Yes, up till now we have seen this issue when the External Power is always connected and Battery is fully charged.

    When you said that gas gauges clock stretch the SCL line in certain conditions,

    - What are these certain conditions? Can you please explain more in brief.

    We have tried by holding low to both the lines SCL and SDA and it has released the SCL line by this logic.

    Do you mean to say that this logic must require to be implemented in the Firmware? What is the reason behind this?

    Also, this is Very random and occurs sometimes and also some of the units so reproducing the issue also is very difficult.

    If you can answer the above queries then it helps us to understand all the situations and we can reproduce the issue and try to avoid gas gauge lock the Firmware I2C bus.

    Thanks 

    Saumil

  • Hello Saumil,

    I would advise adding a error condition where if this condition occurs, you hold the comm lines low to reset the gauge comm engine.

    It will happen if the FW has an issue pulling the data for the comm engine or if something unexpected happens in that period to halt the gauge mid-transaction.

    Sincerely,

    Wyatt Keller

  • Hi Wyatt,

    Thank you for your response.

    We will add the recovery logic as per your suggestion to hold the comm lines low for 2s to reset the gauge comm engine.

    But, our goal is to find out the actual root cause such that fuel gauge shall not enter this mode itself.

    We do not want error to occur.

    When you say FW has an issue to pulling the data from comm engine, do you mean Fuel Gauge internal Firmware?

    Also, something unexpected occur in the mid-transaction, do you mean data processing transaction?

    Because we are not doing any write execution to the Fuel gauge and we are reading only read only resistors at every 10 sec so Where this unexpected things can happen?

    Also, why is it related to battery full charge?

    Please share the details on this then we shall have a better understanding.

    Thanks

    Saumil

  • Hello Saumil,

    These are unexpected errors that occur, I will have to talk with our firmware team to see if they know the exact reasons why they occur. Either way, we include the 2 second reset method in the documentation for customers to use in case an error like this happens so they can include it in their code for any bus timeout error.

    Sincerely,

    Wyatt Keller

  • Hi Wyatt Keller,

    Ok, thanks for the information.

    We will add this 2S recovery logic in our FW and will test it.

    Meanwhile, I will still need more information from your FW team if you can bring such that we shall know about these unexpected errors.

    Please do the needful.

    Thanks

    Saumil

  • Hello Saumil,

    Waiting for their response. Usually it is complicated to tell where the errors originate from and it's the easiest to implement the timeout protection in firmware.

    Sincerely,

    Wyatt Keller