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: uncommanded setting of BATFET_DIS

Part Number: BQ25895

I've got a BQ25895 charging off solar.  I'm noticing a condition where the BATFET_DIS bit will be asserted on its own, without any command from my firmware.

I initially noticed after powering up via QON (VBUS disconnected) and then plugging in the solar panel and finding that it refused to charge.  On further analysis, BATFET_DIS was set, and the system was only powered from VBUS and couldn't charge.  When unplugging the panel, it of course lost power since the battery was disconnected.

Only about half of my units did that, the other half (identical hardware and firmware) worked fine.

Temperatures are fine, below 40C.

System current is low, it's just running an ESP32.  Less than 0.5A.

My current workaround is to continuously check if VBUS is plugged in and if so, check BATFET_DIS and clear it if it is set.  I also log an error message.

This seemed to work - the system is charging now.  However, I'm seeing my log message come up occasionally with the panel plugged in (possibly from momentary cloud cover), so it keeps happening.  I have to hope that there is enough power on VBUS available to ride through and reset the bit before losing power entirely.  There is no way I can poll fast enough to guarantee this will never happen - it would need a huge amount of capacitance to ride out a power glitch that long.

As far as I can tell from searching here and the datasheet, the BQ25895 will set BATFET_DIS if there is an overcurrent condition on the battery.  But there is just no way I'm hitting that in this design.  The SYS output is just powering a small microcontroller circuit.  There is no way I'm hitting 8A - and this only occurs when VBUS is plugged in to a solar panel, it otherwise never happens.  The circuitry on the other side of SYS is a 3.3V buck converter which is current limited to about 1A.  Additionally, I don't get a brownout on that side - as long as there is just enough solar available, the SYS power stays up.  So in case I haven't made that clear enough: there is no over-current condition occurring, at least not on the load side of the circuit.

There are no faults indicated in the fault register, and all other registers look fine.

Possibly there might be some poor interaction on the VBUS side from a solar input and the BQ25895 gets very confused and decides to try to turn the batteries off.  It would be far from the first bug I've found in the chip logic - it also used to momentarily glitch the SYS output during periods of low light (enough to present a voltage on VBUS but not enough to actually power anything) and I had to fix it by adding a large capacitor on it (so it still glitches briefly, but there is enough capacitance to ride through).  Perhaps this is related to that bug (the datasheet asserts that supplement mode is always available on marginal inputs but this is clearly not true in practice).  It has been extremely frustrating - TI markets this chip as solar compatible but it performs quite poorly in real world conditions.  It works fine as a wall charger but the solar app note was clearly not tested in true day/night cycling and in varying weather conditions.

I'm open to suggestions on how to work around this.  I have to be able to power this thing off solar and have it stay up unless the batteries run down to cut off.  It is not acceptable to cut off the batteries during charging when there is nothing wrong.  I shouldn't have to poll the bit and reset it correctly during normal operation, and I can't do that fast enough to guarantee the system will never lose power.

  • Hi Jeremy, 

    Apologies that you are observing undesired behavior on the BQ25895. The BATFET_DIS bit should only be set on its own due to battery discharge over the current limit or if battery temperature is detected outside the thresholds in boost mode operation. 

    I have a few questions to help my understanding of your system so I can better help debug this behavior. 

    1) You mention "powering up via /QON" does that mean the device is initially in ship mode? 

    2) After powering up via /QON did you confirm that battery powers SYS before solar panel is connected to VBUS? 

    3) Do you ever operate in boost mode? 

    4) In your design what is the pullup rail for the I2C pins SCL and SDA? 

    Best Regards,

    Garrett 

  • Hi Garrett,

    1) Yes.  The device starts in ship mode.  I press the button to turn on via /QON, and then plug in the solar panel to VBUS.

    2) Yes.  The MCU circuit powers up and is operating normally.  The SYS output goes to a 3V3 buck regulator, which powers the rest of the electronics.

    3) The boost converter on the BQ25895 is enabled.  It is used to power some 5V circuits (LEDs mostly).  There are no issues with the boost converter turning off when VBUS is connected (meaning, it does not cause any operational issues with my system, it is designed to handle that).  I have wondered if the switchover from boost mode to charge mode could cause any issues on SYS, but I could never conclusively find out one way or the other.  I just keep boost mode enabled at all times for simplicity's sake now.

    4) I2C is pulled up by the 3V3 rail from the buck converter on the SYS output.

    Thanks,

    -J

  • Hi Jeremy, 

    Thank you for answering my various questions. 

    Based on your answers and the description of the typical load at SYS my theory is that the device is sometimes detecting battery discharge overcurrent and setting BATFET_DIS bit when the device attempts to enter boost mode with the solar input connected. 

    To debug further are you able perform a test where boost mode is disabled via either OTG pin or OTG_CONFIG bit = 1 (REG03 bit 5) and see if you still get the error log message indicating BATFET has been set? 

    Regards,

    Garrett 

  • Based on your answers and the description of the typical load at SYS my theory is that the device is sometimes detecting battery discharge overcurrent and setting BATFET_DIS bit when the device attempts to enter boost mode with the solar input connected.

    So, the chip is erroneously detecting an overcurrent condition that is not actually occurring?  Again, there is no way to actually pull 8 amps on the load side of this design.  There isn't even inrush on the capacitors, because in this situation they are already charged.

    To debug further are you able perform a test where boost mode is disabled via either OTG pin or OTG_CONFIG bit = 1 (REG03 bit 5) and see if you still get the error log message indicating BATFET has been set?

    I can try this, but it will be a few days at least before I can as the current weather is overcast for the next several days.  However, even if this stops the BATFET disconnection, it won't work for my application: I need to run the boost output until the solar panel comes up.  There is no way I can reliably disable the boost output *before* sunlight hits the panel.  If I can't use the boost output, I would have to install a separate boost converter in the design, which defeats much of the reason to buy the BQ25895.

    As it stands, my best option so far is to bypass the BQ25895 for my critical MCU loads with a separate protection and power control circuit.  The BQ25895 can still run the boost load and charge the battery, and since it wouldn't be able to disconnect the MCU, the MCU can continually poll and manually reset BATFET_DIS when the BQ25895 glitches.  This would also completely eliminate the SYS glitching issue I also mentioned.

    That might be acceptable in my application, but from a cost standpoint that would probably be a problem for other customers.

    Does TI have more thorough test data with the BQ25895 on solar inputs?  All I have ever seen is the MPPT app note, which was clearly only tested in full sun and didn't go through a day/night cycle with marginal solar input at dusk and dawn.  Since the marketing copy clearly states the part is solar compatible, I would have expected to see much more characteristic data covering the full range of solar input conditions.  This information is clearly not in the datasheet and I have not been able to find any app notes - but *surely* TI did in fact perform extensive testing and characterization of the part before marketing it as such?

  • Hi Jeremy, 

    Apologies for the delay in response. Please see my comments below. 

    I have performed some testing on the BQ25895 and determined that a boost mode fault will also set BATFET_DIS = 1. Overloading the boost converter or an overvoltage of PMID will cause BATFET_DIS = 1. On the BQ25895 I tested a load of approximately 4A at PMID caused a boost fault. 

    I believe a boost fault ( indicated by REG0C bit 6) is a more likely cause of setting BATFET_DIS = 1 then the battery discharge current exceeding the overcurrent threshold. If possible can you check if the register log indicates a boost fault at the same time that BATFET_DIS is being set to 1 on its own? 

    Does TI have more thorough test data with the BQ25895 on solar inputs?

    The BQ25895 was originally designed for power bank applications. The VINDPM function on the device paired with a MCU running a MPPT algorithm allows the device to work in solar applications. Unfortunately, I do not have information on the extend of testing conducted for the MPPT application note. 

    Regards,

    Garrett 

  • Hi Garret,

    Apologies for the delay in response. Please see my comments below. 

    No worries, it's a tough one!

    I have performed some testing on the BQ25895 and determined that a boost mode fault will also set BATFET_DIS = 1. Overloading the boost converter or an overvoltage of PMID will cause BATFET_DIS = 1. On the BQ25895 I tested a load of approximately 4A at PMID caused a boost fault. 

    I believe a boost fault ( indicated by REG0C bit 6) is a more likely cause of setting BATFET_DIS = 1 then the battery discharge current exceeding the overcurrent threshold. If possible can you check if the register log indicates a boost fault at the same time that BATFET_DIS is being set to 1 on its own? 

    This sounds like a plausible theory.  The open circuit voltage on the solar panel is around 7V.  The boost mode overvoltage threshold (Votg_ovp) is 5.8-6.0V.  Since VBUS has a conductive path to PMID through the Q1 body diode, it makes sense that the BQ25895 would see that as an overvoltage in BOOST mode.  Also note that when I came across this issue, boost mode is enabled but I don't actually have a load connected to it.  The output current is almost nil.

    I will check for this (as well as trying it with boost mode disabled) as soon as I can - however the weather continues to refuse to cooperate.  The forecast is still overcast/rainy for the next week at least.

    While the boost mode overvoltage protection is documented in the datasheet, it does not indicate that BATFET_DIS would be set in this condition.  Is this a bug?  Or undocumented but technically correct behavior?  It doesn't make sense to turn off the BATFET since this is not a battery fault - it's really just that the presence of VBUS at all interferes with the boost converter.

    Additionally, boost mode should turn off automatically in any case when voltage is applied to VBUS and the charger attempts to start the charge cycle.  Since the VBUS input might be marginal and not actually have enough power available to charge, I can see this causing constant contention with boost mode, that you wouldn't expect to see on a wall plug application unless you have a hopelessly broken wall adapter (which you then just unplug and try another, so the issue gets fixed one way or the other and you don't have unpowered hardware sitting out that no one can get to). 

    One of the ways I originally tried to handle this was to set HIZ mode to disable the VBUS input entirely, then wait for a higher light level (I have a separate light sensor in the system), and then re-enable the charger after there is likely more solar power available.  The problem with that is that every time VBUS has a rising edge, the BQ25895 automatically disables HIZ mode and re-enables the charger.  There appears to be no way to override this behavior without an external FET to completely disconnect the panel.

    The BQ25895 was originally designed for power bank applications. The VINDPM function on the device paired with a MCU running a MPPT algorithm allows the device to work in solar applications. Unfortunately, I do not have information on the extend of testing conducted for the MPPT application note. 

    Yeah - and the MPPT algorithm works relatively well.  The problem is the chip gets glitchy with the kind of sustained marginal VBUS input conditions that are present on a twice daily basis with a solar input.  I don't think I could recommend the part *by itself* for a solar input - it really needs additional electronics to work around the issues.  I'm still working out what the optimal strategy for that would be (an MCU controlled FET on the solar VBUS connection is one possibility).  There are a number of unsolved forum posts with similar problems.  FWIW, the issues I've had are relatively easy to reproduce outside with a solar panel, but have proven to be extremely difficult/impossible to reproduce reliably in the lab.  Setting up the full array of test equipment to work on an outdoor test you can only do at dusk and dawn in appropriate weather conditions is quite a logistical challenge!  It's been a difficult issue to analyze.

    I have a couple of strategies I'm trying to decide between.  Clearly some additional electronics are needed - the BQ25895 just doesn't have the proper configuration available to do this on its own without glitching the power supply.  Options include:

    - Run a separate bypass circuit from the batteries with its own protection system and power control that the MCU has direct control over.  The BQ25895 just deals with charging the batteries and providing a 5V output when not charging, and cannot otherwise interfere with the MCU power.  This loses the QON system reset functionality though, which is definitely a nice to have, and it does require a decent amount of additional components to implement.  The MCU can override most of the buggy behavior and in any case can keep running the rest of the system.

    - Switch the solar panel power with a FET.  This sounds nice in theory - I can prevent the charger from continuously trying to charge on a doomed input condition in minimal sun.  I lose the ability to monitor the panel voltage via the BQ25895 when it is disconnected, so if I want that I need to add a separate analog input to the system.  I need a way to qualify the panel input before enabling it - either based on its open circuit voltage (if I add the components for it), or perhaps via the light level sensor I already have.  If boost mode is an issue, I can always make sure boost mode is turned off before enabling the panel connection.  This is probably fewer parts overall and it is really preferable to only have the one battery protection circuit (the BQ25895 itself) instead of two.


    I'm definitely open to other ideas as well.

  • Hi Jeremy, 

    I would not expect 7V at VBUS from the solar panel input to be the cause of a boost overvoltage fault. The device should detect the input at VBUS and exit boost mode. As you have mentioned behavior in real world operating conditions may vary some, but testing in lab I can never force a boost fault or BATFET_DIS = 1 by inserting, removing, or adjusting the input voltage source.  

    While the boost mode overvoltage protection is documented in the datasheet, it does not indicate that BATFET_DIS would be set in this condition.  Is this a bug?  Or undocumented but technically correct behavior?

    Let me revise a statement I made previously. I wrongly stated I observed an overvoltage at PMID cause BATFET_DIS be set to 1b. I have since realized I had a test setup issue. The device performs according to the datasheet when overvoltage occurs at PMID. Switching is stopped and the BOOST fault bit is set, but BATFET is not forced off. 

    I have double checked that an overload condition does cause BATFET_DIS = 1. I am working to confirm with internal resources if any operating conditions beyond what is mentioned in the datasheet are expected to cause BATFET_DIS to be set. 

    I will check for this (as well as trying it with boost mode disabled) as soon as I can

    Understood, please share any update in regards to confirming if a boost fault occurs or if disabling boost mode stops the undesired setting of BATFET_DIS bit when you have them to help continue debug. 

    In theory either proposed strategy makes sense. A separate bypass circuit will avoid the issue of not being able to clear the BATFET_DIS bit and assuming the issue is in fact related to entering/exiting boost mode an external FET to disconnect solar panel supply would work to avoid repeatedly entering and exiting boost mode operation. I agree with your statement that the 2nd option seems preferable as it requires less change from your current design and uses less parts.

    Finally I have a couple questions for you. What are the protections on your battery pack? Does it have over discharge current protection? Does it have low battery voltage threshold to prevent further discharging a dead battery?

    Regards,

    Garrett

  • Hi Jeremy, 

    Please see below for update on conditions where device will internally set BATFET_DIS bit on the BQ25895. 

    1)Thermal shutdown in boost mode 

    2)TSCOLD or TSHOT fault in boost mode

    3)Battery discharge overcurrent protection 

    4)Battery voltage falls below BATLOWV threshold (typ 2.8V falling threshold) in boost mode 

    You have previously mentioned you did not think the issue was related to the battery over discharge protection due to the light load of your system. Therefore, the root cause of your issue may be your battery voltage hitting the BATLOWV threshold while in boost mode operation. 

    Regards,

    Garrett