• State TI Thinks Resolved
  • Locked Locked
  • Replies 14 replies
  • Answers 4 answers
  • Subscribers 64 subscribers
  • Views 1088 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ27Z561: Unable to perform a successull learning cycle, Update status never changes from 0x4

Camren Spangler
Prodigy 140 points
Part Number: BQ27Z561
Other Parts Discussed in Thread: GPCCHEM, BQSTUDIO,

I have attempted to run a learning cycle for my battery fuel gauge several times.  I am following the process outlined in SLUA903 from July 2018 but the fuel gauge never changes the update status state from 0x4 and State of Health never changes from 81%.  I have a single cell LiPo battery and have already run gpcchem to determine a matchingHere is the process I followed:

Performed a characterization cycle to determine the correct battery chemistry ID as indicated by the GPCChem tool (I attached the output here).  Chemistry ID 2079 was the closest match that bqstudio displayed so that is the chemistry ID I programmed into the gauge using bqstudio.

Fullscreen 1351.GPC_report.txt Download 
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0	0	0
0		
		
Summary of all IDs with max. DOD deviation below 3%		
		
Chem ID	max DOD error, %	Max R deviation, ratio
2394	1.37	0.61
2642	1.62	0.28
2079	1.93	0.47
257	2.19	0.16
231	2.29	1.08
1653	2.3	0.62
1976	2.32	0.21
2636	2.33	0.27
2309	2.33	0.53
230	2.36	1
2302	2.41	0.23
2053	2.42	0.42
252	2.45	0.72
1340	2.45	0.52
221	2.46	0.24
1352	2.47	0.54
1314	2.5	0.3
253	2.5	0.56
1647	2.59	1.33
1741	2.6	0.55
297	2.61	0.79
1982	2.64	0.21
1991	2.68	0.61
2188	2.69	0.75
260	2.69	0.41
245	2.74	0.24
2082	2.74	0.73
2405	2.82	0.64
2568	2.83	0.36
2135	2.83	0.6
206	2.84	0.23
2089	2.84	0.51
1996	2.84	0.94
2520	2.92	0.52
295	2.95	0.56
1300	2.97	0.7
275	2.99	2.62
2051	2.99	1.81
269	2.99	0.37
		
Max. deviations for best ID is within recommended range. Chosen best chemical ID is suitable for programming the gauge.		
		
		
Selection of best generic ID for ROM based devices like bq274xx		
		
		
Device / Family #1		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
3142	bq27421-G1D: 4.4V LiCoO2	13.11
354	bq27411-G1C: 4.35V LiCoO2	16.19
128	bq27421-G1A: 4.2V LiCoO2	31.01
312	bq27421-G1B: 4.3V LiCoO2	43.68
Best generic ID 3142		
Warning: Deviation for best generic ID is above recommended level for this device / family. Consider using another device, flash based gauge or RAM programming of custom ID.		
		
		
Device / Family #2		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
1210	bq27621:  (ALT_CHEM1) 4.3V LiCoO2	15.11
1202	bq27621: (default) 4.2V LiCoO2	15.73
354	bq27621:  (ALT_CHEM2) 4.35V LiCoO2	16.19
Best generic ID 1210		
Warning: Generic ID Deviation is so high that it is most likely due to anomaly in the data. Please check that data files have recomended format, units and test schedule		
		
		
Device / Family #3		
Generic Chem ID	Device/ Voltage/ Chemistry	max DOD error, %
3142	bq27426: (ALT-CHEM2) 4.4V LiCoO2	13.11
3230	bq27426: (default) 4.35V LiCoO2	15.65
1202	bq27426: (ALT_CHEM1) 4.2V LiCoO2	15.73
Best generic ID 3142		
Warning: Deviation for best generic ID is above recommended level for this device / family. Consider using another device, flash based gauge or RAM programming of custom ID.

Calibrated the voltage and current for the gauge.  However, I saw that even with almost zero current draw on the battery (25-100uA as measured by an external DMM) the gauge still showed a discharge current of ~14-17mA in bqstudio.  I calibrated several times at different current levels but this value would not show zero current.  Eventually I increased the deadband current (but not the Coulomb Counter Deadband) to 15mA.

Performed a Learning cycle.  Log files and screen snapshots are attached below.  I divided the log files into their various steps to prevent them from getting too large.
1. Set the following flash parameters:
Advanced Charge Algo -> Low Temp -> Voltage = 4200
Advanced Charge Algo -> Standard Temp -> Voltage = 4200
Advanced Charge Algo -> High Temp -> Voltage = 4200
Advanced Charge Algo -> Rec Temp -> Voltage = 4200
Gas Gauging -> FC -> Set Voltage = 4200
Gas Gauging -> FC -> Clear Voltage = 4100
Gas Gauging -> TC -> Set Voltage = 4200
Gas Gauging -> TC -> Clear Voltage = 4100
Gas Gauging -> State -> Cell 1 Chg Voltage @EOC = 4190
Gas Gauging -> IT Cfg -> Term Voltage = 3000
Gas Gauging -> Design -> Design Voltage = 3700
Advanced Charge Algorithm -> Termination Config -> Charge Term Taper Current mA = 120
Gas Gauging -> Design -> Design Capacity mAh = 4800
Gas Gauging -> Design -> Design Capacity cWh = 1776
Gas Gauging -> State -> QMax Cell 1 mAh = 4800
Gas Gauging -> State -> Current at EOC = 120
Gas Gauging -> Current Thresholds -> Quit Current = 40
Gas Gauging -> Current Thresholds -> CHG Current Threshold = 75
Gas Gauging -> Current Thresholds -> Dsg Current Threshold = 60
2. Toggled gauge enable off then on again using the Gauge_EN button in bqstudio.
3. Send Reset command using the Reset button in bqstudio.
4. Discharged the battery to empty.
This process completed at 4:33PM on 3/19 (see line 99 in 1BatteryLearningDischargePlusRest.log).
5. Let it rest until "REST" bit was high and confirmed the RDIS bit was low.
This process completed at 8:43AM on 3/20 (line 4 in 2BatteryLearningChargePlusRest.log).
6. Charged the battery to full and verified the FC bit was high.
The system reached full charge as indicated by remaining capacity/full charge capacity equalling 100% at 12:53PM on 3/20 (line 3751 in 2BatteryLearningChargePlusRest.log). I took a snapshot of the bqstudio GUI ChargingReached100percentCapacity.PNG.
The system reached full charge as indicated by zero charge current and FC bit being high at 3:25 PM on 3/20 (line 6036 in 2BatteryLearningChargePlusRest.log).  I took a snapshot of the bqstudio GUI ChargingReachedZeroChargeCurrent.PNG
7. Let it rest until "REST" bit was high.
This process completed sometime before 5:23PM on 3/20.
I confirmed that the REST bit was high but VOK was low and the update status still showed 0x4.

I let it sit over the weekend with at most 25-100uA of current draw.  This process completed at 9:26AM on 3/23 (line 75 in 4BatteryLearningStartDischarge.log). I took a snapshot of the bqstudio GUI ExtendedRestAfterChargeComplete.PNG

Update status still did not indicate 0x5.
The battery voltage showed 4162mV.
The available capacity indicated 92%.
The state of Health still showed 81%.
8. Started discharge to empty using between C/5 and C10 rate.
When discharge is started the REST bit went low and VOK went high but update status still showed 0x4. This process started at 9:26AM on 3/23 (line 75 in 4BatteryLearningStartDischarge.log).

BatteryLearningFailure.zip

Why did the gauge never change update status from 0x4?

Why did the state of health never change from 81%?

Why did the available capacity never increase past 3972 even though significantly more energy was charged into the battery?

Thanks.

-Camren

  • 0
    TI__Guru 52115 points

    Your chemistry id seems okay. I will look into your log file and see if there is anything wrong. 

    Andy

  • 0 in reply to Andy Liu (BMS)
    TI__Guru 52115 points

    I have checked your log files.

    After the battery is discharged to empty and relaxed, you should be able to see the QMaxDOD0 is updated and its value should become around 16000. See the example below.

    However, I see that QMaxDOD0 was not updated correctly in the file 1BatteryLearningDischargePlusRest.log.

    You would need to run the learning cycle again.  I would suggest you use a bq27z561 EVM and also do a good calibration. 

  • 0 in reply to Andy Liu (BMS)
    Prodigy 140 points

    I will purchase an evaluation board and perform the learning cycle again, but can you tell me why the QMaxDOD0 was not updated?  I have spent several weeks trying to run multiple learning cycles with no success.  Each time there is no indication of why it fails.  Without knowing why it did not work I believe it may fail again and we will be in the same position 3 days from now.  Shouldn't we be able to figure out specifically why it is failing from the data I have provided?  Thanks.

    -Camren

  • 0 in reply to Camren Spangler
    TI__Guru 52115 points

    This 5-hour relaxation time allows for a valid OCV reading to be taken and stored for the Qmax update. The valid OCV reading occurs when the dV/dt of the battery is < 4 μV/s.  In your learning cycle, I believe this condition was met and therefore a valid OCV reading was not captured.  Try to have the battery relax for a longer time and also check the QMaxDOD0 in the log file.

    Andy

  • 0 in reply to Andy Liu (BMS)
    Prodigy 140 points

    What happens if the 'Passed Q' value during a charge cycle exceeds the QMax specified in the data flash?  Could this cause the device to abort the learning cycle or disregard the results of the charge cycle?

    Does the QMax value specified in the data flash have to be larger than the largest Passed Q ever expected?

  • 0 in reply to Camren Spangler
    TI__Guru 52115 points

    No.  I don't think the learning cycle will not abort when the passed charge is bigger than the QMax value. 

    The most important thing is that the battery should be charged to the max voltage specified by the cell manufacturer and discharged to the min voltage specified as well to ensure the 90% passed charge condition is met.

    Andy

     

  • 0 in reply to Andy Liu (BMS)
    Prodigy 140 points

    I have now completed a successful learning cycle using the evaluation board.  The update status was 0x6, the full charge capacity was correct, and I was able to verify that it correctly tracked the battery level through a charge and discharge cycle.

    After verifying it was working correctly on the evaluation board I exported the golden image files and programmed that configuration into my custom board.  However I immediately noted that the full charge capacity was not correct.  It correctly imported the QMax (~5214mAh), State of Health (96%), and data flash values.  But it set the full charge capacity to ~300mAh even though the evaluation baord was reporting a full charge capacity of 4757mAh when I exported the golden image files.

    I then charged the battery to full and saw that the gauge reported that the battery received greater than 4800mAh of energy during the charge cycle.  However, the full charge capacity did not update.  I then let the system rest over night for > 12 hours.  After 12 hours it updated the full charge capacity upwards only very slightly to 329mAh.

    I then discharged the battery with a light load (285mA).  After discharging for ~15 minutes at this rate the gauge reported that 73mAh of energy had been discharged from the battery but it still reported both the full charge and remaining capacity at 329mAh.  See attached image of bqstudio.

    I then increased the discharge to 1614mA. After discharging for an additional ~10 minutes at this rate the gauge reported that 151mAh of adittional energy had been discharged from the battery but it still reported both the full charge and remaining capacity at 329mAh.  See attached image of bqstudio.

    1. Why did the full charge capacity not import with the golden image file?  I thought the point of exporting and importing these files was so that I didn't have to do a learning cycle on every gauge.  Do I need to execute a command after programming the golden image for it to take effect?

    2. Why did the gauge report a full charge capacity of 329mAh when even a simple charge integration algorithm would indicate the battery has >4900mAh of energy stored in it?

    3. Why did the remaining capacity not change when I had discharged >224mAh of energy over a 25 minute period?

    Prior to using this fuel gauge I spent almost a month trying to make the bq27621 fuel gauge work and was told by TI support that I needed to switch to the bq27z561.  I have now spent over a month trying to make the bq27z561 fuel gauge work.  If TI isn't able to give me a simple set of instructions to follow that actually causes the fuel gauge to report the correct charge level I will have to switch to a more robust/reliable vendor.

  • 0 in reply to Camren Spangler
    TI__Guru 52115 points

    See my comments below.

     

    After verifying it was working correctly on the evaluation board I exported the golden image files and programmed that configuration into my custom board.  However I immediately noted that the full charge capacity was not correct.  It correctly imported the QMax (~5214mAh), State of Health (96%), and data flash values.  But it set the full charge capacity to ~300mAh even though the evaluation baord was reporting a full charge capacity of 4757mAh when I exported the golden image files.

     

    a) I would suggest you do a calibration on your own board and make sure the current, voltage and temperature readings are accurate.

    b) Make sure that NO load or charger is connected to the gauge or battery and have the battery relax for a few hours. Send a reset command to the gauge device in the bqStudio and check if the RSOC reading makes sense.

  • 0 in reply to Andy Liu (BMS)
    Prodigy 140 points

    I already did a calibration.

    In our system it is impossible to have zero load because the battery is permanently connected to the system.  However the load was <300uA when I let the system rest overnight.

    Can you please answer the questions I asked?

    1. Why did the full charge capacity not import with the golden image file?  I thought the point of exporting and importing these files was so that I didn't have to do a learning cycle on every gauge.  Do I need to execute a command after programming the golden image for it to take effect?

    2. Why did the gauge report a full charge capacity of 329mAh when even a simple charge integration algorithm would indicate the battery has >4900mAh of energy stored in it?

    3. Why did the remaining capacity not change when I had discharged >224mAh of energy over a 25 minute period?

  • 0 in reply to Camren Spangler
    TI__Mastermind 24870 points

    Hello Camren,

    1. You will need to make sure IT is enabled after you re-program the gauges.

    2. Can you attach your gg.csv file programmed into the gauge? You'll have to read the file out by blue-wiring over the I2C lines and bypassing the host.

    3. Please provide a gg.csv file

  • 0 in reply to Kang Kang
    Prodigy 140 points

    IT was enabled.CustomBoard_export.gg.csv

    Attached is the gg.csv file.

  • 0 in reply to Camren Spangler
    TI__Mastermind 24870 points

    Hello Camren,

    It looks like learning is successful.

    Can you perform this.

    Let the cell relax for 5 hours, send a reset command and then begin cycling. I believe you just have a bad initialization point.

  • 0 in reply to Kang Kang
    Prodigy 140 points

    That is the exact process I already followed and it didn't work.

    I have asked the following questions in three different posts but they have still been ignored by the TI suppport team.  Please answer the following questions directly.

    1. Why did the full charge capacity not import with the golden image file?

    2. Why did the gauge report a full charge capacity of 329mAh after charging the battery when even a simple charge integration algorithm would indicate the battery has >4900mAh of energy stored in it?  What event(s) cause the full charge capacity to update?

    3. Why did the remaining capacity not change when I had discharged >224mAh of energy over a 25 minute period?

    Is it possible to have a phone conversation so that I can better understand how the part works and what may cause it to report values that are inaccurate by an order of magnitude?

    -Camren

  • 0 in reply to Camren Spangler
    TI__Mastermind 24870 points

    Camren,

    I did read your question. Can you follow the 5 hour relaxation and provide a gg.csv file at the beginning of this test and provide a log file to us?

    We need a 5 hour rest so your gauge gets a proper DOD.

    Thanks!