BQ40Z50-R2: Bricked pack during compound CUV and CHGC faults

Hi Jeff,

I think the only other workaround would be to extend the CHGC: Delay to a long enough period to allow the change in charge to be allowed. Regarding the unseal, I believe that going through an unseal in the field could be a security risk, while also opening the door to data flash values being accidentally changed by the host. This is why we do not recommend doing this in the field.

Regards,

Anthony

Hi Anthony—thanks again for your support on this topic; I very much appreciate your guidance and patience. I had a similar concern about unsealing the pack in the field—thank you for sharing your feedback; I am aligned with you.

I studied this issue some more, but it seems it is not possible for our design to trigger an OCC fault under normal circumstances anyway. Our OCC1 and OCC2 thresholds are set to 6500 and 8000 mA, respectively; however, the maximum charging current of our charger IC (BQ25798) is only 5000 mA. There would have to be some major hardware problem for an OCC fault to occur, and the corner case described here would be irrelevant.

Similarly, it is not possible for our design to trigger a PCHGC fault either. Our precharge start voltage is set to 2500 mV; however, the BQ25798 has its own precharge start voltage near 3000 mV as configured in our design. As such, the BQ25798 automatically reduces the precharge current below the PCHG threshold with plenty of margin, and does not rely on our host SW to react in time.

Therefore, there is no practical chance of OCC or PCHGC faults; the only concern is a possible CHGC fault. I agree that it is pertinent to set the CHGC delay longer than our host SW reaction time; however, we should assume the latter is infinite in case our host SW fails.

I think a compromise we can make here is to use a positive CHGC recovery threshold as we discussed before, but set the CHGC recovery delay to something much higher (e.g. 60 seconds). This way, the gauge can recover from a compound CUV and CHGC fault; however, the retry period is much longer, and the cells are not repeatedly faced with excessive charging current as rapidly. In case you have any concerns, please let me know.

My last question for now is to understand what is the expected behavior if both OCC and CHGC faults occur simultaneously? Does the gauge wait for both faults' recovery criteria to be met, or does one fault take priority over another?

In our design, the OCC1 and CHGC (RT) thresholds are the same (6500 mA), but the delays are 6 and 3 seconds, respectively. If our charger IC did somehow drive over 6500 mA into the cells, the CHGC fault would occur first; it's therefore impossible for an OCC fault to occur according to our configuration. In case I have misunderstood, please let me know.

Hi Anthony—one additional question; I noticed this statement on page 40 of the TRM:

The bq40z50-R2 device goes through a full reset when exiting from SHUTDOWN mode, which means the device will reinitialize.

I see the ShutdownMode command (0x0010) is available while the pack is sealed. As an alternative workaround, can our host SW simply send this command to shut down the gauge during prolonged periods of DSG = CHG = 0? After the customer removes and inserts the charger, it seems the gauge would reset as if we had sent the DeviceReset command (0x0041).

I tested this hypothesis by decreasing VC1–4 below the CUV threshold such that the gauge signaled a CUV fault, then sent the ShutdownMode command. While the gauge remained in shutdown mode, I increased VC1–4 above the CUV threshold, but below the CUV recovery threshold. For the purpose of this experiment, I set the CUV recovery threshold unrealistically high.

I then very briefly applied a voltage higher than the charger present threshold, but below the CUV recovery threshold. The gauge powered back up as expected, and the CUV fault was cleared.

This suggests that the ShutdownMode command followed by a charger unplug/plug cycle can clear faults in the same way as the DeviceReset command. Can you confirm whether this is correct, and whether it can be a viable SW workaround to this chicken-and-egg problem?

Hi Jeff,

Jeff LaBundy said:

I think a compromise we can make here is to use a positive CHGC recovery threshold as we discussed before, but set the CHGC recovery delay to something much higher (e.g. 60 seconds). This way, the gauge can recover from a compound CUV and CHGC fault; however, the retry period is much longer, and the cells are not repeatedly faced with excessive charging current as rapidly. In case you have any concerns, please let me know.

I am aligned with you here, I think this could be a tangible workaround for this kind of issue. I would recommend testing this just to confirm its validity.

Jeff LaBundy said:

My last question for now is to understand what is the expected behavior if both OCC and CHGC faults occur simultaneously? Does the gauge wait for both faults' recovery criteria to be met, or does one fault take priority over another?

Since both the OCC and CHGC are both firmware protections, there is no priority between them. If they are triggered simultaneously, the XCHG bit will become set regardless and open the CHG FET. For the gauge to clear the XCHG bit, both of the protection's recovery conditions need to be met for the FET to be closed again. This idea can be applied for any firmware protections that are triggered at the same time that affect the same FET.

Jeff LaBundy said:

In our design, the OCC1 and CHGC (RT) thresholds are the same (6500 mA), but the delays are 6 and 3 seconds, respectively. If our charger IC did somehow drive over 6500 mA into the cells, the CHGC fault would occur first; it's therefore impossible for an OCC fault to occur according to our configuration. In case I have misunderstood, please let me know.

You are correct here. If the CHGC protection is triggered first, then it would be impossible for the OCC protection to trigger since the FET is now open and there is no access to the sense resistor, which the OCC relies on. 

Regards,

Anthony

Hi Anthony—thank you for your feedback; I'm aligned with you. Thanks to your generous support these last few weeks, I feel I've become adept at managing the gas gauge configuration.

I think the last question for now is whether the ShutdownMode command (0x0010) followed by a charger unplug/plug can effectively act as the DeviceReset command (0x0041) for the purpose of clearing out any such "chicken and egg" compound faults, as my quick test suggests.

This is more attractive as a general workaround for cases where DSG = CHG = 0 for prolonged periods of time, as opposed to trying to protect against any one case using carefully selected golden file parameters.