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.

BQ27421EVM-G1A: SoC randomly became wrong on some PCBs after being configured correctly.

Part Number: BQ27421EVM-G1A
Other Parts Discussed in Thread: BQ25895, EV2400, BQSTUDIO, BQ2589
Hello,

We are in mass production and we hit an issue that SoC is randomly wrong on some pieces.

Phenomenon:
  • Randomly on some boards, the SoC was wrong like:
    • 78% but vBatt is constant at 4.2V and the charger (BQ25895) indicated charge done.
    • The rolling sum of iBatt = 16mAh but it jumps from 0 - 16%.
    • BQ25895 went to shipmode at 35% but when we turn on, SoC reported 5% only.
      We charged this and we found the rolling sum is 2200mAh (total caps of the battery is 3400mAh)
  • The above symptoms happened in the factory. We did SoC accuracy tests on our side
    and it was good with the same FW. However, we randomly managed to reproduce the issue in
    R&D team by letting the battery discharge for 2 nights then turn it on by plugging 5V charger to BQ25895.
  • In R&D team, we found that when the SoC is wrong, the configurations are wrong too, all was back to
  • default values although we configured it when we boot up and check if ITPOR is set. The configuration
  • is confirmed by reading bqStudio and EV2400 probed on our custom board.

Questions:
  • * Do you think this could be something wrong in SMT process?
  • * We assume that the power of BQ27421 may be unstable when the battery is too low, it could be like up - down cycles many times.
    If this happens, should we rely solely on ITPOR to re-configure the gauge or we should check the whole configured classes?

Background:
  • Gauge: BQ27421
  • Charger: BQ2589 (Input 5V, 3A)
  • PCB: custom

  • Battery: 3.7V 3400mAh
  • Software flow:
    • Boot up
    • Configure BQ25895
    • Check BQ27421::ITPOR
    • If ITPOR is set -> Configure BQ27421
    • Stay in standby mode or continue into application.
  • Burn-in test:
    • Charge at 1.8A for 2 
    • Discharge for 2 hours at 
    • Charge at 1.8A for 2 
    • Discharge for 4 hours (expected to have 
    • Charge at 1.8A for 40 mins

Thank you.
Best regards,

Luck
  • The gauge will only copy the default values if it is reset (power on reset or watchdog reset or RESET command). The ITPOR bit will be set, if it was reset like this. When you say that you configured it when you booted the system (if ITPOR was set at this time), does that mean that you check the ITPOR bit just at this time? What was the state of ITPOR when you noticed (later) that the values were default?

    Something caused a gauge reset, if the configuration reverted to the default values after you configured the gauge.

  • Hi,

    In our application, we do check ITPOR only at boot time

    boot();

    if (ITPOR_is_set())

    {

        configure_gauge();

    }

    while (button_is_pressed() == false)

        stay_standby()

    }

    run_app();

    We ran 11 tests more today in our lab and in the factory, in those tests, we printed all the values that we set in DM (data memory) every second that we set:

    SAFETY_over_temp
    SAFETY_under_temp
    STATE_design_capacity
    STATE_design_energy
    STATE_terminate_voltage
    STATE_taper_rate
    STATE_taper_voltage
    REGISTERS_opconfig
    In all 11 tests, the DM values were intact. Those values were not modified during the tests, but the SoC was still wrong (For example 87% when charger BQ25895 reports charge done). Replugging the battery to re-configure the gauge solved it, SoC went to 100% after re-configuring the gauge.
    Besides, we found the reason DM was reset to default is that we plugged EV2400 and the I2C wires are soldered as a probe on board.
    In summary:
    * There was no DM modified issue.
    * The SoC is sometimes right, sometimes wrong with the same DM values.
    We have a few questions:
    * You told me in another post that "No. SLUA595 doesn’t apply to the bq27421." But my team keeps wondering why the document is written for BQ274xx but it's not applied to BQ27421. Could you please elaborate on why this document is not applied to BQ27421-G1A?
    * Could you please suggest some directions what we should do next?
    Thank you.
    Best regards,
    Luck
  • SLUA595 was written for gauges with persistent flash memory, which the bq27421 doesn't have.

    Please follow the instructions from https://www.ti.com/lit/ml/sluuah7b/sluuah7b.pdf

    Pay close attention to taper rate and make sure that your system configures the gauge to reliably detect a full charge (that's why taper rate is super important).

    In general, the gauge must not be reset or power cycled unless absolutely necessary. The algorithm depends on adaptation and every time you reset the gauge you interfere with this process. The reason why you get 100% (or different values than before) when you configure the gauge (followed by a soft reset) is that the gauge will restart the gauging algorithm and it will calculate results based on typically non-ideal point measurements that will always introduce an error.

    The key feedback from you is that the gauge reports only 87% when the charger stops. This means that the gauge has no clue what the full charge reference point is and that infers that you didn't configure taper rate correctly.