• State Resolved
  • Locked Locked
  • Replies 11 replies
  • Subscribers 64 subscribers
  • Views 513 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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-R2: Short circuit problem about 1 second after the short circuit occurs

Christian Rump
Prodigy 10 points
Part Number: BQ40Z50-R2
Other Parts Discussed in Thread: BQSTUDIO

We did short circuit tests with our BMS and encountered a problem.

On some boards, the MOS-FET's are burnt approx. 1 second after the first short circuit.

Measured with an Ozillocop over 0.5mOhm you can see very clearly that the first short circuit is intercepted.

After about a second, the MOSFETs seem to be activated again.

However, the unlock delay is set to 10 seconds.

 

Is there another register set incorrectly?

Or how can the activation after approx. 1 second be avoided?

Short circuit is generated and approx. 1 second later it is activated for a short time   Short circuit is generated and approx. 1 second later the MOS-FET's are burnt 

Settings-Protections

  • 0
    TI__Guru** 104905 points

    Hello Christian,

    Can you share a BQStudio log of your tests so we can review the registers during the failure? Can you also share your .gg file with the full configuration for the test?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    4188.bat_105Ah_v5.6_2023-01-24_01.log
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Tue Jan 24 11:49:47 CET 2023
    Device Version Info = 4500_2_08
    BQZ Device Name = bq40z50R2
    BQZ Firmware Version = V2_08_BLD50
    Design Capacity = 10500
    Design Voltage = 12800
    Specification Info = 0x0031
    Manufacturer Date = 2022-9-15
    Serial Number = 0x0001
    Manufacturer Name =
    Device Name =
    Device Chemistry = LIFE
    Sample,DateTime,ElapsedTime,ManufAccess,RemCapAlarm,RemTimeAlarm,BattMode,@Rate(@),@TimeFull,@TimeEmpty,@RateOK,Temperature,Voltage,Current,AvgCurr,MaxErr,RSOC,ASOC,RemCap,FullChgCap,RunTimeEmty,AvgTimeEmty,AvgTimeFull,ChgCurr,ChgVolt,BattStat,CycleCnt,MaxTurboPwr,SusTurboPwr,MaxTurboCurr,SusTurboCurr,SoH,OpStatA,OpStatB,TempRange,ChgStat,GaugeStat,ITStat,MfgStat,SafetyAlertAB,SafetyStatAB,SafetyAlertCD,SafetyStatCD,PFAlertAB,PFStatAB,PFAlertCD,PFStatCD,CellVolt1,CellVolt2,CellVolt3,CellVolt4,vBAT,vPACK,CellCurr1,CellCurr2,CellCurr3,CellCurr4,CellPower1,CellPower2,CellPower3,CellPower4,Power,AvgPow,IntTemp,TS1Temp,TS2Temp,TS3Temp,TS4Temp,CellTemp,FETTemp,GaugeTemp,FltRemQ,FltRemE,FltFullChgQ,FltFullChgE,NoLoadRemCap,TrueRemQ,TrueRemE,InitialQ,InitialE,TrueFullChgQ,TrueFullChgE,T_sim,T_ambient,RaScale1,RaScale2,RaScale3,RaScale4,CompRes1,CompRes2,CompRes3,CompRes4,PackGrid,LStatus,CellGrid1,CellGrid2,CellGrid3,CellGrid4,StateTime,DOD0_1,DOD0_2,DOD0_3,DOD0_4,DOD0 Passed Q,DOD0 Passed E,DOD0 Time,DODEOC_1,DODEOC_2,DODEOC_3,DODEOC_4,QMax1,QMax2,QMax3,QMax4,QMaxDOD0_1,QMaxDOD0_2,QMaxDOD0_3,QMaxDOD0_4,QMaxPassedQ,QMaxTime,Tk,Ta,RawDOD_1,RawDOD_2,RawDOD_3,RawDOD_4,CBTime1,CBTime2,CBTime3,CBTime4,CBDOD_1,CBDOD_2,CBDOD_3,CBDOD_4,CBTotalDODChg,SOH_FC_Q,SOH_FC_E,LogRowTime(ms),LogStatus
    1,2023-01-24 11:49:52,5.000,0x0187,300,10,0x6001,0,65535,65535,1,14.6,13952,0,0,1,99,108,11339,11454,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23440,-32767,-21000,100,0x0187,0x0000,0x08,0x0008,0x50,0x0011,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3441,3507,3492,3512,13895,14038,0,0,0,0,0,0,0,0,0,0,15.8,14.6,14.9,15.0,-53.5,14.6,-273.2,14.6,11454,14420,11454,14420,11651,11454,14420,0,0,11454,14420,15.9,14.6,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,6880,0,0,0,0,0,0,30,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,30,1.17,860,0,0,0,0,0,0,0,0,0,0,0,0,16384,11527,14803,1196,SUCCESS
    2,2023-01-24 11:49:57,10.001,0x0187,300,10,0x6001,0,65535,65535,1,14.5,13952,0,0,1,99,108,11339,11454,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23440,-32767,-21000,100,0x0187,0x0000,0x08,0x0008,0x50,0x0011,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3441,3507,3492,3512,13894,14039,0,0,0,0,0,0,0,0,0,0,15.8,14.5,14.9,14.9,-53.3,14.5,-273.2,14.5,11454,14420,11454,14420,11651,11454,14420,0,0,11454,14420,15.9,14.5,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,6885,0,0,0,0,0,0,30,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,30,1.17,860,0,0,0,0,0,0,0,0,0,0,0,0,16384,11527,14803,1166,SUCCESS
    3,2023-01-24 11:50:02,15.199,0x0187,300,10,0x6001,0,65535,65535,1,14.5,13952,0,0,1,99,108,11339,11454,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23449,-32767,-21000,100,0x0187,0x0000,0x08,0x0008,0x50,0x0011,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3442,3507,3492,3512,13896,14038,0,0,0,0,0,0,0,0,0,0,15.8,14.5,14.9,14.9,-53.4,14.5,-273.2,14.5,11454,14420,11454,14420,11651,11454,14420,0,0,11454,14420,15.9,14.5,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,6890,0,0,0,0,0,0,30,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,30,1.17,860,0,0,0,0,0,0,0,0,0,0,0,0,16384,11527,14803,1232,SUCCESS
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    7268.bat_105Ah_v5.6_2023-01-24.gg.csv

    bat_105Ah_test

  • 0 in reply to Christian Rump
    TI__Guru** 104905 points

    Hello Christian,

    The gauge will clear the ASCD when the firmware sees it (about one second interval) after the ASCD gets triggered multiple times in a row without clearing the counter then ASCDL should set and stop any more discharge until it is cleared (depending on the NR bit settings)

    If you are testing with MOSFETs in parallel or large gate capacitance the gauge may not be able to pull the gate low fast enough to prevent FET damage. Can you share a snippet of your schematic?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hello Wyatt,

    There are 7 x IFRS7534-7PPBF parallel on the circuit.
    Each Gate are connected paralell via 100 Ohm and over one 5,1k resitor to the DSG-Pin.

    Schematic MOS-FET

    At BMS where the MOS-FET's don't burn out 1 sec after the short circuit,
    this unlocking occurs again and again after approx. 1s.

    NR = 1, ASCD:Latch Limit = 1, ASCD:Counter Dec Delay = 30s, ASCD:Recovery = 10s, ASCD:Reset = 120s.

    Best regards

    Christian Rump

  • 0 in reply to Christian Rump
    TI__Guru** 104905 points

    Hello Christian,

    The gauge may not be able to turn off all the FETs you have in parallel quick enough, you may need to add some external circuitry to pull down the gates faster. The battery monitor team has some useful collateral for this, let me know if this is useful: https://www.ti.com/lit/an/sluaa09a/sluaa09a.pdf?ts=1674691687604&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FBQ76952

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hello Wyatt,

    Thank you for the link to the document.

    I've now tested some of this.

    The MOS-FET's now survive the short circuit,

    but it still seems to be activated after one second

    and not after 10 seconds as set in the parameters.

    Picture1: Short_200us_RVgate=47r+RVDSG=100r+Zener16V

    CH2=DSG_Gate, CH1=Ishort over 0,5mOhm -->  ~1kA

    Short_200us_RVgate=47r+RVDSG=100r+Zener16V

    Picture2: Short_100ms_RVgate=47r+RVDSG=100r+Zener16V

    CH2=DSG_Gate, CH1=Ishort over 0,5mOhm -->  ~1kA

    Short_100ms_RVgate=47r+RVDSG=100r+Zerner16V

    Picture3: Short_500ms_RVgate=100r+RVDSG=100r+Zener16V

    CH1=Ishort over 0,5mOhm

    Short_500ms_RVGate=100r+RVDSG=100r+Zener

    Log of the last Test (see also Picture3):

    test13.log
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Thu Feb 02 13:24:44 CET 2023
    Device Version Info = 4500_2_08
    BQZ Device Name = bq40z50R2
    BQZ Firmware Version = V2_08_BLD50
    Design Capacity = 10500
    Design Voltage = 12800
    Specification Info = 0x0031
    Manufacturer Date = 2022-9-15
    Serial Number = 0x0001
    Manufacturer Name =
    Device Name =
    Device Chemistry = LIFE
    Sample,DateTime,ElapsedTime,ManufAccess,RemCapAlarm,RemTimeAlarm,BattMode,@Rate(@),@TimeFull,@TimeEmpty,@RateOK,Temperature,Voltage,Current,AvgCurr,MaxErr,RSOC,ASOC,RemCap,FullChgCap,RunTimeEmty,AvgTimeEmty,AvgTimeFull,ChgCurr,ChgVolt,BattStat,CycleCnt,MaxTurboPwr,SusTurboPwr,MaxTurboCurr,SusTurboCurr,SoH,OpStatA,OpStatB,TempRange,ChgStat,GaugeStat,ITStat,MfgStat,SafetyAlertAB,SafetyStatAB,SafetyAlertCD,SafetyStatCD,PFAlertAB,PFStatAB,PFAlertCD,PFStatCD,CellVolt1,CellVolt2,CellVolt3,CellVolt4,vBAT,vPACK,CellCurr1,CellCurr2,CellCurr3,CellCurr4,CellPower1,CellPower2,CellPower3,CellPower4,Power,AvgPow,IntTemp,TS1Temp,TS2Temp,TS3Temp,TS4Temp,CellTemp,FETTemp,GaugeTemp,FltRemQ,FltRemE,FltFullChgQ,FltFullChgE,NoLoadRemCap,TrueRemQ,TrueRemE,InitialQ,InitialE,TrueFullChgQ,TrueFullChgE,T_sim,T_ambient,RaScale1,RaScale2,RaScale3,RaScale4,CompRes1,CompRes2,CompRes3,CompRes4,PackGrid,LStatus,CellGrid1,CellGrid2,CellGrid3,CellGrid4,StateTime,DOD0_1,DOD0_2,DOD0_3,DOD0_4,DOD0 Passed Q,DOD0 Passed E,DOD0 Time,DODEOC_1,DODEOC_2,DODEOC_3,DODEOC_4,QMax1,QMax2,QMax3,QMax4,QMaxDOD0_1,QMaxDOD0_2,QMaxDOD0_3,QMaxDOD0_4,QMaxPassedQ,QMaxTime,Tk,Ta,RawDOD_1,RawDOD_2,RawDOD_3,RawDOD_4,CBTime1,CBTime2,CBTime3,CBTime4,CBDOD_1,CBDOD_2,CBDOD_3,CBDOD_4,CBTotalDODChg,SOH_FC_Q,SOH_FC_E,LogRowTime(ms),LogStatus
    1,2023-02-02 13:24:50,5.002,0x0107,300,10,0x6001,0,65535,65535,1,19.1,13341,0,0,1,97,105,10928,11372,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23932,-32767,-21000,100,0x0107,0x0000,0x08,0x0008,0x50,0x0014,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3330,3336,3335,3340,13379,13435,0,0,0,0,0,0,0,0,0,0,19.8,19.1,19.4,19.5,-53.4,19.1,-273.2,19.1,10928,13754,11372,14338,11066,10928,13754,444,584,11372,14338,18.9,18.8,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,165,832,696,704,624,0,0,0,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,0,1.17,860,832,696,704,624,0,49858,46774,65535,832,696,704,624,16384,11527,14803,1296,SUCCESS
    2,2023-02-02 13:24:55,10.001,0x0107,300,10,0x6001,0,65535,65535,1,19.1,13341,0,0,1,97,105,10928,11372,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23932,-32767,-21000,100,0x0107,0x0000,0x08,0x0008,0x50,0x0014,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3330,3336,3335,3340,13379,13436,0,0,0,0,0,0,0,0,0,0,19.8,19.1,19.4,19.5,-53.4,19.1,-273.2,19.1,10928,13754,11372,14338,11066,10928,13754,444,584,11372,14338,18.9,18.8,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,170,832,696,704,624,0,0,0,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,0,1.17,860,832,696,704,624,0,49858,46774,65535,832,696,704,624,16384,11527,14803,1299,SUCCESS
    3,2023-02-02 13:25:00,15.281,0x0107,300,10,0x6001,0,65535,65535,1,19.1,13341,0,0,1,97,105,10928,11372,65535,65535,65535,2500,14400,0x00C0,1,-32767,-23932,-32767,-21000,100,0x0107,0x0000,0x08,0x0008,0x50,0x0014,0x0298,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,0x0000,3332,3336,3335,3341,13380,13435,0,0,0,0,0,0,0,0,0,0,19.8,19.1,19.4,19.5,-53.5,19.1,-273.2,19.1,10928,13754,11372,14338,11066,10928,13754,444,584,11372,14338,18.9,18.8,1000,1000,1000,1000,0,0,0,0,0,14,0,0,0,0,175,832,696,704,624,0,0,0,0,0,0,0,11658,11651,11668,11661,0,0,0,0,0,0,1.17,860,832,696,704,624,0,49858,46774,65535,832,696,704,624,16384,11527,14803,1267,SUCCESS
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    Best regards

    Christian Rump

  • 0 in reply to Christian Rump
    TI__Guru** 104905 points

    Hello Christian,

    I looked through the log and I don't see any of the protections being set. Can you change your sampling rate to 1s intervals so we can see exactly when they get set if they do? You can also disable logging for certain registers so it can ready only VIT data with the safety and alert registers,

    You can disable logging for all registers then select the ones you want by double clicking the log button:

    Can you also enable the lifetime logging and then click the LT_FLUSH command after the test before exporting the .gg file an sharing?

    I can't tell which hardware protection is getting triggered and the log isn't showing any protection triggered. It is strange it resets every 1s, this is how often the firmware updates all the registers.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hello Wyatt,

    Attached is the log file from the last short circuit test.
    The query interval was set to 500ms.

    1st short circuit test 2nd Short circuit test

    test16.log

    Also included in the appendix is a watch log with a log time of 250ms with the 4 registers:
    Battery Mode, Operation Status A, Safety Alert A+B and Safety Status A+B.

    test16.1.log
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    Data Log
    TimeStamp,Battery Mode,Operation Status A,Safety Alert A+B,Safety Status A+B
    2023-02-06 08:56:49.310,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:50.402,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:51.528,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:52.655,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:54.232,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:55.359,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:56.480,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:58.010,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:56:59.121,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:00.247,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:01.834,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:02.965,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:04.076,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:05.643,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:06.730,0x6001,0x0107,0x0000,0x0000
    2023-02-06 08:57:07.843,0x6001,0x0107,0x0000,0x0000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I also activated Lifetime logging before the test and executed the LT_Flush command after the test and exported the data.

    105ah_after_test16.gg.csv

    Thank you for your support

    Best regards

    Christian Rump

  • 0 in reply to Christian Rump
    TI__Guru** 104905 points

    Hello Christian,

    thank you for providing the additional data.

    Let me take a closer look at it and respond within the next couple days, I am currently traveling and don’t have good internet.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Guru** 104905 points

    Hello Christian,

    Sorry for the delay, I have been traveling and training the last few days.

    I took a look at the files shared, it looks like the lifetime data may not have properly been saved, it looks like they are still default.

    Also in the logs I don't see any of the safety flags trigger, which is really strange to me. I think you have actually disabled the ASCD and ASCC protection since the enabled protections B has been modified from default. Both bits 0 and 2 should be 1, RSVD bits shouldn't be modified.

    From what I can tell the gauge may not have actually registered the hardware fault because it was disabled in firmware, so on the next firmware check of the AFE registers it constantly clears the AFE fault which is why it happens every 1s in your tests.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    Prodigy 10 points

    Hello Wyatt,

    yes that was the right hint.

    The Reseved Bits 0 and 2 of "Settings.Protections B" were set to 0.

    Settings.ProtectionsB wrong setting

    After the bits were set to 1, the activation only came after the time set under Protections.ASCD.Recovery. (Actually after 10sec)

    Settings.ProtectionsB rigth setting

    Test18_Short2_500ms

    test18.log

    Thank you for your support.

    Best regards

    Christian Rump