• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 3 answers
  • Subscribers 62 subscribers
  • Views 1300 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:

BQ27621 - I2C becomes unresponsive

BQ27621-G1: BQ27621 Fuel Gauge locks up/becomes unresponsive with ESD - How to reset?

David Smith11
Prodigy 50 points
Part Number: BQ27621-G1


We are using a BQ27621-G1 that works largely as we'd expect under normal circumstances.  We have noticed some conditions related to ESD with our product containing the BQ27621-G1 that results in the BQ appearing to lock-up, or at the very least not respond to I2C traffic sent to it.  The part will not respond until power is removed from it and reapplied.  If it is power-cycled, it begins to work as expected and responds to I2C messages sent to it.

We can duplicate this issue using an ESD gun by discharging it into certain locations on our product.  While we are going to attempt hardware design modifications to eliminate this, we would like to know if there are any ways to restart/reinitialize/reboot the BQ27621-G1 when it ends up in this condition other than a power-cycle.  In our product, the BQ is connected directly to the enclosed battery, so there is no way for the customer to power-cycle it.

Specifically, is there anything like: 1) a watchdog timer that can be enabled internally to force a hardware reset, 2) a way to force a reset by manipulating the I2C pins, 3) any specific configuration settings that may address this?  If so, this would provide a potential method to allow for a firmware workaround in our products that are already in the field.

I'd appreciate any leads that I can follow-up on.

Thank you,
David

  • 0
    TI__Guru* 76230 points

    Hi David,

    Implement  in your  FW such that  it has the capability to pull both clock and data  lines low for 2.5 seconds if the gauge does not respond after multiple tries. This should get the gauge to start communicating again. Test this and let me know if it works for you

    thanks

    Onyx

  • 0 in reply to Onyx Ahiakwo
    Prodigy 50 points

    Thank you Onyx - I really appreciate you providing the suggestion!  I will test it out and let you know the results!

    Thanks,

    David

  • 0 in reply to David Smith11
    TI__Guru* 76230 points
    Additionally, Can you verif if it is the i2c that is just latch-up or if the device is in shut down. You can tell if the device is in shut down by mesureing the output voltage on the 1.8V LDo pin which is vdd. If this is a case of shut down then toggling the gpout pin would help get the device out of that state. in your system, this can be done by tying the gpout pin to a gpio pin of your host. The data sheet captures thisin the GPOUT pin description section.
    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 50 points
    Onyx,

    I will certainly check this condition (Shutdown) also by testing the voltage at the VDD pin and report back to you hopefully tomorrow.

    Unfortunately, GPOUT is not connected to our micro in our circuit - it is pulled up to the VDD pin on the BQ27621-G1 with a 51K resistor. Will this automatically make the chip exit shutdown if it enters it since the 1.8V LDO pin would go low in shutdown? If the part does turn out to be in shutdown instead of I2C latchup, is there any other way to exit without having GPOUT directly driven by the micro?

    Thank you,
    David
  • 0 in reply to David Smith11
    TI__Guru* 76230 points
    Hi David,
    I do not believe that will cut it otherwise that would have been the easiest recommendation that would have been offered on the ds. The Gpio should be able to toggle the pin high then low or low then high. That is the the only option short of power cycling the device to get it out of that shutdown state.

    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 50 points

    Hello Onyx,

    I was able to test the options that we discussed:

    1) Pull both I2C lines to ground for 2.5 seconds:

    I made changes to the firmware and tested pulling the lines low for 2.5 seconds after the chip was detected to have entered this condition.  I verified that it was pulling the lines low for 2.5 seconds correctly using the oscilloscope.  Unfortunately, this did not resolve the issue.  The chip continued to be unresponsive until a power cycle.

    2) SHUTDOWN mode (Check the output of Vreg):

    The output of Vreg is 0V when the chip is in the non-responsive state.  I externally pulled GPOUT high and it did wake the chip up.  So I'm assuming that you are correct about it being in SHUTDOWN mode instead of I2C lockup.

    As a result, 2 other quick questions:

    1) What other condition can cause it to enter shutdown? (We never using SHUTDOWN_ENABLE or SHUTDOWN command)

    2) Is there any other configuration-based method to prevent SHUTDOWN from being entered?

    Thank you again for your assistance in this matter. You've been most helpful and it is clear that we need to redesign our circuit to connect up GPOUT.  I'll mark this post resolved after giving you a chance to respond to the 2 questions above.

    Regards,

    David

  • 0 in reply to David Smith11
    TI__Guru* 76230 points
    Hi David,
    -The shutdown issue is known and ESD is usually the culprit. That is why we have that section in the DS to let customers toggle that pin
    - There is no known config short of ensuring you have adequate esd protection that prevents the device from entering shut down.

    Pls still keep the portion in your firmware of holding the lines low as the i2c lock up could happen as well, though very very rarely. This was just recently found out hence why it hasn't made it into the DS sheet yet.

    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 50 points
    Issue resolved. Just want to thank you again for your excellent and rapid assistance! It is very much appreciated!