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.

BQ27541-G1: Incorrect State of Charge after exit Hibernate Mode

Part Number: BQ27541-G1
Other Parts Discussed in Thread: BQEVSW

We have the BQ27541-G1 integrated into a battery pack. We have some packs being stored for more than 1 year without maintenance charge before customer use so they are fully depleted and have entered hibernate mode. After charging (reconditioning) our first read of the SoC is 0% even though the voltage is 4.15V, additional read attempts eventually give 100% SoC. The charger has no I2C communications only V+, GND and thermistor. I have several questions:

1) Is there an I2C command that will force a refresh of the SoC?

2) If no refresh command, how long should we wait after the initial I2C activity (which brings the fuel gauge out of Hibernate) before we have a valid SoC?

3) Any other suggestions on how to get valid SoC information from the fuel gauge upon exit from Hibernate?

  • Hi Perry,

    1) There's no I2C refresh command that will help in this case. You can send a rest command, but that's only available in unsealed mode which put you as risk of exposing your unseal keys and still may not resolve the issue.

    2) it's best to wait until the cell is charged to full to get accurate SOC reporting because it a defined state for the gauge that is try to figure out where the cell is at since it went into hibernate.

    The issue is on exiting hibernate the DOD0 the gauge determined upon exiting hibernate was inaccurate. Can you provide what DOD0 is being reported and the voltage and current as well upon exiting hibernate? Exiting hibernate with charge or communication? Most like it's charge.

    3) One parameter you can tweak is Max IR Correct. The fault is 400mV. Try lowering it to 200mV or 100mV to see if SOC reports more accurately upon exit of hibernate.
    - Take cell in hibernate for 1yr or more
    - Exit hibernate to check SOC reporting (then remove charger immediately)
    - if SOC inaccurate unseal gauge change Max IR correct then send command to force hibernate
    - Exit hibernate to check SOC reporting (then remove charger immediately)
    - if SOC inaccurate unseal gauge change Max IR correct then send command to force hibernate
    - Repeat until finding the Max IR correct value that reports the correct SOC upon exiting hibernate
    - Update packs with new Max IR correct value
  • Thank you Damian.

    1) ok, no refresh command

    2) I don't believe the BQ27541-G1 exits hibernate upon charge condition, only communication or Vcell < POR threshold.

    3) When we use the TI bqEVSW tool the SoC seems right each time, so I don't think I can perform the experiment you propose. I don't know what protocol the tool uses to get its readings. It is I2C but not sure about how it waits or retries commands. In our product we check the SoC upon boot up to ensure we have sufficient capacity to complete the boot process, but get a 0% SoC on the first read, upon a second insertion of the battery into the device we get a 100% SoC. This appears to me as a communication protocol issue but would like your confirmation of my understanding.

    According to the TRM section 3.1.4 Hibernate Mode "Once the gauge exits to NORMAL mode, the IT algorithm will take about 3 seconds to re-establish the correct battery capacity and measurements, regardless of the total charge drawn in HIBERNATE mode." I think we need to communicate with the gauge to transition to NORMAL state then wait at least 3 seconds to read the SoC, do agree with this assessment?

  • Hi Perry,

    From the TRM it doesn't appear to exit hibernate upon charge, but let me confirm that.

    Yes you need send a dummy I2C communication to the gauge to exit hibernate then wait 3 sec or more before reading SOC. bqEVSW refreshes every 4 sec or so and sends multiple commands to identify the gauge connected. I was under the impression that the SOC was wrong on multiple reads by the system after exiting hibernate mode, since that's not the case you don't have to perform the steps I proposed above. Just update your system code and verify the correct SOC is read after exiting hibernate. You can force hibernate mode using bqEVSW (ensure no I2C communication sent after hibernate command) then plug into your system to see if it reports the correct SOC.
  • Thanks Damian, I think that will fix our issue. We'll give our system code an update .