• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 63 subscribers
  • Views 111 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:

BQ25896: Stops outputting VSYS and won't exit "unknown mode"

BQ25890: Won't exit shipping mode

Kim Adrian Huynh
Prodigy 10 points
Part Number: BQ25890
Other Parts Discussed in Thread: BQ25896

Hi,

We have two battery-powered products with BQ25890 and we've got a few returns due to "dead" devices.

We suspect it happens when shipping mode is enabled, but we're unable to reproduce the problem in our lab.

When the product was returned we did some measurements around the BQ:

  • VBAT: 3.45V
  • VBUS: 0V
  • VSYS: 0V

Since the devices can be externally powered/charged with a USB cable, we inserted a cable with power and did some new measurements:

  • VBAT 3.45V
  • VBUS: 5V
  • VSYS: 0V

Tried toggling VBUS a few times, but the BQ would never power up the VSYS. The expected result is that it would exit shipping mode and power up the system.

A logic low on QON for around 1 second powers the system as expected.

Since our host is powered by VSYS we were unable to read the registers.

Are there any situations where toggling VBUS won't power up VSYS again?

I saw a post regarding BQ25896 where there was a known issue regarding I2C comm while entering ship-mode. Does this issue also apply to BQ25890?

  • 0
    TI__Mastermind 24080 points

    Hi Kim, 

    Thank you for reaching out via E2E. 

    Kim Adrian Huynh said:
    I saw a post regarding BQ25896 where there was a known issue regarding I2C comm while entering ship-mode. Does this issue also apply to BQ25890?

    Yes the known issue on BQ25896 can also occur on BQ25890. If an I2C communication is incomplete at the time SYS power (i.e. MCU host power) is lost there is a risk of getting into a locked up state where VBUS plug in will not result in the device exiting ship mode. 

    Our recommendation is to ensure BATFET_DLY in REG09 is set to 1b to add a 10 sec delay between I2C communication and the device entering ship mode. 

    Best Regards,

    Garrett 

  • 0 in reply to Garrett Kreger
    Prodigy 10 points

    Hi Garrett,

    Thanks for the confirmation and recommended solution.

    If we add the 10 sec delay, is it still safe to have the I2C pull up on VSYS?

    Ref. your comment from an other post:

    Regarding your initial report of the device getting stuck in an "unknown state" the behavior appears to match an issue on this device where it can get "locked up" due to entering shipmode in the middle of an I2C communication. Typically this will happen when the I2C pullup rail is SYS. 

    Do you know if the watchdog will get it out of the "locked" state?

    We could for example set the watchdog in host mode, enter shipping mode. This will shutdown our host and stop kicking the watchdog. When the watchdog expires, it will return the BQ25890 back to default mode and reset registers.

  • +1 in reply to Kim Adrian Huynh
    TI__Mastermind 24080 points

    Hi Kim, 

    Kim Adrian Huynh said:
    If we add the 10 sec delay, is it still safe to have the I2C pull up on VSYS?

    Correct. I will note that ideally I2C pullup would be to a always on source to eliminate the risk of I2C pullup being lost prematurely, but this is typically not practical in a portable application. 

    Kim Adrian Huynh said:
    Do you know if the watchdog will get it out of the "locked" state?

    The watchdog will not have any affect. Watchdog expiring is not a way to get out of the locked state.

    Best Regards,

    Garrett