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.

BQ20Z655 R1 V0.03 RSOC and Capacity Bug

Other Parts Discussed in Thread: BQ20Z655-R1, BQ20Z65-R1

We recently migrated a stable BQ20Z65 design to the BQ20Z655 R1, made the appropriate changes to the GG file, and are disapointed by the results.

In particular, we are seeing major problems with the capacity updating and a tendency for the chipset to "lock up" on capacity reporting especially after deep discharges. We have seen this in many battery packs using several different chemistry files and even using different cells. This problem was not seen on the Z65 chip.

We are sitting on a large inventory of batteries and have customers waiting for them. Any help would be appreciated.

An example is shown below for a pack that was stable for about 20 cycles, then did a QMAX update, on the following cycle capacity instantly jumped from 0% to 99% when a charger was connected, then after 24 minutes it dropped to 0% (remaining capacity in mWhr also reports 0). Battery continued to charger as normal with RSOS, ASOC and remaining capacity all stuck stubbornly at 0, even after 12 hours!!!

  • Hi Steve,
    Can you please attach the senc file for the bq20z65 and bq20z655. I can check to see if anything there is causing an issue.
    Regards,
    Swami
  • I am using Chem 2059 (new cell) and therefore can't provide SENC's from two apples-to-apples packs at this time.

    The attached SENC is for a pack that has cycled several more times without EVER showing more than 0% capacity (even though the time to full and time to empty register is working fine). The capacity is just stuck at 0. After reading the SENC file the pack is soft-reset, and this causes it to start working again. This is a common thread with all the packs that we see in this situation. Doing a soft reset (0x41) recovers the pack for anywhere from one to dozens more cycles before the capacity gets locked up again.

    Note, change the .zip extension to .senc.

    BQ20Z655R1 0pct bug senc.zip

  • By the way, it is probably worth noting that I have been using the BQ series of battery monitoring chips for nearly 10 years...
  • Hi Steve,
    I will look at the srec file just to make sure that everything there looks ok. It may take a few days as I will be out from tomorrow till the end of next week. I will able to get back to you early the week after.
    Regards,
    Swami
  • NEW INFORMATION:

    After reading the SENC file the pack reset so started to read normal capacity again, but after a few cycles the reported capacity again became stuck at 0% (both RSOC and ASOC).

    However, I pushed the button on the battery pack itself and was surprised to see that the display appears to light up normally (5 LED's indicating the pack was fully charged... which was correct, even though the BQ Software was reading 0% for RSOC and ASOC). The LED settings are very plain, we have selected ASOC display and LED settings "11" (5-LED's using the default % thresholds).

    I have also noticed that the Time to Empty and Time to Full registers appear to be pretty accurate, correctly telling me how many minutes until the pack is full or empty as it is cycling.

    So this points even more strongly to a very odd bug since the LED display and the time registers shouldnt be able to display a different capacity than is being reported by the SMBus.

    I have reset the pack and changed the reporting from mWhr to mAhrs on the off chance that is where the problem is. Cycling continues.

  • Hello Steve,

    How are you cycling the battery? Are you leaving periods of relaxation between each charge and discharge or it is continuous cycling?

    Thanks

  • It doesn't matter, eventually the bug appears on 100% of the packs we have tested. We have tried with a little as 1 minute between cycles and as long as 3 days between cycles.
  • We have now narrowed the bug down considerably - It is related to the pack reporting mode!!!

    If Capacity is reported in mWhr (by setting the CAPM bit of Battery Status or INIT Battery Mode), then eventually the capacity reported will lock up.

    If Capacity is reported in mAhr (but clearing the CAPM bit) then capacity reported seems to be fine.

    We have now verified this on several batteries with 100% failure seen for CAPM set and 100% pass for CAPM cleared.

    Once capacity locks up, setting the bit to mWhr will instantly display 0% remaining, and clearing the bit will cause capacity to be displayed normally again. You can switch the bit back and forth and capacity will jump back and forth from 0% (locked) to "actual" capacity.

    This is NOT a bug fix, this is only a work around. We have equipment that uses the mWhr reporting mode, this mode only seems to be broken on the 655-R1 chip. It can take a few battery cycles before the capacity locks up. Doing a soft reset (0x41) will cause capacity to display normally in either mode (mWhr or mAhr), but eventually capacity will lock up again in mWhr mode.

    Hopefully this will help you locate and fix the bug.

    It also explains why no one else seems to have reported it as I think very few people use the mWhr reporting mode.

    I will attempt to post a video showing the capacity flipping back and forth...
  • A link to the video can be found here:
    dl.dropboxusercontent.com/.../2015-12-23 13.19.06_mpeg2video_001.mpg

    Note that after I reset the pack and tried the experiment again, I found that the percent reported capacity is different when CAPM bit is set. I would expect that if the software was working properly then the % capacity reported should stay the same regardless of the reporting value being in mWhr or mAhr.
  • Hellllloooooo. Anyone out there?

  • Hi Steve,
    I am able to duplicate your issue. Unfortunately I need some input from the firmware engineer who is only back next week. Let me check with him and get back to you.
    Regards,
    Swami
  • Any update on this issue?

    We are considering dumping the 655 and going back to the (soon to be obsolete) 65 chip.

  • Hi Steve,
    I went through the firmware with the firmware engineer earlier this week and the code branch for capacity reporting is common to both the ba20z65 and bq20z655, and it does not seem to have any issues. At this point I am certain that there is setting that I am missing that can fix this issue. I just need a little time to go through all the settings and find out which one it is.
    Regards,
    Swami
  • Hi Steve,
    Can you please attach your senc file as well?
    Thanks,
    Swami
  • As before, you have to take this file and rename the JPG to SENC since the TI website won't allow upload of SENC files (gives an error that the extension is not allowed).

  • Thanks Steve,
    Yes, forgot the rename part. I had modified the original without saving it.
    Swami
  • Hi Steve,
    I am finding that if I use the calculations in the FW, the RSOC does seem to be a bit different when using mAh and cWh. The difference is not large, but there is a difference. This is due to the fact that one is an Energy calculation and the other is a Charge calculation. Also the Energy calculation is a bit different in discharge vs. charge. From a theory point of view this makes sense, and it should not be a big issue since the difference between the mAh and cWh is minimal from the calculations I have done. Is it possible to send me a log file of all the SBS registers from the EVSW when the problem occurs. I would like to manually calculate the values of a few points on the log in mAh and cWh and see if there is numerical issue involved.
    Regards,
    Swami
  • I have attached two files inside the attached RAR file (since the TI website does not allow uploads of LOG or GG files)Dropbox.rar.

    The Log file was taken during cycling. You will see around the middle of the file that ASOC / RSOC lock at 0% even though other parameters such as time to full and time to empty still function. 

    The GG file was then saved from the battery after it was noticed that it had locked.

    If you have trouble seeing the files let me know. 

  • Hi Steve,

    I looked at the log file, and the I could not account for the abrupt change, without much change in the other values. I will go over with the firmware team tomorrow morning and update you.

    Regards,

    Swami

  • Per our call, please find attached a new zip file which contains:

    excel spreadsheet of a log file for a pack serial number 000F which we do several types of cycling on and switch back and forth from mWhr to mAhr and back to mWhr mode. Eventually the capacity locks at 0. What is really interesting is that the capacity did the jump from 100% to 0% with no other factors involved. It was sitting on my desk with no load and at around 6am it just jumped from full to empty.

    ALSO included:

    A SENC image taken before the cycling started.

    A SENC image taken after the cycling finished

    A gg file take after the cycling finished (and after SENC was read out, so pack had been soft reset by the SENC read process).

    Pack000F.zipHope these help!

  • Per your request:

    We will run two tests (this response is for the first test).

    Test#1 (4-Packs)

    On the “Gas Gauging” tab change the DSG Relax Time parameter to “1” and the CHG Relax Time parameter to “60”.

    Soft-reset packs then cycle them.

    Test#2 (4-Packs)

    Do the above changes AND:

    Change Load Select (the first parameter on that same tab) to “6”

    User Rate-mA to 3000

    User Rate-mW to 43200

    Soft-reset packs then cycle.

    Results of Test#1

    We took four battery packs and ran them down then recharged. Three out of Four packs experienced state-of-charge readout problems. Log files attached.

    The truly disturbing part is that the three errors were all different (but ulitmately tied to state of charge readings).

    Pack 0012: Pack capacity jumped from 0% to 100% instantly when charger was applied after a full discharge. 

    Pack 0010: Pack capacity locked-up at 0% when charger was applied after full discharge.

    Pack 001D: Pack capacity locked-up at 0% for half the recharge cycle then started to work, reaching only 46% at end of charge, capacity then corrected itself to 100% and seems to work OK again.

    Pack 0061: Pack readings seemed OK.relaxtimechange.zip

  • Hi Steve,

    Let me take a look at the latest log files as well as discuss it with the algorithm folks and give you an update later today.

    Regards,

    Swami

  • I have the same four packs running Test #2. Data is not available but I can already tell you that they are failing in the same way. All four packs started charging from 0% at the same time and the same current... so they should all be showing the same capacity. Right now their capacity reads: 0% 21% 49% and 99%.
  • I wanted to update you that we have now ABANDONED the BQ20Z655-R1 chip as a lost cause.

    We have changed our design back to the BQ20Z65-R1 and have seen NO PROBLEMS.

    Disappointed that resolution was never reached on this problem, especially when it is so easy to reproduce. We just don't have any more time to dedicate to trying to move to the newer chip.