BQ25120A: Unexpected behavior with external load directly on VBAT

Hi,

The connection of a load such as LED drivers, directly to the VBAT node of your system can have a few impacts on the BQ device performance.

L Z said:

When reading the battery voltage monitor I get 0x80, but only after a while.

This represents the register value? This is certainly an unexpected value since bit7 should always readback as 0. Can you confirm this I2C communication is valid? A waveform of the SCL and SDA lines during the read transaction of this register would help in confirming this transaction.

L Z said:

Starting at around 250 mA, the voltage on LS/LDO, when turned on via LSCTRL, turns on and off unreliably

Can you confirm, 250mA is the load on LS/LDO, or the external load on battery? Is this while VIN is present or only Battery is present?

L Z said:

- SYS is shutting down (and reactivating). At 500 mA SYS starts to fail (off for ca. 400 ms, then on again for often about 2 s, but the on period varies a lot, sometimes less, sometimes a lot more).

Can you confirm, 500mA is the load on SYS or the external load on battery? Is this while VIN is present or only Battery is present?

The current that is drawn by these loads, during charging, subtracts from the configured charge current. So if the charge current is configured for 100mA, but your load is pulling 50mA, then your battery will only be charging at about 50mA. Additionally, the current pulled by the load can have an impact on the voltage measured at the VBAT pin. The VBAT pin voltage is used by the charger to determine behavior, such as BUVLO, charge current, etc. 

The device is designed such that VBAT is primarily connected to a battery, which models a very high capacitance and slow change in voltage. The sudden load from the LED drivers may cause a quick change in VBAT that crosses the thresholds mentioned. Can you capture a waveform of VBAT voltage along with VSYS voltage when SYS starts to fall off, when LS/LDO stops working reliably.

Best Regards,

Juan Ospina

Thank you for the quick reply.

You are right, I checked I2C with an oscilloscope and the PMIC does not reply at all when getting the faulty readings. I have to check why I did not register any I2C error here. But then the chip does not respond at all - why is that?

The load values I reported are all loads on VBAT directly, not on SYS. The load on SYS should be < 50 mA.

I already took into consideration the charging and VBAT limitations you mentioned, but the PMIC not behaving as expected is what threw me off.

Here is what I captured on an oscilloscope:

LS/LDO failing (purple: LS/LDO, yellow: VBAT, blue: SYS):

SYS failing (purple: LS/LDO, yellow: VBAT, blue: SYS):

Hi,

To get a better understanding of what is happening, I'll attempt to recreate the behavior on my end. Just to confirm is this behavior present when VIN is present, or only during Battery-only mode? Additionally, is it safe to assume your battery cell voltage is about 3.6 - 3.8V? Does the actual battery cell voltage differ at all from the VBAT pin voltage?

Lastly, can you please share a schematic of the power-set up?

Best Regards,

Juan Ospina

This is when VIN is not present. With VIN the problems are not there.

The battery voltage is currently at 3.75 V, so that should be fine. And since it is connected directly to the BAT pins, VBAT should be the actual cell voltage. I can also recreate this with a lab power supply. The Problems disappear/appear when raising/lowering the voltage (although at different thresholds, but the measured VBAT voltage was always above 3.45 V when the problems appeared with a VBAT current draw of 370 mA)

The chip is in active battery mode for reading the registers and otherwise in Hi-Z mode.

These are the schematics:

VCC is connected to some peripherals (MCU, sensors ...) and VCC_BAT is connected, apart from the battery itself, to 2 LED drivers and another single LED.

Some more testing with the lab supply shows that the battery monitor measures a much lower voltage than what I am measuring in reality. With the lab supply at 3.67 V, I measure 3.56 V at a VBAT load of 237 mA, but I get 3.23 V from the battery monitor. This is the point where the chip does not reply anymore, right after the battery monitor crosses the 3.3 V threshold. SYS is configured at 3.3 V, so could this be related to the failure?

With the real battery I'm seeing a similar mismatch between the battery monitor and the actually measured voltage. At a cell voltage of 3.74 V, the actual voltage under load (243 mA) drops to 3.59 V while the battery monitor reports ca. 3.32 V (78-80 % of VBATREG (4.2 V)).

Edit: The mismatch was apparently introduced by a current measurement device I had connected in series. When connecting the battery directly, the reported battery monitor voltage matches the actual battery voltage. However the problems with the chip not responding anymore start at around 3.26-3.27 V VBAT.

These are the I2C waveforms:

ok:

fail:

Yellow is VCC. SDA/SCL are pulled up to VCC with 4.7 kOhm resistors. When VCC drops, SDA/SCL are not pulled as high anymore, but should still be well within limits of being recognized as high levels.

Thank you for that information! I will try lowering SYS.

Does that mean that when the battery is drained below whatever SYS is configured as, I will not be able to communicate with the chip at all?

Yes, that's right.

We do see that in many applications the SYS is set as low as 1.8V so it wouldn't be a problem for those applications since Li+ batteries shouldn't be discharged that low. But for higher VSYS applications that is a limiting factor.

Best Regards,

Juan Ospina

Thank you for your help!

Another thing: Can you confirm that the chip indicates a fault in its status register when VINDPM is enabled and the threshold is reached?

And is there complete documentation about in which cases the status register shows a fault? That would make it much easier to actually handle currently undefined faults.

Okay thank you, I missed that in the table. So there shouldn't be any other cases where the status field is set to fault? In my other question you answered that in case of VIN ILIM fault the status is set to fault as well which is not documented (or I misinterpreted the wording) and made me wonder if there are other cases which could be relevant for me how to handle a fault status. But if that is it, that should be fine!

That's what I suspected now, thank you for the clarification and all the prompt help!