BQ76952: BQ76952 DFETFail/CFETFail question

Hi Kaho,

Was the device in SLEEP mode? When the device is in SLEEP mode, measurements are taken at a slower rate and could result in a slower initial detection.

Another thing to try is monitoring the CC2 value. It may be that the initial detection is being slowed slightly due to the filtering of the current measurement, both from the external RC filter and the internal digital filtering.

Does this happen with other current based protections (OCD1/2/3 or OCC)?

Regards,

Max Verboncoeur

HI Maxwell

A . device in Active mode

       1.Settings:Configuration:Power Config :0x0C80

       2. I check  "Battery Status()"  In the UV state, I read the value as 0x0980

B . I tried using current hook meter Confirm with the current time read by MCU

     The difference is about 80ms,

C. i use "OCD1_Threshold"  : 16 

              "OCD1_Delay" : 121

              The result of my experiment is 32.4A /410ms

             "OCC_Threshold"  : 3 

             "OCC_Delay" : 121

               The result of my experiment is 6.08A /2.74s

It seems that the OCC time is also far behind.

The problem I encountered during testing is as follows:
ch1 D fet
ch2 C fet
ch3 Alert pin
ch4 Current

I simulate 100mA DSG current on SRP-SRN pin,

Alert pin will trigger before pfdfetfail occurs
And it can be found that the first Alert pin pull high when the current appears is exactly the time to delay pfdfetfail.

I can use mcu to confirm that MSK_PFALERT is received

I confirmed that the register setting of MSK_PFALERT is as follows
0x80U, //U8 Enabled_PF_A; //-------0x92C0 0x80
0x1BU, //U8 Enabled_PF_B; //-------0x92C1 0x1B
0x00U, //U8 Enabled_PF_C; //-------0x92C2 0x00
0x00U, //U8 Enabled_PF_D; //-------0x92C3 0x00

0x01U, //U8 PF_Alert_Mask_A; //-------0x92C4 0x01
0x1BU, //U8 PF_Alert_Mask_B; //-------0x92C5 0x1B
0x00U, //U8 PF_Alert_Mask_C; //-------0x92C6 0x00
0x00U, //U8 PF_Alert_Mask_D; //-------0x92C7 0x00

Q1. But I don’t know why the first Alert pin pulls high?

This may be the reason for the delay in pfdfetfail

20231106.gg.csv

Hi Kaho,

I believe the alert is triggered at the beginning of the delay countdown, so the first alert is when the DFETF conditions have been detected and the second alert is likely something else.

Regards,

Max Verboncoeur

 I use MCU 250ms to send command to AFE including

1. BQ76952_REG_battery_status_Address
2. BQ76952_REG_alarm_raw_status_Address
3. BQ76952_REG_safety_status_A_Address
4. BQ76952_REG_FET_status_Address
5. BQ76952_REG_Cell1_Voltage_Address
6. BQ76952_REG_DASTATUS5_Address
7. BQ76952_REG_CC2_Current_Address
8. BQ76952_REG_Int_Temperature_Address

Use LA to measure the relationship between i2C communication and alert,
As can be seen from the figure below, the interval between the current and the Alert pin is 530ms.

It means that I have 2 opportunities to ask the "BQ76952 REG alarm raw status Address[0x64]" register

I set BMS to CUV, I simulate 100mA DSG current on SRP-SRN pin,

I see that the current reaches 100mA and the Alert pin has not been pulled high for the first time.
Query 2 times "BQ76952 REG alarm raw status Address[0x64]" The response given by the temporary register is 0x46A3, which means that "MSK_PFALERT" has not occurred.

Q. What is the reason for the 530ms DFETF detection delay of AFE?

Hi Kaho,

It is likely that the DFETF detection uses the CC1 measurement, which updates every 250ms.

I'm going to attempt to recreate this on an EVM and I'll get back to you on those results by the end of tomorrow.

Regards,

Max Verboncoeur