BQ27426: Battery does not charge, does not discharge, voltage drops, RM value rises

关于上述问题，请帮忙分析下，提供下解决方向，谢谢！

Regarding the above problem, please help analyze it and provide the direction to solve it! Thanks.

Hello Wang,

The voltage drop is minimal (10mV). Make sure that the battery is connected to the fuel gauge after it has been at rest for 5 hours and you will not see this issue. It looks like initial SOC was wrong as is being corrected.

Hello Shirish,

Thanks for you reply.

We retested as you described, with the battery left alone for 5 hours and then plugged into the unit.

The phenomenon is the same as the original problem. Almost 4 hours or so, the RM will increase by 1.

Key log:

Line 1672: [2023-07-07 09:38:41.049] RM changed from 291 to 292

Line 29121: [2023-07-07 13:33:51.155] RM changed from 292 to 293

Between line 1672 --> line 29121, there is no change in voltage (3868mv) and no change in current (0mA).

Please help again to analyze the cause and solution idea. Thanks!

电池单独静置5小时后，插入电池测试结果.txt

Hello Wang,

Have you verified that the battery chemistry is compatible with bq27426 and the correct chemistry profile has been set?

Hello Shirish,

The chem ID is provided by TI and is matched to the battery. The configuration data loaded into FuelgaugeIC contains the chem ID data.

Based on the chem data, we performed current and voltage calibration and re-gold learning on our device.

The battery information is as follows:

For configuration data loaded into the FuelgaugeIC, please see the attachment.

0418_New_Bat_FS_withChemID_0419.gm.zip

Hello Wang,

Only certain chemIDs work with bq27426.

The correct procedure is to use GPCCHEM tool to determine if there is a match to bq27426.

If someone from TI helped you determine the compatibility, then i would like to loop them in.

Hi Shirish,

This is FAE Jiaqi. The CHEM ID is #2389. Dominik had sent the certain GMFS file to customer. 

BR,

Jiaqi Wang

Can you help us understand which commands are used to get the following data in the log

Fuel_Soc

Calc_Soc:

Hello,

Fuel_Soc---> StateOfCharge()

Calc_Soc---> RemainingCapacity()/Battery Design capacity*100

Fuel_Rm---->RemainingCapacity()

Fuel_Fcc----> FullChargeCapacity()

Fuel_Volt----> Voltage()

Fuel_curr----> AverageCurrent()

Hello Wang,

Thank you. The log shows increase of StateOfCharge(). If you leave it for another 5 hours, then does StateOfCharge() still continue increasing by 1? I will assign this thread to Dominik since he has been involved before.

Hello Shirish,

再放置4小时以上，RM还是会增加。

Leave it for another 4 hours or more and the RM will still increase.

Thanks for your reply.

根据TRM描述，bit[SMOOTHEN]是默认开启的。FS文件中OpconfigB值是默认值0x0F，bit[SMOOTHEN]是开启的。

另外，根据我们的测试，电池长时间维持在静置状态，会间隔4个小时左右，RM就加1，呈线性。

According to the TRM description, bit[SMOOTHEN] is on by default. the OpconfigB value in the FS file is the default value 0x0F and bit[SMOOTHEN] is on.

Also, according to our test, the battery is maintained in a resting state for a long time, it will be about 4 hours interval, and the RM is added 1, linearly.

Dominik Hartl11 said:

So this is about just 1 mAh change in RM while current is 0?

Yes. Every 3-4 hour interval the RM increases by 1.

Hello Wang,

Dominik will reply when he is back in office

One of the reserved bits in OpConfigB (bit 3) controls if a temperature triggered simulation in relax allows updates to smoothed RM. Please set OpConfigB to 0x07 instead of 0x0F to prevent this effect.

Thanks for you reply.

Problem unresolved。

As per your suggestion, I changed the FS config file, ConfigB from 0x0F to 0x07.

After testing, the phenomenon is the same as before changing the configuration.In about 4 hours, the RM value will be increased by 1.

Attached is the test log.

Test conditions:

Batteries were left alone for more than 5 hours and then inserted for testing

Log description:

Added RemainingCapacityUnfiltered() register value printing, the log corresponds to the keyword "Fuel_UnFRm".

行 840: [Fri Jul 21 11:39:00 2023[BCM][Debug]Fuel_Volt:3881,Fuel_Curr:0,Fuel_RM:317,Fuel_UnFRm:317,Fuel_Fcc:862,Fuel_Soc:37,Calc_Soc:25,Ctrl:209C,Bub Ntc:27,Pcb Ntc:28

行 22401: [Fri Jul 21 15:33:01 2023[BCM][Debug]Fuel_Volt:3881,Fuel_Curr:0,Fuel_RM:318,Fuel_UnFRm:318,Fuel_Fcc:862,Fuel_Soc:37,Calc_Soc:25,Ctrl:2098,Bub Ntc:26,Pcb Ntc:30

ConfigB 0x07_RelaxTest.txt

Added 8hours test log。

RM value increased from 317mAh to 319mAh

ConfigB 0x07_RelaxTest_8hours.txt

Given that this is a log file from your system and not bqStudio, I can't say why this happens.

Maybe there's a temporary load current that your log file misses and which causes the gauge to update filtered RM? Your log file shows that unfiltered RM changes so the gauge so eventually filtered RM will also change. In won't change if it's truly in relax.

Please test this with the EVM and bqStudio and a guaranteed zero current (disconnect any load from the EVM).

Hello，

Following your tips, I performed a static test using a TIDemo board and bqstudio.

The test results are consistent with the phenomena of our device.

Attached is the test log and Fs file

0811_TIDemo.zip

This is due to a small current that the gauge won't report because it's below 1mA. The gauge does accumulate charges even if the current is below 1mA. You can see this in the passed charge column.

The smoothing code will adjust filtered RM based on this accumulated charge, hence it slowly adjusts upwards. You can issue the SMOOTH_SYNC command periodically in relax to re-adjust filtered RM to unfiltered RM.

Note that SOC is kept steady at 24% in the TIDemo log file so this looks correct.

Dominik Hartl11 said:

You can issue the SMOOTH_SYNC command periodically in relax to re-adjust filtered RM to unfiltered RM.

Please tell the procedure, thanks!

Dominik Hartl11 said:

Note that SOC is kept steady at 24% in the TIDemo log file so this looks correct.

In response to this issue, I continued to verify. It continued to hang for 6 days and the SOC went up to 29%. Attached is the log.

0817_TiDemo.zip

The procedure is for the host uC to send the SMOOTH_SYNC subcommand (see https://www.ti.com/lit/ug/sluubb0/sluubb0.pdf, 5.1.10) periodically (e.g. once an hour) during long standby.

This will fix the issue of slow creep due to accumulated charge measurement errors.