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.

BQ25895: Unstable output under marginal Vbus supply

Part Number: BQ25895
Other Parts Discussed in Thread: TIDA-01556, TIDA-00818, TIDA-01182, BQSTUDIO

Hi there

I have been investigating an unusual problem. I have not found a major issue with our implementation, but have checked all of the obvious things. Our schematic is attached at end.

The design charges correctly, reads correctly, bucks correctly. It has good efficiency (89 - 90%). We have been testing the design with a solar panel (6V / 6W). The problem is when we have a small amount of power available (low light for the solar panel).

The custom board

1. Under low light conditions, our hardware (our own PCB) implementation results in output going to 2.3V, even with battery source provided (3.5V) with no load connected. This is with a little light on the solar panel and the EV2300 USB -> I2C interface sitting on I2C bus. Our MCU is powered from Vsys, once it is powered, for testing purposes it sets the configuration and then sits in an infinite loop (while(1);). With no load on the output the following happens:

  • when the solar panel is covered, it results in a stable Vsys output.
  • when the solar panel is given more light, it results in a stable Vsys output. 
  • with an electronic load on the output (almost any load, for example just 2-3mA) it will result in a stable Vsys output.

The scope shot below shows the hand over the solar panel (first half, stable Vsys) and then removing the hand so the solar panel is illuminated by the workshop.

Extracting the following settings:

With hand on solar panel

Immediately after removing the hand off solar panel (getting workshop light)

A short time after the above

Scope shots of SW (= 2.29V DC), REGN (= 4.23V), ILIM (= 20mV), SYS (=2.31V), BTST (=3.73V) are all DC in this state. As mentioned, I can simply add more light or less and it will revert to a stable condition, otherwise it will stay in this state indefinitely..

The following items have been checked:

  • Switching waveforms when charging appear normal and regulation reasonable
  • All capacitors on PMID are X7R / 25V / 10% / 1206 on input
  • 1uF on Vbus (0805, 10%, 25V, X7R)
  • output capacitance is 40uF (10V / 0805 / X7R / 10%), with 20uF of it being immediately next to the chip
  • Inductor has a rated current of 5.2A, a saturation current of 7A and max DC resistance of 26mR (74438357022)
  • All connections are very similar to the evaluation board (generous copper where it matters)
  • Analog and power grounds where connected to the same ground plane (identified as potential issue).

I re-routed the analog grounds so they connect at pins 17,18 (PGND). I did this by lifting the components so TS, VREG, ILIMIT ground connections are routed via kynar wire to pins 17,18. This did not change the behaviour.


  • The power supply used for the 3.5V battery supply has sense leads, generous cable sizes and a Keithley power supply behind it.
  • Also tested with a 3.5V battery with short leads with same results
  • Checked that the bootstrap capacitor was correct (refitted one with labelled bag from mouser part # CGA2B3X7R1H473K050BB)

Evaluation Board

I decided to check the evaluation board for similar behaviour with the BQ25895 Evaluation board and test with a power supply instead of the solar panel.

JP1 - not fitted
JP2 - /PG + PG
JP3 - short to DSEL
JP4 - short to VSYS
JP5 - installed
JP6 - not fitted
JP7 - not fitted
JP8 - not fitted
JP9 - installed
JP10 - installed

  • 5.2V supply, 6mA constant current limit on Vbus w/ 1000uF electrolytic on input
  • 3.5V from power supply or battery (2A limit when from PSU)
  • No load on output.
  • The following configuration from battery management studio

The following trace is given. Note that this behaviour is not in itself incorrect, as it does not drop significantly below the Vbat voltage. Good enough!

Setting FORCE_VINDPM = 0 seems to solve the above problem (sawtooth shape). We do actually want to use FORCE_VINDPM so we can do peak power tracking though (as per TIDA-01556)

When removing the additional fake solar supply on Vbus, it drops correctly and doesn't drop below the battery voltage. Good enough!

Our board (same test as evaluation board)

We can simulate the panel in a similar condition using:

  • Hardware as per schematic
  • 5.2V supply, 6mA constant current limit on Vbus w/ 1000uF electrolytic on input
  • 3.5V from power supply or battery (2A limit when from PSU)
  • No load on output.
  • The following configuration set by MCU, then goes into while(1) loop. Read settings into battery management studio from I2C bus (same settings used on evaluation board)

The trace shows the device dropping significantly below the battery voltage. Not good enough!

If FORCE_VINDPM is unticked (= 0), then looks stable. Switching on / off the 5.2V / 6mA constant current supply it does not resume to battery voltage gracefully.

What next? Questions..

  1. Theories as to why it lets the Vsys drop below Vbat indefinitely in this marginal condition?
  2. The PCB design is a possible cause, since PGND and AGND share the same ground plane - although otherwise it is very similar to evaluation board. ( notice TIDA-00818 does shares PGND and AGND on ground plane). I had modified one board to isolate all AGNDs and connect at a single point, pin 17/18 using wire.
  3. Possibly improve the connection to ground on C12 (input cap 1uF) or C17 (battery cap 10uF)?
  4. It mentioned connecting AGND to PGND using the power pad as the single connection point (P55, 11.1 point 4). Is 17,18 electrically different from power pad? On TIDA-01182 17,18 are connected to thermal pad.directly (no via), on the evaluation board they are kept separate and joined through thermal pad vias.
  5. Larger input capacitor? (currently 1uF / C12, but seems unlikely since PMID capacitance == 40uF)
  6. Differences in the jumper configuration on evaluation board and our board making a difference?
  7. I have checked the SW behaviour on the oscilloscope and it looks stable when charging.
  8. Is there any tuning needed around the bootstrap capacitor? (note 0R fitted R19).

I can take any measurements necessary... Help!

PCB design


  • Hi there,

    This post about solar application has a lot of register settings and hardware configurations. We are reviewing the information and will get back to you by tomorrow.
  • I have some additional information that may help:

    1/ I added 10uF / 0805 / X5R / 25V to Vbus (piggybacked on 1uF) - no change

    2/ Added additional wire from GND of C17 (Batt cap) to 17,18 to improve ground connection - no change.

    I forgot to mention, from the 'solar supply' setup (5.2V / 6mA CC on our board), there is a schottky diode before the 1000uF capacitor - PMEG40T20ERX.

  • Hello,

    I think there is a very basic problem here; the load and/or startup current are too much for your solar panel too support, especially at low light.

    At every low light, which I assume you are using a 6mA current limit to simulate, the operating IQ of the charger is well beyond what the charger can handle. The VINDPM loop can only regulate charge current and the system so much. As such, with this amount of low power, the input basically crashes. The converter cannot do anything to keep the input from falling below the sleep threshold.

    What I imagine the sawtooth waveform representing is the constant converter start and stop as the solar panel becomes unloaded and loaded, respectively.

    You can also notice this when you look at the BQStudio GUI. The VBUS status says "No Input" in every scenario.

    So in general, I think this is just a power limitation of your panel when heavily shaded (and frankly, of any panel that is heavily shaded ) and not a design issue. I would also confirm your findings using actual UV light. You mentioned your shop light, but I would also check outside in the sun with your actual solar panel.

    Joel H
  • Hi Joel, thanks for the reply.

    I don't think that is what is happening ---

    1/ All of the tests carried out in the first post are with a 3.5V battery or 3.5V power supply on Vbat. According to several descriptions in the datasheet, but prominantly it should not fall significantly below Vbatt. Please see image below.

    2/ TIDA-01556 describes exactly this application, with Vsys being used to power the controlling MSP430 microcontroller, so it has to be stable. Whilst these TI designs are not guaranteed, I would hope they have gone through some testing - low light is common in solar applications (at least twice a day - sunrise and sunset!)

    3/ The evaluation board does not exhibit this behaviour and I cannot reproduce the 'complete failure' behaviour on the evaluation board.

    If you are not sure, does Chris Glaser / Jeff F have any thoughts / things to test / try?

    Thanks again

  • Hello,

    I still think the operation is due to the power output of your power supply. In fact, even the evaluation board shows an improper waveform. Once the input voltage has been regulated, it should not oscillate as you've shown. It could be due to slight differences between board design and where power is derived from that causes one to dip more than the other.

    Another thing I want to point is TIDA-01556. This reference design assumes that you are charging. In your screenshots from BQStudio, charging is disabled (the checkbox is unchecked to Enable Charge). The controlling loop here, VINDPM, reduces charge current to regulate the input voltage to a certain threshold. Without charge enabled, the output voltage loses regulation.

    The other point here is the voltage you are forcing VINDPM to is 5.2V. From this, VINDPM is being set exactly to your power supply voltage. From my previous comment, without being able to reduce charge current, the converter's VINDPM will allow VSYS to fall. And when you set to 5.2V, the converter immediately will pull back on the delivering output current as soon as you turn the supply on. You may be want to set the VINDPM threshold to 5.0V or 5.1V to test, but this is likely not the only problem. I think one other major difference between your custom board setup and the EVM board setup is your continually running MCU. Try programming the charger once (just disable the watchdog timer in the charger's register) with your MCU and place it in its Lowest Power Mode AND then power on your 5.2V/6mA bench supply. You will likely want to look at how much current your MCU is drawing to operate that code, even if it is in an infinite loop. If we assume 90% efficiency in this ultra light load condition (which is being generous if you look at Figure 2. System Light Load Efficiency vs System Light Load Current in the datasheet, you can see how quickly the efficiency falls), then the available power to the output to SYS is 28mW. At 3.7V (VSYSMIN), your MCU cannot nor anything on VSYS can consume more than 7mA of current.

    At the end of the day, the MPPT is trying to find the optimal power point of your supply. However, if even at that optimal point the output is still demanding more power than your system is attempting to consume, the panel voltage will collapse. Your power supply will collapse.

    As I mentioned above, you can quickly check several things:
    1) Monitor the VBUS voltage as VSYS droops from your waveform)
    2) Monitor the SW node of the charger; you will likely see almost zero HSFET switching pulses.
    3) Monitor (using a separate supply rail for comms.) the state of the charger through BQStudio, such as VINDPM or Power Good state)
    4) Change the VINDPM threshold to something lower. This may not make a different as the input power is very low
    5) Enable charge

    Joel H
  • Hi Joel

    Thanks for the details.

    I understand that the waveform, even on the evaluation board is not correct. The key point is that it should not fall below the battery supply voltage.

    I am programming the evaluation board with the identical settings to the custom board. Once the MCU has booted, it only programs the settings once, then goes into an infinite loop. The watchdogs are already disabled in this setup. The MCU uses 2mA.

    ____The whole point of this part is that if necessary, the battery will supplement VSYS appropriately, so it does not fall significantly below the battery voltage.____

    The problem I am raising is that I can reproduce conditions that mean that it can fall below the battery voltage indefinitely, or it oscillates and falls below the battery voltage. It shouldn't do this, even if there is not enough power on the input (because it will be supplied by the battery).

    I will test again with charge enabled, but I don't see any reason why the battery should not supplement this with or without battery charge enabled.

  • Hello,

    I think we are on the same page then. You are correct that the battery should supplement the power to the system.

    I will have the check this on the bench with similar test conditions.

    Joel H
  • Great. I intend to start a new prototype with attention to the ground plane AGND / PGND separation soon, but I would like to understand the behaviour I am seeing (i.e. indefinitely sitting below battery supplement voltage) first.
  • Any update on this?
  • Hello,

    I dug further into this and could replicate it, even on my EVM.

    I used the same settings you described above, but was unable to replicate on my EVM with my power supply:
    "Evaluation Board

    I decided to check the evaluation board for similar behaviour with the BQ25895 Evaluation board and test with a power supply instead of the solar panel.

    JP1 - not fitted
    JP2 - /PG + PG
    JP3 - short to DSEL
    JP4 - short to VSYS
    JP5 - installed
    JP6 - not fitted
    JP7 - not fitted
    JP8 - not fitted
    JP9 - installed
    JP10 - installed

    5.2V supply, 6mA constant current limit on Vbus w/ 1000uF electrolytic on input
    3.5V from power supply or battery (2A limit when from PSU)
    No load on output.
    The following configuration from battery management studio"

    From your BQStudio screengrab, it looks like the charger does not detect an adapter at all, which means the input is just crashing. I would recommend trying this test with a different power supply.

    Another thing you can try is disabling ICD (uncheck Enable ICD checkbox) in BQStudio. It looks like at some point, the ICD is running and setting the input current limit at 1.6A which is odd considering that it is not in the "Optimized" state.

    The last thing I will suggest is adding some capacitance on VSYS. Maybe 20uF to 100uF extra to see if the behavior improves.

    Joel H