BQ27425-G2A: SOC not linear after writing golden image

Hi Felix,

Can you send me a log file of all parameters on the device when this unexpected discharging behavior occurs so I can get a deeper look into what might be causing it?

Thanks,

Jackson

Hello Jackson,

I'll send you a log file on monday. I haven't logged all parameters yet while this error occurs. So I have to to start a new discharge first.

Thank you for your quick response.

Felix

Hello Jackson,

this took some more time because to my surprise in the next discharge all out of three testet fuel gauges worked fine. You can see the linear SOC in the following picture. Also the SOC was set 0 at a lower voltage which results in a longer runtime. Blue graphs are fuel gauges with written golden image and orange/brown graphs are fuel gauges without my golden image.

Two of the praphs without golden image look exactly like the graphs from my last post. Maybe something went wrong with writing the golden image last time?

I did another discharge with the same sensors from the last picture. Before starting the discharge I disconnected the batteries. Then I reconnected them and fully charged all sensors. Here's the SOC-graph from the following discharge:

Now all sensors have the same nonlinear behaviour. But the sensors with written golden image still have a longer runtime because the fuel gauge sets the SOC = 0 % at a lower voltage then the sensors without written golden image. I read the registers of the golden image and noticed changes in register 52 (hex) offset 1 and register 56 (hex) offset 0. But these registers also had changed after the first discharge with linear SOC. The rest of the registers remained unchanged even after battery disconnect.

Here's the bqStudio log of one sensor with written golden image from the last picture. There are some missing values because of a shared I2C communication with our microcontroller.

FG5_bqStudio_Log.log

Here are my questions:

1. Is the battery disconnect the reason for the nonlinear behavior in the second picture?
2. If yes, how do I handle a power loss?
3. What is written in register 52 (hex) offset 1 and register 56 (hex) offset 0? In table 9 of the datashett SLUSB23B I don't se a register 82 (dec) offset 1 and register 86 (dec).
4. After what hardware changes do I have to repeat the learning cycle for a new golden image? Is this needed only when choosing a different battery or also when I get a new batch of same batteries? Do changes in our PCB also require a new golden image?
5. Also at charging all tested fuel gauges set the SOC to 100 % before charging is completed. Could there be a connection to the problem of nonlinear SOC at discharge or what could be other reasons?

Thanks for your help

Felix

Hello Jackson,

the aim of my last test (disconnect the battery and repeat the discharge) was to figure out if the fuel gauge keeps the written golden image after a power loss. As described I read all golden image registers on the fuel gauge before and after disconnecting the battery and only register 56(hex)/86(dec) offset 0 changed at all sensors. Register 52(hex)/82(dec) offset 1 changed at one sensor. All other registers remained unchanged. Even the Ra-tables in register 58(hex)/88(dec) still match with the golden image. Also the runtime showed a significant difference between sensors with and without previously written golden image.

Is register 56(hex)/86(dec) the only reason that the fuel gauge needs a new copy of the golden image after power loss? What information does this register contain?

Would be writing only this register instead of a full golden image sufficient? If the batterys impedance and capacity changes ofer its lifetime I excpect the Ra-tables and Qmax in the fuel gauge to adapt. So after a power loss keeping these learned values instead of writing the values of a new battery seems better to me. Also less memory is needed.

Thanks for your help

Felix

Hi Felix,

register 56(hex) stores the value for load select (Average I Last Run) which is used for calculating RemCap(), FCC(), and in turn FCC(). I am not sure why this is updating when you reset the device but it (in combination with your Ra table values) is definitely what is causing the issue. Can you send me your .gg file so I can take a look at your Ra table values?

Thanks,

Jackson

Hi Jackson,

as Felix isn't available at the moment, but we need to solve this urgent, I will take over here for now.

As I don't have the gg file at the moment here https://file.io/2VinjbMF1yxU is our GoldenImage file - should contain all data.

The picture below shows the Ra table (RAM) right after programming the GI.

What we currently do not understand is: When battery gets disconnected - the NV keeps nearly all the data but class 0x56 as described above - if we now rewrite only those changed bytes to the correct ones from GoldenImage - the full NV data now equals the GoldenImage data but the fuel gauge is acting like an unlearned device (non-linear as described above).

When we re-programm the full GoldenImage (actualy we rewrite the same data to NV wich is already there for 99% of the data) it seems the fuel gauge is working correctly - do you have any explanation for this behaviour? Does the gauge apply settings upon writing all the CRCs? Or is it maybe one special CRC making the fuel gauge applying its NV data?

As we currently can't fit the full GI file in our ROM we are searching for a solution which needs least amount of data to be re-written after battery disconnect.

regards

Frederik

Hi Jackson,

just noticed the file.io link isn't working - so here is another try: https://file.io/3h2AklrAEQG7

Maybe one other question: we were wondering if it matters which charging state the battery has when applying the GoldenImage?

So for a fresh / exchange battery SOC typicaly is 60%-80% when GoldenImage will be (re)written - while for a deep discharged battery where its cuttoff kicked in the GoldenImage will be reprogrammed below 0% - for production we thougth about writing GI at 100%.

Jackson DiGiovanna said:

For this device, upon battery removal, all settings will be restored to default values. This means that upon power loss, you will essentially lose the golden image programmed to the gauge. This is almost certainly the reason for the nonlinear behavior in the second picture.

Sorry to bother you with the 3rd post already - but according to https://www.ti.com/lit/an/slua652/slua652.pdf?ts=1659307279310 the NV arera persists a POR - and therefor it should persist a battery removal (as we noticed in our tests).

The GoldenImage classes are not fully documented as far as I know - so for us to know: Is a GoldeImage file NV data only or does it contain RAM data aswell?

If it is purely NV data: Why would we need to reprogramm at all? It seems I still don's see the full picture yet.

Hi Frederik,

have you tried subsequent chg/dsg cycles after the first one following a reset? It appears that Average I Last Run (what I believe to be this issue here) is in RAM and therefore resets on POR. However, I would think that Average I Last Run would be updated after one cycle and I would be interested to see if this solves the non-linearity of the SOC curve. In general, on a POR the device should reset to its GI settings. But I think that the value of Average I Last Run may be different from the current you are actually observing in your application. When you made the Golden Image, did you do a Field QMax Update at the discharge rate of your application? Again, I would like to see what happens on a second chg/dsg cycle and if that improves the linearity of SOC.

In terms of a battery exchange, I would recommend writing the GI at 100% to avoid confusing the gauge and being able to quickly update all Ra table values with the new cell.

Thanks,

Jackson

Hello Jackson,
indeed the Average I Last Run is updated after every discharge and varies between devices and cycles. We did two charge-discharge-cycles with three devices after a battery disconnect. During the first cycle all devices showed a nonlinear SOC. In the second cycle two of three devices again showed a nonlinear behaviour. The third device seemed fully learned with a linear SOC. We don't know what caused the difference between the devices because all three were handled the same. Unfortunately we only logged the SOC of the fuel gauges and no other parameters.
What exactly do you mean by doing a Field Qmax uptate when making the golden image? In the learning cycle we used a discharge rate of C/7.5. Our application has a rate of around C/6.7. Do we have to repeat the discharge with our application-discharge-rate?
Thanks for your help
Felix