• State Resolved
  • Locked Locked
  • Replies 17 replies
  • Answers 5 answers
  • Subscribers 64 subscribers
  • Views 2463 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

BQ40Z60EVM-578: Charging does not recover after a CUV detection

TK82
Intellectual 725 points
Part Number: BQ40Z60EVM-578
Other Parts Discussed in Thread: BQSTUDIO, BQ40Z60

Hi,

Charging does not recover after a CUV detection.

However, sending a RESET (MAC 0x0041) restarts the charging back to normal.

Are there any settings for an automatic RESET/restart when AC Power is applied?

 

The log file(s) show the test scenario:

-      Running normally from battery (Sample 1 to 6)

-      Excessive load current (8Amp) & err.log (Sample 7 to 13)

-      AC Power applied (CUV) with no charging (sample 14 to 25)

 

The design is a 2S configuration so, final output is 3.7V * 2 = 7.4V

Charging does not start/recover when AC Power is applied with an under voltage battery stack (CUV). Measured wrt PGND

VC1             = 3.9V measured (bqStudio reads 3800mV)

VC2             = 2.8V measured (bqStudio reads 0V)

BAT pin 1     = 2.5V measured (bqStudio reads 2900mV)

Is there a minimum PACK Voltage setting for charging to start?

 

Note: Battery on VC2 has its own internal safety circuit that has opened (CUV) therefore looks like a voltage drop. The internal safety circuit on VC2 will recover if a voltage is applied, hence, this is our problem, the charger needs to apply a voltage to the stack for the battery on VC2 to recover).

 

Here are some Register Bits:

Battery Mode AM             = 1 (Alarm Mode)

 

Operation Status SS        = 1 (Safety Mode)

Operation Status SDV     = 1 (Shutdown triggered due to low pack voltage)

 

Charging Status PV         = 1 (Min cell voltage in Pre-charge Voltage region)

 

Safety Status CUVC        = 1 (Compensated Cell Under-Voltage Detected)

Safety Status CUV          = 1 (Cell Under-Voltage Detected)

 

I have also attached the src file:

bq40z60_v0_15_build_21_2S6P_R0.05b_CUV.src

 

A second EVM starts up automatically but the voltage at BAT (pin1) is slightly higher (2.8V). Both EVM’s have the code.

 

Thanks,

Tom

PS, the log shows a few temperatures at -273.2 when AC Power is applied (Sample14)… what does this mean? ERROR?

SafetyMode_PackUnderVoltage.rar

  • 0
    TI__Mastermind 42535 points
    Tom,

    Your thread has been assigned to me. Please expect an update by next Tuesday.
  • 0 in reply to Batt
    TI__Mastermind 42535 points
    Tom,

    My suggestion is that you have CUV set to a higher threshold than the trip threshold for your cell. The bq40z60 is supposed to handle all cell events by itself without any factors on the cell. When you do a reset, the protections are reset momentarily, which enable the closed FETs to provide the voltage needed by your pack to close and recover. If there's any way to disable that protection on your cell, please do so and let the bq40z60 handle it.

    The -273C is an error due to a partial register read prior to initialization by bqstudio.
  • 0 in reply to Batt
    Intellectual 725 points
    Hi Batt,

    Thanks for the clue… I understand what you are saying however, our battery pack safety circuit CUV is hardwired to 2800mV (measured 2713mV @ 96mS).

    The bq40z60 is set to 2900mV with a 2second Delay.

    What is the bq40z60 smallest time Delay?
    bqStudio implies the smallest Delay could be 1second??
    I believe the Delay needs to be 96mS or less for the bq40z60 to handle it.

    This sounds like a Load Line vs Time race condition…. unfortunately.


    Thanks,
    Tom
  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Tom,

    Either way the fw limits the register update to once per second. To meet your requirement you will have to increase the CUV threshold to near about 3V (2975mV) would be a good value. Then reduce the delay to 0s. What this means is that you will only be limited by the fw delay in reading the registers and it will wait only register refresh time(following adc update of the new voltage) to set CUV. This may take upto 1s. It is not possible to reduce the time any lower as we simply don't update the registers more than once per second.
  • 0 in reply to Batt
    Intellectual 725 points
    Hi Batt,

    We are looking for a work around for now….

    What would be the impact to send a RESET (0x0014) when our system detects a power up from AC?? Sending the RESET recovers the open battery for reasons indicated earlier ( protections are reset momentarily).

    Alternatively:
    Depressing the WakeUp button (SW2) does NOT recover the open battery when it is at full charge(??)
    Depressing the WakeUp button (SW2) recovers the open battery when it is at a lower charge level.

    Any thoughts how the WakeUp (S2) button works…?



    Thanks,
    Tom
  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Hi Tom,

    Now, I'm confused. How were you able to get the battery fully charged when one of the batteries is open because of dsg?

    The switch S2 just connects 2P(the high cell) across to VAC. That is used to wake the gauge up. If you are fully charged, XCHG would be set and therefore the chg fet would be open to prevent overcharging. Below charge terminate that fet would be closed. However, I don't think that can possibly have an effect on the 2P connection. It's just a parallel path to wake up the BMU when the system is not present. It shouldn't affect it either way. Are you using our evm or do you have a design of your own?
  • 0 in reply to Batt
    Intellectual 725 points

    Hi Batt,

    Sorry for the confusion but debugging from a distance is not always obvious to either of us.. maybe I can explain.

    Yesterday, when one of the batteries was open (CUV), I sent a RESET command (0x0041) from bqStudio to the EVM when AC was present. The RESET command provided enough voltage to close the battery and allowed the charger to start charging overnight to full charge.

    This is why I’m asking the impact of always sending a RESET command from our system when AC Powered (could this be a viable work around??). Will the RESET command affect gauging/charging/protection under normal conditions??

    We have 2 EMV’s with the same code on both but one powers up from CUV and recovers with no problem (?? momentarily reset, which enables the closed FETs to provide the voltage needed  to close and recover??).

    However, the 2nd EVM and our pre-production board do NOT recover when AC Power is applied...

    ?? I’m thinking there is some race condition between Q2 & Q3 at power up that allows just enough voltage through to close the open battery on the working EVM1?? (going to investigate this further now).

    Attached are some scope traces from last week on the working (EVM1) and the not working EVM2.

    (see attached, the issue is happening 2.2sec after ACP goes hi)

    Ch1 – ACP (pin 31)

    Ch2 – BAT (pin 1)

    Ch3 – CHG (pin 32)

    Ch4 – HiDrv (pin 27)

    Thanks for the S2 WakeUp explanation.

    Tom

    3630.NoCUV_RecoveryAtPowerUp.rar

  • 0 in reply to TK82
    Intellectual 725 points
    from the previous scope traces

    the issue is happening (WorkNot) 2.2sec after ACP goes hi on this file:
    Brick_EVM2_WorkNot_ACP_BAT_CHG_HiDrv.bmp

    These are Close ups zoomed in at the issue:
    Working:
    Brick_EVM1_WorkingClose_ACP_BAT_CHG_HiDrv.bmp

    WorkNot:
    Brick_EVM2_WorkNotClose_ACP_BAT_CHG_HiDrv.bmp

    T
  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Tom,

    I'm not seeing any attachments in your post.
  • 0 in reply to Batt
    Intellectual 725 points

    i was refering to files from the previous post (NoCUV_RecoveryAtPowerUp.rar)

    but here they are again ( i think the battery is recovering due to some leakage through the FETS and connot rely on it [CHG & DSG are both Low at this time].

     

    However, i'm still looking for a work around because the bq40z60 does not recover when used with our batteries (with their own internal safety circuits).

    Our internal safety circuits are reacting faster (in the mS range) while the bq40z60 reacts in the 'seconds' range.

    Is there a way to disable all protections?? and use only the gauging and charging?? (and we will use our battery internal safety circuits).

    Otherwise, the bq40z60 needs to send a short pulse of voltage to recover our internal safety circuits at RESET(??) or when powered from AC.

    (hope this make sense).

    Sending a PCHG FET Toggle  (0x001E) works under most conditions (medium charged batteries, i thought this was going to be the workaround) but, bqStudio hangs after sending FET_EN (0x0022) when the overload test condition is done with fully charged batteries.

    please help with some thoughts or workaround ideas....

    thanks,

    Tom

    2061.NoCUV_RecoveryAtPowerUp.rar 

  • 0 in reply to TK82
    Intellectual 725 points

    Hi,

    What would be the preferred timing sequence (2 second interval??) to send the following commands from our system to clear the CUV error due to our internal safety circuits in our batteries (2S configuration)?

    this sequence seems to provide a voltage to the batteries (close the internal safety circuit) and overcome the short circuit test that created the CUV condition. 

    RESET 0x0041

    FET_EN 0x0022  (Off)

    PCHG_FET_Toggle 0x001E   (On)

    PCHG_FET_Toggle  0x001E  (Off)

    FET_EN 0x0022  (On)

    T

  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Yes, Tom. 2s would be OK.
  • 0 in reply to Batt
    Intellectual 725 points

    Hi Batt,

     

    Q1: Can you please explain in detail what happens when the RESET command is sent (0x0041)? after a fault condition like CUV in our case?

     

    I’m asking because I see a delay of ~2.3seconds for the HiDrv signal to go active which in turn creates the VSYS voltage. The VSYS voltage is then used to create the Precharge voltage to bring the open battery pack out of the fault condition.

     

    Q2: how often are the following registers updated and made available for a system process on the SMBus? (once a second?)

     

    Manufacturer Access() 0x0057

    FET_EN                 [4]          FET Controlled by Firmware        1 = Enabled, 0 = Disabled

    PCHG_EN            [0]          PreCharge FET test                          1 = Enabled, 0 = Disabled

     

     

     

    Q3: What do you think of the following sequence to overcome our CUV fault condition?

     

    Send each command with a 3 second delay between each - Read Modify Write except RESET

    RESET                                    0x0041                  this is a pulse ~300mS -> 1Sec, measured

    FET_EN                                 0x0022                  Toggles/Disables FW control of CHG, DSG, PCH_FET

    PCHG_FET_Toggle           0x001E                  Toggles/Enables PCHG FET

    PCHG_FET_Toggle           0x001E                  Toggles/Disables PCHG FET

    FET_EN                                 0x0022                  Toggles/Enables FW control of CHG, DSG, PCH_FET

    RESET                                    0x0041                  Absolute/Relative State Of Charge are determined

     

     

    Thanks,

    Tom

  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Hi Tom,

    1. A reset command clears the dataRAM registers and the protection fault status registers. It essentially does a reload of gauging parameters from the dataflash. The only items preserved are the PFs. As far as timing goes, fw initialization time and the command delay time are typically the delays associated with the reset. However, any reset will also recalculate the DOD by running simulations, this can take up to two seconds depending on the number of cells and the number of iterations the gauge has to run for the DOD to converge depending on the OCV that is seen by the gauge.

    2. The registers are only updated once every second.

    3. That looks OK to me. This is for you to allow the voltage to be seen by the cell's internal protector so that it closes again, right?
  • 0 in reply to Batt
    Intellectual 725 points

    Hi Batt,

    thanks for the detail insight on the RESET conmmand, this really helps to understand this fully integrated/complicated device. Like always, integration is great when it works as expected... 

    Will the RESET obstruct or alter any of the previously Learned information in the Golden File?

    (i'm moving on to creating the Golden File next with reference to the attached pptx, maybe i should start a new thread(??))

    and Yes, the RESET sequence of commands are to allow the voltage to be seen by the cell's internal protector so that it closes again.

    Tom1346.Battery gauge system design overview-process, flow, tools and configuration.pptx

  • 0 in reply to TK82
    TI__Mastermind 42535 points
    Hi Tom,

    No, reset won't change anything that has been committed to the dataflash. Yes, it would be useful if you could please close this thread if your question has been answered and start another thread for that.