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.

Charge FET gets turned off by Battery chipset

We are having some of our products that suddenly won't take a charge after running for over three months.  Here are the details:

Battery pack with four Li-Ion cells in series, controlled by BQ29330 and BQ20Z90DBT-V110.

System containing battery pack is using a MAX1870 to control charge voltage to pack.

The battery pack is embedded and not easily disconnected.

We have had a bunch of these systems running for several months doing some testing.  Our software continuously monitors the battery state of charge.  When the state of charge gets down to 90%, we turn on the charger to charge it back up.  When it gets to 99% RSOC, we turn the charger off.  If, after three hours, the battery isn't charged up, we set an error.

We had 14 systems being tested, and for approximately1500 hours, this has worked fine.  During that time, there were around 33 of these discharge/charge cycles.  Then, suddenly, we find that the batteries won't charge anymore and our software is reporting that the charge FET is turned off in the battery.  I've attached one log file from the EV2300.  The first occurrence of the charge FET turning off occurs at sample 86689.  I have logs from other batteries as well if it will help.

There are more details in post #399394.

Any help that we can get on this will be greatly appreciated.

Thanks,  John.

0523.A0039.log

  • The CHG FET is turning off because you are getting a Fast Charge Mode Timeout.  The default value for this timer is 3 hours. This counter is cumulative, meaning that if there is no measured discharge current, the timeout counter will continue to increment as long as charge current is detected. What is likely happening is after around 30 cycles, the cumulative charge time is surpassing the FC-MTO timer and causing the FET to turn off. Given your application, it would be best to disable this charge timeout feature by writing the FC-MTO register to 0 in data flash. It is located in the Charge Control class.

  • Thanks for the reply.  I do have a question.  I assume that the chip designers put this counter in for a reason and I assume that our battery vendor enabled it for a reason.  What is the downside of disabling this timer?

    Thanks,

    John.

  • It looks like I'm having the same problem. I have a bq20z95 chipset integrated in a battery pack (NR=1). The FCMTO flag is set in the Charging Status and cascading up as TCA. However, I haven't been able to clear it using the prescribed method in sluu264a (section 2.4.10), Current <= (-)Dsg Current Threshold. I'm assuming this means the battery is discharged for a current greater than Dsg Current Threshold (100 mA). How long does this discharge need to last? Right now I'm forced to do a reset to clear this flag, which is not optimal.

     

     

  • The FCMTO flag should clear if discharge current is greater than the Dsg Current Threshold. Are you sure you don't have another safety flag set in conjunction with FCMTO? Do you have a log file showing this situation?

  • Unfortunately, I've cleared the battery that I've been debugging and disabled the Fast Mode Charger Timeout, but here is a log of another battery that appears to be exhibiting the same issue - A TCA flag with an FCMTO bit set. I disabled the charger and ran our device. The device pulled several good slugs of current out of the battery (50 ms/1A) and the FCMTO condition still exists.

    We disable charge on any TCA flag and we're trying to find some work around to clear the TCA for the field units we have w/o having to issue a software fix.

    On an unrelated note - these batteries are sealed from the OEM, yet the EV2300 unit we have is able to read SBS reads against "sealed" portion (ie. charging status, pf, safety, etc.) If we try to read those registers through our software, we get a failure - as expected from a sealed battery. How is the EV2300 able to read those registers?

    Thanks.

    -Ben

  • The current will need to be applied for a few seconds, at least. The gauge only takes current measurements once a second, so it's going to miss pulses that are 50ms. Simply keep the current applied until you see the flag go away. It shouldn't take long. The SBS.Current register just needs to be higher than the DSG Current Threshold.

     

    As for being able to read registers while sealed, that is actually an EVSW thing. If not using EVSW, you won't be able to read those extended SBS registers, as you have found out.