• State TI Thinks Resolved
  • Locked Locked
  • Replies 13 replies
  • Answers 7 answers
  • Subscribers 63 subscribers
  • Views 842 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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 - I2C becomes unresponsive

Michael Schober
Prodigy 70 points
Part Number: BQ27621-G1

I've a quite similar problem.

Using the BQ27621YZER-G1A in all our devices (almost 3K out in the field).

Occasionally in about 20% of the devices the I2C communication completely goes silent - even when other devices on the same bus resumes working.

Observations in the field didn't help either - absolutely no hint what circumstances could trigger this behavior.

Since the BQ27621 is directly powered from a battery, board reset doesn't help.

Only when removing and re-connecting the battery the BG27621 starts communicating again.

Is there any way to re-trigger the I2C state machine part in the BQ27621 ?

BR

Michael

  • 0
    TI__Guru* 76230 points
    Hi Michael,
    How do you have the gpout pin connected on the device. Is it connected to the gpio of your host? if yes, can you toggle the pin high and low to see if comm is restored?
    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 70 points

    Hi Onyx!

    GPOUT isn't connected at all.

    BR

    Michael

  • 0 in reply to Michael Schober
    TI__Guru* 76230 points
    Hi Michael,
    The data sheet recommended connecting that pin. For debug purposes, can you toggle that pin with a power supply to see if you are able to restore communication.
    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 70 points

    Hi Onyx.

    Sorry, but the GPOUT is not connected - unfortunately I even can't access this pin - due to SMD mounting.

    Additionally, the device is always on and never put to shutdown mode - at least not intentionally.

    Any other work-around? Any idea what probably could cause this behavior?

    BR

    Michael

  • 0 in reply to Michael Schober
    TI__Mastermind 42535 points
    Not really, a powered gauge won't enter shutdown unless by command or if battery is depleted. We will check with hw.
  • 0 in reply to Batt
    TI__Guru* 76230 points

    Michael

    Do you have pull-ups on your com lines such that the lines are not floating when not connected to the host?

    On a latched up board, can you hold the clock and data lines low for atleast two seconds to see if there is a recovery?

    thanks

    Onyx

  • 0 in reply to Onyx Ahiakwo
    Prodigy 70 points

    Hi Onxy!

    Within the past two week I tried to figure out the circumstances which seems to cause the problem - without any significant results.

    I've been working on two issues:

    Issue 1: Finding the reason for this problem.
    In normal operative mode - also during sleep state, data and clock are connected via the MCU's interna pull-up to Vcc... (MCU is STM32F4xx).
    During reset and also when the device is switched off - the lines are more or less floating (connected to the unpowered MCU).
    It's my best guess, that somehow this confuses the I2C state machine within the gauge chip which stays powered from the battery side.

    Issue 2: Recover unresponsive devices ...
    It seems that nothing is helping besides cut-off from the battery side. I tried to pull down data/clock for reasonable time - no result...
    Is there any other idea like bit banging data/clock lines or whatever to regain control over the gauge chip via I2C ?

    I really need help from your side now, because I run out of ideas...

    BR

    Michael

  • 0 in reply to Michael Schober
    TI__Guru* 76230 points
    hi Michael,
    We do not typically recommend keeping the comm lines floating. You need need to find a way to access the gpout pin to toggle it high then low or low then high to test if this will recover the device.

    thanks
    Onyx
  • 0 in reply to Onyx Ahiakwo
    Prodigy 70 points
    Onyx,
    yes in normal circumstances I would fully agree with avoiding floating comm lines.
    But with a battery gauge chip like this, which is designed to be supplied from a different power source the than rest of the host, it's not applicable to keep comm lines pulled up when the entire host system is completely powered down...
    But I've to correct myself -> we're not using the internal Pull-Ups -> we're using 10K resistors to the host's 3V supply - but witch is also powered down... when host is in off mode...

    I'll try find a way to access the gpout pin - but since we're using the BGA packaging it's going to get a little tricky...
  • 0 in reply to Michael Schober
    Prodigy 70 points

    Hi Onyx,

    during my try to fix a tiny wire to the A1 (GPOUT) pin i guess i made a temporary shortcut to A2 pin (SDA) which is pulled-p with a 10K resistor to the host 3v supply and also connected to a GPIO port on the STM32 (but CPU and also the 3V supply are shut down anyway).

    And it immediately started communicating when the CPU was powered on again...

    Guess something happens during brown.out when CPU goes off...

    For next board revision we'll connect this pin to a free CPU GPIO to be able to pull-up, pull-down or toggle or whatever need to be done...

    So, any idea how to prevent this from happening with the existing boards?

    How can floating SDL/SCL lines result in this behavior?

    BR

    Michael

  • 0 in reply to Michael Schober
    TI__Guru* 76230 points

    Hi Michael,

    ESD is one known cause that causes this latchup. Sending multipe transactions to the gauge without sufficient delays can cause the latchup as well. There is no one absolute root cause, that is why we recommend tying the gpout pin to a gpio pin of your uC. There really is no way around that.

    thanks

    Onyx

  • 0 in reply to Onyx Ahiakwo
    Prodigy 70 points
    Hi Onxy!

    I already started a design change to get the GPOUT pin connected to a GPIO port.
    For the current boards I probably have the possibility to make a shortcut between A1 (GPOUT) and A2 (SDA).
    But even this is kind of difficult because of the BGA housing.
    Would this have unpredictable side effects ?
    Would be good to know...

    BR
    Michael
  • 0 in reply to Michael Schober
    TI__Guru* 76230 points

    Hi Michael,

    Are you saying you intend to connect GPOUT to SDA for the purposes of waking the gauge from shutdown? While this might seem like a viable method, we haven't tested this out to know if there will be any repercussions.  If you meant have a trace inbetween those pins, that should work. i don't envisage a draw back doing it that way.

    thanks

    Onyx