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.

BQ76952: BQ76952 Short Circuit Protection improper operation

Part Number: BQ76952
Other Parts Discussed in Thread: UCC37324, BQSTUDIO

Hello,
We are using BQ76952 and are having issues with SCD. When SCD threshold condition is met, the AFE doesn't seem to switch off the DDSG(Discharge FET) FET. The DCHG FET(Charge FET) is switched Off after Short Circuit occurs and never recovers unless the cell connections are removed and plugged in again whereas The DDSG remains on even after Short circuit occurs. 
Following are the configurations:
Enabled FET Protections A - 0xBC
CHG FET Protection A - 0x98
DSG FET Protections A - 0xE4
FET options - 0x0D
SCD threshold - 200mV
SCD delay - No delay.
Note: We are using Low-side switching and FETs are in series configuration

Thanks and Regards 

Ibrahim Saqib 

  • Hi Ibrahim,

    The settings look okay. The SCD Threshold of 200mV is very high - are you using a large sense resistor or will the threshold be a very large current? Have you read the Safety Status registers to confirm that SCD is triggered? The behavior you describe sounds more like an OCC protection behavior - the default settings for OCC requires a discharge current for the CHG FET to be re-enabled. You can modify the OCC Recovery Threshold to change this (set to zero). 

    If you can share more details on your sense resistor and low-side FET circuit along with your other register settings (you should be setting the DDSG Pin Configuration and DCHG Pin Configuration registers), it may be helpful for us to help you debug.

    Best regards,

    Matt

  • Thanks for the swift response Matt. In response to your query thhese are the settings we've done :-

    DDSG Pin Configuration: 0xAA

    DCHG Pin configuration: 0xAA

    Apart from that the main issue that we've noticed now is that on performing Short Circuit tests the AFE is unable to detect the Short Circuit and the DCHG and DDSG pins remain on(Both On). 

    The mV drop across SRN-SRP is ranging from 250mV to 600mV but still the AFE is not detecting the fault and this was verified by reading the subsequent AFE protection registers.

    Note:- The short circuit tests we've performed are as follows and there is low side gate driver UCC37324 that we've used:-

    1) Using capacitors in parallel with a resistive load, calculated to have a very high spike during turn On of load which can simulate a SC spike, the spike is around 400mv in this scenario.

    2) Actual Short Circuit of Battery with Secondary Protection devices like Fuse and MCB. The spike noted during scenario is around 250 to 600mV.

    Please find attached the Schematic of the Protection and current measurement circuit below.

    Request you to please guide us as to what we're missing here and what could cause this to happen. 

    Thanks and Regards

    Ibrahim 

  • Hello Ibrahim, 

    So there are no protections based on the register bits?

    Could you share a .gg.csv file of your configuration? Are you measuring directly across the SRN/SRP pins? 

    How long is the short-circuit spike? If you set the SCD at a lower value, does it help with detection?

    Best Regards,

    Luis Hernandez Salomon

  • Hi Luis, 

    Yes, the mV drop is directly measured across SRN and SRP. 

    The short circuit spike lasts around 2ms before the MCB itself cuts the current Off. 

    We've tried keeping lower SCD values as well from 40mV till 500mV and also tested it with different delay times, but no combination seems to work. The detection of SCD isn't happening and both DCHG and DDSG pins remain at 3.4V (continuously ON).

    Note:- the equivalent shunt resistance is 1mohm which  translates to 1mV drop per amp. 

    Thanks 

  • Hello Ibrahim,

    Would you share the .gg.csv configuration file so we may look at the settings and make sure everything is okay?

    Best Regards,

    Luis Hernandez Salomon

  • Sure Luis.

    To add to the above points, I'd like to also point out that other protection functions like OCD, OCC, OT, UT, OV and UV and their recoveries are all functioning normally.

    It is only during the SC that AFE isn't able to detect the fault. Whereas for OCD when set at 100mV with a delay of 10ms, the AFE is able to detect it and function normally.

    Can you please confirm if the the schematic is as it should be or are missing something. 

    I'll share the .gg.csv file  by tomorrow 

    Thanks & Regards 

    Ibrahim 

  • Hi Luis,

    Bqstudio doesn't load default values conforming with the TRM for some weird reason. Is there a new update for the software?

    Anyways, I have added corresponding register values for protections.

    Or could you send me a default gg.csv file which is according to the TRM? So that I can load that, change specific values that are in my code and send it back to you?

    Do take a look at the attached file.

    Note: FET options = 0x0d

    Chg Pump control = 0x00

    DDSG Pin config = 0xAA

    DCHG Pin Config = 0xAA

    Enabled Protections A = 0xBC

    CHG FET Protections A = 0x98

    DSG FET Protections A = 0xE4

    We are seeing normal operation of OCC, OCD1 protections.

    We are also seeing SCD flag on the Safety Status A register only when we externally provide a voltage drop of 200mV or above artificially across the shunt from a regulated power supply to simulate a SC condition. In this condition, DDSG and DCHG pins work as expected. 

    Request you to please have a look and provide your valuable feedback. 

    Thanks and Regards 

    Ibrahim 
    bmsv1.gg.csv 

  • Hi Luis,

    Bqstudio doesn't load default values conforming with the TRM for some weird reason. Is there a new update for the software?

    Anyways, I have added corresponding register values for protections.

    Or could you send me a default gg.csv file which is according to the TRM? So that I can load that, change specific values that are in my code and send it back to you?

    Do take a look at the attached file.

    Note: FET options = 0x0d

    Chg Pump control = 0x00

    DDSG Pin config = 0xAA

    DCHG Pin Config = 0xAA

    Enabled Protections A = 0xBC

    CHG FET Protections A = 0x98

    DSG FET Protections A = 0xE4

    We are seeing normal operation of OCC, OCD1 protections.

    We are also seeing SCD flag on the Safety Status A register only when we externally provide a voltage drop of 200mV or above artificially across the shunt from a regulated power supply to simulate a SC condition. In this condition, DDSG and DCHG pins work as expected. 

    Request you to please have a look and provide your valuable feedback. 

    Thanks and Regards 

    Ibrahim 

    6862.bmsv1.gg.csv

  • Hi,

    Please consider the attached gg.csv file and ignore the one in the previous thread.

    Thanks0363.bmsv1.gg.csv

  • Hi Ibrahim,

    It looks like you may be using an old prototype version of the device based on the reading near the top of your .gg file.

    The firmware version should be 0.36 for a production device. Do you know where you received this device from? The production version has been released for more than two years, so this is strange. 

    Or perhaps you are using an old version of BQStudio which does not have the updated device in the database?

    Best regards,

    Matt

  • Hey Matt, 

    Yes, it does seem like we have an older version of the EVM as well as that of BQ Studio. 

    The Top marking on the BQ76952PFBR IC which we're using on the board we've designed is as shown in the picture of the part shared below

    BQ76952

    08WG4

    A97Y

    Is this a pre production part or a production part? 

    Looking forward to hearing from you. 

    Thanks and Regards 

    Ibrahim 

  • Ibrahim,

    I think the top marking of the device is the production version. The soldering on the board looks a little scary though. Upgrading BQStudio is critical because if you are trying to write the registers of the pre-production version of the device, it will write to different registers on the new device (register addresses are not all the same). This might explain the strange behavior you are observing.

    Regards,

    Matt