STC3115 Not showing correct SoC after charging

Sami-Pekka Mähönen · ‎2017-09-12

Posted on September 12, 2017 at 12:02

Hello everyone,

We are having an issue with STC3115 (fuel gauge) where we are charging our device while it is powered off. After powering on the device, SoC received from STC3115 driver to application shows the same value as it was before

charging. Then it takes around 30 minutes or so SoC slowly update to the actual value.

Also to be noted that:

a) If the battery is re-attached, then SoC shows the correct value on first power on after charging

b) When the device is turned off (standby), our application sets fuel gauge to power saving mode

c) SoC is updated correctly when the device charged while being powered on

d) Our hardware does not support charging mode where the device could be woken from standby if the charger is connected

If anyone has faced similar problems or have any ideas how to solve this issue with SoC not updating if the device is charged while powered off, please let us know. We are also happy to give more details if needed.

#stc3115-issue-startup

Note: this post was migrated and contained many threaded conversations, some content may be missing.

Antish Antony · ‎2017-12-06

Posted on December 06, 2017 at 15:33

Hi Sami ,

We are also facing the same issue now. Did you get any solution for this ?

#stc3115%20issue%20startup

‌

Sami-Pekka Mähönen · ‎2017-12-07

Posted on December 07, 2017 at 09:05

Hey Antony,

We didn't find a solution for this issue. In future we're are going to implement charging mode where the charger wakes up the device and starts running the task while updating the gas gauge. Hopefully that fixes the issue.

Gregory Go. · ‎2017-12-07

Posted on December 08, 2017 at 00:48

Hello,

If you face an issue where the STC3115 doesn't provide the correct SoC value, it usually means there is a Device configuration issue.

Note that the STC3115 is monitoring the battery only when the supply voltage is higher than 2.7V .

If the battery voltage is below 2.7V, it doesn't matter because your application is not powered up yet, so it doesn't display any SoC value.

Also, Vmin for RAM content retention is 2.0V. So if the battery voltage went below 2V, the STC3115 lost all its previous configuration. And you need to reconfigure it again at the next startup.

To further analyze the issue, here are some questions:

- In your case, your system is powered off. Then you connect the battery charger, and it will power up the system.

What is doing your system to STC3115 device when it is powering up ?

Does it reconfigure the STC3115 every times at startup ?

Does it configure the device right away or after 30min (when the SoC is seen updated again) ?

A common issue in a multi-tasks RTOS environment is that the background battery monitoring task is started before the Gas gauge initialization sequence being run first. This could lead to unpredictable behavior.

- When the STC3115 doesn't provide the correct SoC, what is the SoC value shown ? Is it 0% ?

- When the STC3115 doesn't provide the correct SoC, does the device is at least running ?

You can check that by reading the 'REG_COUNTER' register (2 bytes), and verifying that it is continuously counting.

- When the STC3115 doesn't provide the correct SoC, does it provide a correct battery Voltage value ?

You can check that by reading the 'REG_VOLTAGE' register (2 bytes).

- Which software drivers do you use to manage STC3115 ? Is it a custom implementation ?

- Do you use an RTOS ?

Best regards.

Gregory Go. · ‎2017-12-07

Posted on December 08, 2017 at 02:25

Please see answer below.

It is more likely a system implementation issue.

Antish Antony · ‎2017-12-08

Posted on December 08, 2017 at 15:56

Hi Gregory,

Thank you for your response.

Our Battery is directly connected to STC3115. And the battery voltage always remains above 3.4V during power off state (Because we automatically turn off our application when it reaches 3.4V).
No RAM content is lost. And the SOC value shown at power ON is the previous SOC value saved into RAM before shutdown.
But by Removing and Re-inserting the battery, STC3115 provides the current SOC and voltage.
We are using a FreeRTOS environment and the driver we are using is the open source driver available in ST website.
On every boot up of our device, we use Gas gauge initialization sequence first, and then call the gas gauge task periodically every 5 secs.

For normal scenarios, we have not seen any issues with SOC. We face this issue only when we charge in offline mode and reboot our device (STC3115 doesnt get reset at this stage). After reboot , SOC shows previously saved SOC value in RAM, but we were expecting the SOC would show an increased value as charging was done.

( We confirmed that battery was actually charged by measuring the voltage of battery using multimeter before and after charging. Also, we re inserted the battery causing STC3115 to show the correct voltage and SOC. Without a battery re-insert , we were not able to read proper SOC value after offline charging )

Gregory Go. · ‎2017-12-08

Posted on December 08, 2017 at 23:34

Hi Antony,

2. No RAM content is lost. And the SOC value shown at power ON is the previous SOC value saved into RAM before shutdown.

This is the expected behavior, to restore the last known battery SoC value after a shutdown. This is done thanks to STC3115_Restore() function.

Then the SoC will slowly be adjusted to the newly measured value.

The restoration process is meant to improve the initial SoC accuracy after a system shutdown. Because the Voltage the gas gauge measures, while the battery is charging, is not the Open Circuit Voltage (OCV) but the charging voltage. And the SoC should be based on OCV.

During the restoration, the driver writes a value to REG_SOC register, which forces the Coulomb counter gas gauge algorithm to restart from this new SOC value.

If you don't want this restoration behavior, you can skip STC3115_Restore() function in the driver.

3. But by Removing and Re-inserting the battery, STC3115 provides the current SOC and voltage.

Removing the battery forces the Gas gauge to compute a new SoC based on the currently measured Voltage, without taking into account the restored value.

4. We are using a FreeRTOS environment and the driver we are using is the open source driver available in ST website.

There is an updated open-source driver on Github:

/external-link.jspa?url=https%3A%2F%2Fgithub.com%2Fst-sw%2FSTC3115GenericDriver%2Ftree%2Fmaster%2Fsrc

Not sure if it may improve your specific case. But it would worth to take a look at it.

5. On every boot up of our device, we use Gas gauge initialization sequence first, and then call the gas gauge task periodically every 5 secs.

Ok, this is the correct init implementation

Antish Antony · ‎2017-12-09

Posted on December 09, 2017 at 15:50

Hi Gregory,

OK. So what I understood is STC3115 wont update the SOC values during off-line charging (i.e when Application is switched off ).

It updates SOC/voltage only when the application is working.

Please correct if I understood it wrongly.

Gregory Go. · ‎2017-12-11

Posted on December 12, 2017 at 01:26

This is incorrect.

As long as the Gas gauge is powered on (ie Vcc > 2.7V) and GG_RUN bit == 1, the Gas gauge will continuously monitor the battery. So it will update the Voltage measured and compute the SoC, and keep the value within its internal registers.

So when the full Application starts up, the SoC information will be up-to-date.

It is just the final user who will need to wait that the application starts before being able to see the SoC provided by the Gas gauge.

Antish Antony · ‎2017-12-12

Posted on December 12, 2017 at 11:01

OK.

When we turn off our application , we were calling the Gasgauge Stop API. Internally in this API they are setting the GG_RUN bit = 0. I removed this code and put to test. Will update on the test result.