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.

BQ27421-G1: Fuel Gauge resetting to default settings

Part Number: BQ27421-G1
Other Parts Discussed in Thread: BQ25895M

I am trying to use the BQ27421-G1 to monitor the battery's state of charge.The battery that we are using has a different design capacity, voltage and taper current, so we need to configure that after a system reset.  Below is the list of I2C reads and writes that I perform to complete that process which I logged in my code. 

I am having a couple problems occurring and I don't know if it related to the way that I am configuring the device, or the way we have implemented the IC in the design (we are also using a TI battery charger IC - BQ25895M), or a problem with the actual Fuel Gauge IC.

The first problem that I am having is that as I monitor the designCapacity using the 0x3C extended command, this command sometimes reports the default capacity of 1000 mAh instead of the 3000 mAh capacity that I have configured.  Some times this reports such only once and then return to the configured capacity.  Sometimes it gets stuck at the default.  If I go back and read the capacity out of the data block region, it is still configured at 3000 mAh.  It does this more frequently when I am connected to a charger.

The other problem that I am having is that the SoC seems to just switch between 0 and 100 - obviously if I reconfigure, it returns to 0 - but sometimes it just switches back and forth.  It seems to do it primarily when I am connect to the charger.

All this to say that I have yet to get a good cycle of seeing the SoC dwindle from 100 down to discharged and then after connecting a charger to see it walk back up to 100%

Here is the I2C traffic when I am configuring the IC - I have annotated it so I can keep track of which command do what.

// Unseal
wr 0x00 0x00 0x80
wr 0x00 0x00 0x80

// Send CONFIG_UPDATE
wr 0x00 0x13 0x00
rd 0x06 0x37 0x01

// Enable Block Data memory control
wr 0x61 0x00 0x00

// Access State Subclass
wr 0x3E 0x52 0x00
wr 0x3F 0x00 0x00

// Get the current checksum
rd 0x60 0xE8 0x00

// Get the data for State Subclass
rd 0x40 0x00 0x00 0x00 0x00 0x00 0x81 0x0E 0xE6
0x0E 0xA4 0x03 0xE8 0x0E 0x74 0x15 0xCC
0x0C 0x80 0x00 0xC8 0x00 0x32 0x00 0x14
0x03 0xE8 0x01 0x00 0x64 0x10 0x68 0x00
wr 0x61 0x00 0x00

wr 0x3E 0x52 0x00
wr 0x3F 0x00 0x00
// Write back modified data
wr 0x40 0x00 0x00 0x00 0x00 0x00 0x81 0x0E 0xE6
0x0E 0xA4 0x0B 0xB8 0x2B 0x5C 0x15 0xCC
0x0B 0x54 0x00 0xC8 0x00 0x32 0x00 0x14
0x03 0xE8 0x01 0x00 0xEA 0x10 0x68 0x00
wr 0x60 0xF2 0x00

// Check that the checksum is correct
wr 0x3E 0x52 0x00
wr 0x3F 0x00 0x00
rd 0x60 0xF2 0x00
wr 0x61 0x00 0x00

// Access Registers subclass
wr 0x3E 0x40 0x00
wr 0x3F 0x00 0x00
rd 0x60 0xA2 0x00
rd 0x40 0x00 0x00 0x0F 0x10 0x00 0x14 0x04 0x00
0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
wr 0x61 0x00 0x00
wr 0x3E 0x40 0x00
wr 0x3F 0x00 0x00
wr 0x40 0x05 0x00 0x0F 0x10 0x00 0x14 0x04 0x00
0x09 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
wr 0x60 0xBA 0x00

// Check that the checksum is correct
wr 0x3E 0x40 0x00
wr 0x3F 0x00 0x00
rd 0x60 0xBA 0x00

// Config Battery insert
wr 0x00 0x0C 0x00

// Perform SOFT RESET
wr 0x00 0x42 0x00
rd 0x06 0x17 0x01

// Seal the unit
wr 0x00 0x20 0x00

  • Hello Steve,

    Check possibility of power loss/glitch in supply to the gauge.

    Monitor the ITPOR bit in Flags (section 4.4 in TRM ) to know if the gauge thinks there was a power reset.

    Regards

  • After checking for ITPOR, it took longer, but eventually the return from 0x3E (designCapacity) reports the default of 1000 mAh and it never sets ITPOR.

    Additionally, the SoC is very erratic - it will jump from 100 to 0 to 100 and then suddently set itself to some value in between and count up or down from there (depending on whether we are charging or discharging at the time).

  • Hello Steve,

    I would recommend checking if the chemistry of this cell is a good match to the gauge application and check all settings since SOC is erratic.

    For example check Load mode (Reference section 6.4.2.3.6) setting

    If you are using bq27421-G1B, your battery curves should match CHEM_ID 0x0312

    Regards

  • I have checked the chemid. This IC part was chosen by our battery supplier based on the battery cell's chem_id. 

    The biggest problem is that the IC seems to forget it's design capacity and then the SOC declines at a must higher rate that I would expect based on the average current measurement.  I monitor the design capacity reported via register 0x3C, and I can see it change from 3000 (which is what I program it to) to 1000 (the default capacity).  I am also monitoring for ITPOR and I never see it set.  After 5 hours of running the device with between 100 and 120 mA of discharge, I am seeing 64% SOC and I would expect to see something closer to 85-90%.

    I am afraid that if I reprogram the design capacity, it will clear all of the learning that has been done.  Is there a way to update it "on-the-fly" without reseting the SOC calculator?

  • I am wondering if you are seeing Watchdog Reset

    Here is the thread with similar issue https://e2e.ti.com/support/power-management/f/196/t/310543

  • Thanks.  Let me examine the timing of my communication with the IC.  I will let you know.

  • I checked the timing and it still isn't working.  I added 1 msec delays between reading different registers.  I am currently reading voltage, current, temperature, state of charge, state of health, design capacity, remaning capacity, full charge capacity and flags every second.  As I said, I am also inserting 1 msec delays between each reading.  In addition to this, when I read the flags, I am checking ITPOR to see if a reset occurred and I have never seen that bit get set.  Despite this, after some period of time - usually when charging - the reading of design capacity goes to 1000 (the default).  If I cannot figure this out soon, I am going to need to change the IC to something more predictable.

    As my code is running, I am collecting data about the charger and fuel gauge.  The data below contains the following parameters:

    time_in_msec,

    BQ25895M_VBUS,

    BQ25895M_VBAT,

    BQ25895M_VSYS,

    BQ25895M_CHG_CURR, 

    BQ25895M_STATE, 

    BQ25895M_FAULT,

    BQ27421_des_cap, 

    BQ27421_voltage, 

    BQ27421_current, 

    BQ27421_SOC, 

    BQ27421_flags,

    CHRG/DISC

    You can see in the data below that at time 3765001, the BQ27421's design capacity goes from 3000 to the default of 1000:

    00> 03757001,12300,4204,4204,1100,2,0,3000,4347,0300,100,0x0000,CHRG
    00> 03758001,12300,4204,4204,1100,2,0,3000,4348,0300,100,0x0000,CHRG
    00> 03759001,12300,4204,4204,1100,2,0,3000,4348,0300,100,0x0000,CHRG
    00> 03760001,12300,4204,4204,1100,2,0,3000,4348,0300,100,0x0000,CHRG
    00> 03761001,12300,4204,4204,1100,2,0,3000,4347,0299,100,0x0000,CHRG
    00> 03762001,12300,4204,4204,1100,2,0,3000,4347,0300,100,0x0000,CHRG
    00> 03763001,12300,4204,4204,1100,2,0,3000,4348,0300,100,0x0000,CHRG
    00> 03764001,12300,4204,4204,1100,2,0,3000,4347,0300,100,0x0000,CHRG
    00> 03765001,12300,4204,4204,1100,2,0,1000,3600,0000,000,0x0000,DISC
    00> 03766001,12300,4204,4204,1100,2,0,1000,4348,0299,000,0x0000,CHRG
    00> 03767001,12300,4204,4204,1100,2,0,1000,4348,0299,100,0x0000,CHRG
    00> 03768001,12300,4204,4204,1100,2,0,1000,4347,0299,100,0x0000,CHRG
    00> 03769001,12300,4204,4204,1100,2,0,1000,4348,0298,100,0x0000,CHRG
    00> 03770001,12300,4204,4204,1100,2,0,1000,4348,0299,100,0x0000,CHRG
    00> 03771001,12300,4204,4204,1100,2,0,1000,4348,0298,100,0x0000,CHRG
    00> 03772001,12300,4204,4204,1100,2,0,1000,4348,0299,100,0x0000,CHRG
    00> 03773001,12300,4204,4204,1100,2,0,1000,4347,0297,100,0x0000,CHRG
    00> 03774001,12300,4204,4204,1100,2,0,1000,4348,0298,100,0x0000,CHRG
    00> 03775001,12300,4204,4204,1100,2,0,1000,4347,0298,100,0x0000,CHRG
    00> 03776001,12300,4204,4204,1100,2,0,1000,4348,0297,100,0x0000,CHRG
    00> 03777001,12300,4204,4204,1100,2,0,1000,4348,0298,100,0x0000,CHRG
    00> 03778001,12300,4204,4204,1100,2,0,1000,4348,0297,100,0x0000,CHRG
    00> 03779001,12300,4204,4204,1100,2,0,1000,4348,0297,100,0x0000,CHRG
    00> 03780001,12300,4204,4204,1100,2,0,1000,4348,0297,100,0x0000,CHRG
    00> 03781001,12300,4204,4204,1100,2,0,1000,4347,0296,100,0x0000,CHRG
    00> 03782001,12300,4204,4204,1100,2,0,1000,4348,0296,100,0x0000,CHRG
    00> 03783001,12300,4204,4204,1100,2,0,1000,4347,0298,100,0x0000,CHRG
    00> 03784001,12300,4204,4204,1100,2,0,1000,4347,0295,100,0x0000,CHRG

  • Hello Steve,

    00> 03765001,12300,4204,4204,1100,2,0,1000,3600,0000,000,0x0000,DISC

    The voltage seems to drop suddenly from 4347 to 3600, it is discharging instead of charging, and SOC goes to 0. There is more happening than just design capacity being reset to original.

    You may want to log Control status and check if the WDRESET bit is being set.

    On the bq27421-G1B datasheet, page 13:

    8.5.4.3 I2C CommandWaitingTime

    "For read-write standard command, a minimum of 2 seconds is required to get the result updated. For read-only standard commands, there is no waiting time required, but the host must not issue any standard command more than two times per second. Otherwise, the gauge could result in a reset issue due to the expiration of the watchdog timer."

    Regards,

  • I think that the reading of 3600 mV is an artifact of the fuel gauge restarting, but I will check the value against that measured by the battery charger IC (BQ25895M) which also monitors the battery voltage.  

    With respect to the timing, I am reading several registers in a row with 1 millisecond delay between requests.  This update is done once every second.  This compiles with statement you mention, right?

  • "the host must not issue any standard command more than two times per second" seems to imply that a max of 2 commands can be sent per second.

    I would recommend that you add 500+ms between subsequent commands to bq27421 and see if the problem goes away.

  • I assumed that the 500 msec delay was just between a request for the SAME register.  I find it hard to believe that a sophisticated IC like this can't communication a full set of information within one second of time.

    I will try that though and see if it makes a difference.

  • Can you help me with hardware related issues as well if it turns out there is a dip in the battery voltage?  If that is happening, it is probably coming from the battery charger IC as it is switching from being connected to the changer and being connected to the battery instead.  We are using the BQ25895M.  What size capacitors should there be between the fuel guage/battery and the battery charger IC?  It could be that the sudden demand of current from the battery as the charger is disconnected is causing a large enough dip in the battery voltage to reset the fuel gauge.  Right now, we have two 4.7 uF capacitors between the two ICs and a 1 uF between the fuel gauge and the battery.

  • Hi Steve,

    I recommend that you start a "related" thread for bq25895M and ask the charger question there.

    Regards