• State TI Thinks Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 63 subscribers
  • Views 358 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:

BQ25619: Unused pins

BQ25619: Investigating the causes of systematic VSYS failure / fault after a period of time

Ibrahim Kamal
Intellectual 390 points
Part Number: BQ25619

Hi,

Here is our (simplified) configuration:

When the host MCU is powered ON, it will reset the BQ25619 registers, change the charge current to match our battery, then pull CE to 0 to enable the battery charge. So far so good.

When battery drops below ~3V, MCU is powered down, and both SDA and SCL lines become floating (i don't know if this is related to our problem).

After a period of time (hard to quantify, but more than an hour) if we apply power again (around 12V), we never see any powerd delivered on VSYS.

The only solution to get out of this situation, is the to provide an external power source to the MCU so that it can boot up (and eventually reset the charger) and then everything is back to normal.

I'm still not sure if I got the chain of events and causality right though...

We managed the read charge fault "01" once, which is coherent with our problem: input fault.

All points toward what seems to be wrong OVP parameters being written in Charger Control 2 (0x06), which would explain everything. The problem is that we never touch this register, and reset values should not cause any issues (we use 12V input).

Could floating I2C lines cause that eratic behavior?

Could a watchdog timeout cause that behavior?

Please not that at this stage, our problem is not to charge the battery, but just to get output from VSYS pin.

Thanks for your help,

  • 0
    TI__Expert 5590 points

    Hi, Kamal:

    I have a few questions:

    Please confirm if both I2C and MCU is powered by battery? Do you use real battery or just a power supply? When battery voltage drops below 3V, did you disconnect battery or decrease battery (or power supply) voltage to a certain level? What is the MCU's UVLO voltage?

    In your application, is there a reason you did not use SYS to power your MCU? In that case, even the battery is dead, MCU can wake up immediately.

    Regards,

    Hong

  • 0 in reply to Hong Mao
    Intellectual 390 points

    Thanks hong for your message and sorry for late reply.

    MCU (and I2C) are powered by VSYS, which in case VBUS is absent, well, is in turn connected to battery via the internal BATFET (Q4 if i'm not mistaken).

    I use a real battery.

    One important piece of information: My system has an independent UVLO that switches off at 3.0V and switche back on when battery voltage reaches 3.6V.  So, the default setting of BQ25619 for VSYS_min which is 3.5V is not enough to turn on my system.

    Luckily - i thought - we can modify this by software to 3.7V, which should have solved the problem.

    But the problem remains the same, even if i reconfigure the VSYS_MIN to 3.7V instead of 3.5V.

    So the big question that may answer it all is:

    What happens when VBUS is removed and only VBAT remains ? Or more precisely, when happen when we plug in an adaptor (VBUS) again? is this considered a POR? are the registers retained during the period where only battery is present but not the adaptor (VBUS) ?

    Thanks for your help.

  • 0 in reply to Ibrahim Kamal
    TI__Expert 5590 points

    Ibrahim Kamal:

    With a real battery connected to BAT and MCU connected to SYS, when VBUS is removed, SYS voltage follows BAT voltage. When an adaptor is plugged in, SYS voltage is VSYS_MIN+150mV if VBAT is below VSYS_MIN; If VABT is above VSYS_MIN, VSYS follows VBAT. For the case you described, when adaptor is removed, if the battery present and VBAT>2.62V (VBAT_DPL), the registers will be not be reset. In this case, even adaptor is pugged in back, there is no POR. If VBAT drops below VBAT_DPL and VBUS is plugged back in, POR occurs and all registers go back to POR status. I suspect the registers have been updated somehow when MCU shuts down.

    Regards,

    Hong