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.

BQ40Z50-R1: Chemical fuse blown without any PF log in the black box

Part Number: BQ40Z50-R1
Other Parts Discussed in Thread: BQ40Z50, BQSTUDIO

Hi,

We use the BQ40Z50-R1 with the BQ294702 secondary voltage protection IC in a 3S3P Li-Ion battery pack.The schematic is the same as the recommended one in paragraph 9.2 of the BQ40Z50 datasheet except we don't have any LEDs or push buttons.

Our customer has returned a battery which seems dead. Actually the voltage at the pack output is 0V and the battery do not charge when connected to a charger.

Connection to the battery with BqStudio shows that the FUSE bit of the Operation Status A register is set. The fuse pin is driven high (around 6.3V) and the "chemical" fuse is blown.

We concluded that the BQ40Z50 has detected a permanent fail and blown the fuse but when we check the data flash memory, all the black box and PF status data remain to their intitial value of zero and thus we are unable to determine which failure has caused the fuse to blow. We also see one COV safety event and one ASCD safety event in the lifetime but no overvoltage or overcurrent event in the black box or PF status.

You will find attached a screen capture of the BQ40Z50 registers and a data flash export.

We don't understand why the chemical fuse has blown without having any permanent fail log in the black box and/or in the PF status. Is it normal? Do you have any explanations?

Regards,

Stephane

Bat_No10_Log_Files.zip

  • your question will be answered in the next few days by me, kindly bear with me until then.
  • Yes, if your secondary protector has blown the fuse then you will not be able to detect it in the failure records. This is because you have the PF Fuse C bit 2LVL set to 0.
  • Hi,

    I'm not convinced the second level protector has blown the fuse because currently the 2nd level protector is not in tripped state while the Bq40z50 is in tripped state (Fuse bit in the Operation Status A register is set).

    You're right the 2LVL bit of Enabled PF C is set to 0. According to paragraph 3.20 of the TRM : "Setting Enabled PF C[2LVL] = 0 will not prevent the second level protector from triggering and blowing the fuse, setting [2LVL] = 0 will only prevent the gauge from detecting the fuse state."

    Therefore, if the gauge doesn't detect the fuse state it can not activate its own FUSE pin in response especially as the 2LVL bit of the PF Fuse C is also set to 0.

    What is puzzling me is the current state where the output of the 2nd level protector is low, the FUSE output of the bq40z50 is high with Operation Status register FUSE bit = 1 despite the 2LVL bit is set to 0 in both Enabled PF C and PF Fuse C. To me, it indicates that the bq40z50 is in permanent fail state with the Fuse pin active but without any indications or records of what led to this state.

  • Hi Stephane,

    Sorry, we can't be of more help because this is not a scenario that happens on the gauge. We will record all PFs as the firmware intercepts the data prior to stopping writes to df after taking action based on the enabled PFs. Furthermore you don't have any logs. Is your secondary a resettable protector? If so, that may also have happened.

  • Hi Batt,

    Thanks for answering.

    Our secondary protector is the Bq294702 thus it is resettable and currently its output pin is not active while the FUSE pin of the Bq40Z50 is active.

    Perhaps you're right about the scenario. The secondary protector has probably blown the fuse but this is not my concern. I'm not looking for causes that led to blow the fuse but for causes that place the Bq40Z50 into what seems a permanent fail state.

    As you can see on the attached screen capture of the registers, the Bq40Z50, to me, is in PF state (CHG and DSG FETs are open and FUSE pin is active) but there is no PF status active and despite the lifetimes and black box data recording are enabled there is no event logged (refer to the Data Flash export of my first post).

    My concern is to know in which state is the Bq40Z50 currently, PF or not ? If in PF state, caused by which event and what are the explanations I don't have any logs in the lifetimes and the black box ?

  • It is in a PF state. However, this is not indicated in the gauge df. However your Operation Status does show a fuse blow. My suggestion is to first clear PF and then reset the gauge. That should bring it back to a state where the FETs can close.
  • Hi Batt,

    I reset the gauge and as expected the FUSE bit has cleared and the FETs get closed but I don't understand why the gauge didn't saved any informations in PF Status, blackbox and lifetimes on entering PF state with the FUSE pin active. According to our settings, the only PF Status bits that cause the gauge to drive the FUSE pin are SOV, SUV, SOCD, SOCC and SOT. To me, those events should have been saved in PF status and blackbox.

    Also I made some tests with another board on power supplies to simulate transient overvoltages on a cell as we think it could be the cause of the blown fuse. The chemical fuse is replaced with a zero ohm resistor and the drain of the control FET is connected to +CELL with a 10 kohms resistor. One power supply is programmed to cause a voltage increase from 3.9V to 4.4V during approximately 2.5s every 7s. The others are set to 3.9V
    Our secondary protector voltage threshold is 4.35V with a trigger delay of 2.2s +/-1s. I have temporarily set the PF SOV threshold of the gauge to 4,5V well above the secondary protector threshold to be sure the gauge will not drive the FUSE pin. Our COV protection threshold is set to 4.24V with 1s delay.

    COV is a firmware based protection which seems to have some latency unlike the AFE based protections. The delay is always superior to the one set in the Flash parameter and different between several consecutive detections. What is the worst case latency on the firmware based protections (COV, OCD and OCC particularly) ?
    I think that depending on this latency the secondary protector could blow the fuse before the gauge opens the FETs on a COV event.

    I also noticed that despite the 2LVL bit of Enabled PF C is set to 0, when the secondary protector is active, the FUSE bit in the Operation Status A register is set and the FETs are open. I conclude that
    - The FUSE bit only indicates the level on the FUSE pin irrespective of the driving source and not the activation of the pin by the gauge itself as a result of a permanent failure. Can you confirm ?
    - A high level on the FUSE pin causes the gauge to open the FETs irrespective of the 2LVL bit of Enabled PF C which is set to 0. To me, the FETs opening is not caused by a firmware decision because setting 2LVL bit to 0 will prevent the gauge from detecting the fuse state. Perhaps it is a direct action from the AFE on the FETs? Could you give us more details on the interactions between FUSE pin state, 2LVL bit configuration, PF status and FETs opening ?

    Thanks for your support.
  • To answer your questions,

    1. Yes, fuse just indicates that the FUSE pin is high
    2. The fuse can be driven high by the 2nd level protector. The gauge has no knowledge of the second level protector acting unless you enable 2LVL in the settings. Once it's on, it can show you if the 2LVL protector has been tripped and record the failure state. For every other PF that's as a result of fw action, you will have a PF record. PFs not intercepted by fw will not be recorded.

    As is, the fw has process timers. In active mode the fw scans all registers once every second for compliance with safety and PF thresholds. Therefore if the register scan has happened a the nth second, register trip will happen only on the second scan at n+1+delta delay where delta delay is delays due to any fw process that has precedence. What this means is, even if you set PF delay to 0, you will have up to 2 seconds of delay in opening FETs etc.

    I reiterate, 2LVL is not a switch, you can't turn off second level protector action using fw. You can only choose to record 2LVL action depending on the FUSE pin state when it is set. Else you will not record that PF.
  • OK Batt. Thank you for your support.