• State TI Thinks Resolved
  • Locked Locked
  • Replies 7 replies
  • Answers 2 answers
  • Subscribers 63 subscribers
  • Views 382 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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: Hardware protection timing

Tyler Holmvik
Intellectual 891 points
Part Number: BQ40Z50

Hi, 

Customer is using the BQ40Z50 on a design and seeing a time delay of 300-400us for an overcurrent event and the activation of protection (CHG/DSG signal change at the BQ). They expected tDetect delay of 160us but they are seeing double that. They set the time offset for 0 seconds for protections.

Is this expected behavior? Any suggestions on how to reduce the time from event to protect?

Thanks,

Tyler 

  • 0
    TI__Guru** 105600 points

    Hello Tyler,

    There is a FAQ which discusses the differences between the hardware and firmware protections, it may help answer your questions. You can find it on our home FAQ page for the BQ40Z50: https://e2e.ti.com/support/power-management-group/power-management/f/power-management-forum/1106884/faq-bq40z50-faqs

    There's a delay which is added to all hardware protections which must be accounted for, it is defined in the datasheet.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 891 points

    Wyatt, 

    Yes I had referenced that "[FAQ] What are the differences between the hardware and firmware protections?" post and it was helpful.

    However I am looking for more specific support here. Based on that FAQ, I am expecting 160us delay but customer is seeing 300-400us. Can you help me understand what that is?

    "When setting the timing on the BQ hardware protections (ASCC, ASCD), a fixed time offset of 300us-500us between the programmed and measured time has been observed that BQ requires to trigger the protection. Even when we program it to 0 seconds for protections, a delay of 300us-400us was observed between the overcurrent event and the activation of the protection (CHG/DSG signal change at the BQ). We expected 160us based on tDelay"

    Tyler

  • 0 in reply to Tyler Holmvik
    TI__Guru** 105600 points

    Hello Tyler,

    Can you share their .gg file and scope captures showing the behavior? If they have large gate capacitance is could take longer to actually see the current be shutoff from ASD event. The delays we give are the reaction time directly when the gauge will start to open the FET.

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 891 points

    Please find attached the .gg file and two scope captures

    • ASCD 24.7A 916delay.png corresponds to the attached .gg file
    • ASCD 24.7A 0delay.png: corresponds to the same .gg file, but with ASCD Threshold2 (line 384) set to 04 (hex)
    • C2 (red) trace represents the DSG signal from BQ40Z50
    • C4 (green) trace represents the current

    BQparameters 20230815.gg.csv

    ASCD 24.7A 916delay

    ASCD 24.7A 0delay.png

  • 0 in reply to Tyler Holmvik
    TI__Guru** 105600 points

    Hello Tyler,

    Based on their settings in the .gg file shared, the AFE Control Register has 0x72, which indicates that the SCD double bit is set (modified from the default setting) so it seems they are intending to increase the delay.

    Base on this, I think the results may be close to the expectations, given 10% error with hardware protection thresholds. Were they triggering ASCD 1 or ASCD 2?

    Sincerely,

    Wyatt Keller

  • 0 in reply to Wyatt Keller
    TI__Intellectual 891 points

    Thanks for the quick reply Wyatt. Their gate capacitance is 2nF. Is this considered large or small capacitance for this design?

    From customer:

    It is intended to have the SCDdx2 bit set. With ASCD Threshold 1 and 2 set to 0xF4, the expected delays are 1830us for ASCD1 and 916us for ASCD2 (image below). Because the thresholds are the same, ASCD2 should trigger (lower delay).

     

    The top limit would be 916 + 916*10% + tDetect =  1168us. What we measured is 1552us.

    Also when setting the ASCD Threshold 1 and 2 to 0x04 (expecting ~instant triggering), we measure a delay of 578us (again, higher than 0 + tDetect = 160us).

    Do you have any insights on what could cause these increases in the triggering delays?

    Tyler

  • 0 in reply to Tyler Holmvik
    TI__Guru** 105600 points

    Hello Tyler,

    It does not seem to be lining up with the expectations. Can they try uploading the default SREC again and doing testing with the baseline settings?

    Sometimes the trim flash can edited by accident and cause issues, it is the reserved bits.

    Sincerely,

    Wyatt Keller