BQ76930: Doesn't charge after having been discharged for 24h

Hi Franz,

If the device is going into Shutdown mode (which is the reason the button on the TS1 pin needs to be pressed), it is likely because the Shutdown voltage is being reached. See section 8.4 of the BQ78350-R1 Technical Reference manual for details on device Shutdown: http://www.ti.com/lit/pdf/sluubd3

The default value is 1750 mV (cell voltage) to trigger a voltage-based Shutdown. 

Best regards,

Matt

Hi Matt,

its me Ingmar the engineer who wrote Franz.

We set CUV to 2500 mV threshold and recovery to 3000 mV and thought device will go at this range in sleep mode and FETs will switch off and periodically the BQ wakes up in order to check charger has been attached. Problem: If the charger is attached (BQ24610) and battery is in shutdown mode we can’t even charge the battery. The reset button is on the BMS PCB and not accessible from outside of our device. Our device needs when its running 300 mA and in off state still ~ 2 – 3 mA from the accupack. Furthermore our device has a huge 6 – 7 A peak current at the beginning within 10 ms and if battery periodically switch on the FETs in sleep mode the cell will get exhausted after a while and during the current peak cell voltage will decrease to 1750 mv and chip will go in shutdown mode. Do you have any idea how to fix?

Ingmarti.gg.csv

Hi Ingmar,

Thanks for your more detailed explanation of the issue. It seems like there are a few things in combination causing issues. Fortunately, there are multiple settings that can be used to modify these behaviors.

First, the FET Options register can be used to control the FET behavior in different conditions (like Sleep mode). It looks like you have the CHG FET programmed to remain on during sleep in your settings which I think is the behavior you want.

If you believe the device is going into Shutdown by mistake (due to the peak current), you may want to adjust your Shutdown Time and PF Shutdown Time parameters. By default, these are set to 10 seconds. Voltage-based shutdown is designed to protect the battery in case of extreme over-discharge. If your application needs to come out of shutdown, there are some circuit level ways to boot the device discussed in this (http://www.ti.com/lit/pdf/slua769) app note.

A CUV protection will trigger the DSG FET to turn off, but not the CHG FET. 

I think your first step might be to try increasing the Shutdown Time parameters.

Hope this helps,

Matt

Hi Matt,

I am wondering why I measure still voltage @sleep mode coming from the battery pack. I measure 7.3 V which means battery is still serving power to our device which triggers to shutdown. Did you have an look on our schematic where could it come from?

Ingmar

Hi Ingmar,

I do not see the schematic attached - did you send it? I am a little confused - are you talking about sleep mode or Shutdown mode? Sleep mode is only a reduced power mode to save power while there is not a large current flow. Shutdown mode is actually turning the BQ78350 off, so no communication with the device should be possible in Shutdown mode. 

Matt

Hi Matt,

maybe I explain what we expect from the battery.

You totally right if device needs less then 10 mA of power then the pack should go into sleep mode and if CUV has reached the treshold the battery should switch off the discharge fet. Right?

However we still measure current into our device in sleep mode which means we still loosing power and at the end we reach the treshold for entering shotdown. When we measure volatage at sleep mode we see 4,6 V on the pack P+ P-  and if we measure between b+ b- we measure 12,9 V. Is this normal?

Hi Ingmar,

The current should be very low. CHG should pull down with 1M at R29 and 1M at R30, so the load at 12.9V should be around 4.3 uA.

Maybe there is discharge through SMBC and SMBD. Can you try removing ZD7, ZD8, R51, and R52 to see if the Shutdown issue goes away? When the FETs open, it cuts the GND connection between the host and the BQ78350.

Some application use high-side FETs (using the BQ76200 high-side FET driver) for this reason if they still need to communicate with the PACK when the FETs are open. Some applications use an isolation on the SMBus instead.

Regards,

Matt

Hello Matt,

How’re you doing?

I am involved with Mr Bott on this battery issue. Thank you for your feedback up to now and if I may provide you with additional information which may help?

The issue we have is the wake up button / boot switch (TS1 to cell) is not accessible when the battery is within the product. A charger should be the only way to take the pack out of shutdown. Since this is not possible, the pack has to avoid going into shutdown mode. The CUV level has been raised to 3000mV, CUV release to 3200, charger present to 2300mV and the shutdown time to 10s (it had been set to 1s previously). This now avoids the peak current spike at wake up, which was causing the voltage of at least one cell to hit the 1750mV level and trigger shutdown.

However, what I have found with testing is that even if the pack is not going into shutdown, just reaching CUV and the communication breaking (as seen on the EV2400). The charger / PSU is not able to restart the battery pack if it is left in CUV overnight. You can see that the PSU is supplying a current, but there is no communication and only when the boot switch on the battery is pressed, does starts communicating.

Is there any factors which could be causing this pack to not to be woken up fully with a charger / PSU?

Existing packs need to have the GG files updated to resolve this issue.

I will attach the GG file for you to see the settings. The CUV, CUVR, Shutdown time and charger present thresholds in the GG file are for the existing packs.

Thank you.

Zahid Shafi

Hello Mat,

I just logged on to see if there were any update since my post this morning to find my post still sitting there, but not posted. I may have forgotten to hit the REPLY button as I had copied and pasted. 

Can you see my post to add onto Ingmar's explanation? 

I believe there are two issues here:

1) hitting shutdown mode with a current spike and having to press the boot switch to wake up. This is most probably solved with raising the CUV, CUVR etc (as per my earlier post)

2) Leaving the pack in CUV, BQ78350R1 switches off AND if left for a few hours (overnight testing so far), the pack cannot be woken up with a charger / PSU - even though current can be seen being supplied. I charged this with 500mA.

It is issue 2) which needs solving as it mimics a pack left in the product in storage and reaching CUV due to a small current being drawn by the product. 

Thank you,

Zahid Shafi

Hi Zahid,

If the device is going into a state where the boot switch needs to be toggled to communicate, it means the device has gone into Shutdown which means the battery has drained to a very low level. There must be a current path that is pulling current from the battery when the FETs are opened. Can you try removing ZD7, ZD8, R51, and R52 to see if it eliminates the issue? 

If you lose communication because of the CUV, then connecting the battery to a charger should help to recover since the CHG FET should close once the cells are above the recovery threshold or charging is detected (there is a CUV_RECOV_CHG bit that determines this behavior). However, if the device reaches the Shutdown voltage, the BQ78350 is completely power off and only the Boot switch can cause the BQ769x0 to bring back power to the BQ78350.

Thanks,

Matt

Hi Matt,

Ingmar did remove the components you suggested, but still current is able to flow. The product is able to draw 3mA from the battery pack once it enters CUV. As there is no way of disconnecting the load, the battery eventually reaches the Shutdown level, as you also say.

With the action of CUV, the discharge FET should open, but it does not. The discharge FET should stay open until the CUVR threshold is reached and the  XDSG bit should indicate this like in the BQ40z50. Is there another setting which is stopping this?

Many thanks.

Zahid

Hi Zahid,

That is interesting. The DSG FET should definitely turn off with a CUV event. Some things to check:

• Verify the DSG FET is working.
• Verify the gauge is measuring the voltages changing and is reporting cell voltage measurements below the CUV threshold.
• Verify the gauge log shows the Safety ALERT and Safety Status change for CUV.
• Verify the gauge log shows the Operation Status CHG and/or DSG switching

Matt

Hi Matt,

The points you mentioned will be checked and reported back. 

I do not have my rig at hand, but I can say the following highlighted :

• Verify the DSG FET is working.
• Verify the gauge is measuring the voltages changing and is reporting cell voltage measurements below the CUV threshold. The communication breaks as soon as the CUV is reached. No logging is possible from this point until the battery is charged

• Verify the gauge log shows the Safety ALERT and Safety Status change for CUV. No comms after entering CUV, but you can see the CUV bit is on whilst the battery is between CUV and CUVR. The charger has to remain connected to the pack until CUVR is reached otherwise the comms breaks again.  
• Verify the gauge log shows the Operation Status CHG and/or DSG switching

Thank you.

Hi Zahid,

Since you lose communication when CUV occurs, I suspect the issue is the ground connection. When the FETs open, they will lost the ground connection between the host and the BQ78350 which is why you see the loss of communication. This can be solved by using an isolator on the SMBus or by using high-side FETs (there is a BQ76200 high-side FET driver that many applications use).

 Here are a couple links that explain the problem: https://e2e.ti.com/support/power-management/f/196/t/649992

https://e2e.ti.com/support/power-management/f/196/t/840799

 Here are some TI Designs that use the high-side driver:

http://www.ti.com/tool/TIDA-00792

http://www.ti.com/tool/TIDA-010030

Best regards,

Matt

Hi Matt,

Thank you for your comments. For new designs, we will surely look at the information you have provided as now we know what we are looking for, but as this is a design that is already in a product, we just wanted to put a fix using the firmware settings.

Does this means the discharge FET cannot be switched off with the hardware we have?

Thanks,

Zahid

Hi Zahid,

I don’t know what would prevent the discharge FET from opening. If the communications are referenced to PACK- there will be continued discharge through the comm protection circuit and/or the IC substrate. The charger can maintain a voltage and allow communication.

Matt