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.

DRV8711: Predriver Fault(XPDF) detection

Part Number: DRV8711

Hi all

Would you mind if we ask DRV8711?

And thank you for your cooperation about DRV8711's support always. 

We recognize the condtion which Predriver Fault(XPDF) occurs. 
-The predriver fault (xPDF) indicates a failure on the gate of the FET. 
-The predriver fault monitors proper operation of the x1LS/x2LS/x1HS/x2HS outputs of the DRV8711.
-If incorrect operation is detected the PDF fault is activated.
-Examples of detectable predriver faults are gate to source short, gate to drain short, pin short to adjacent pin.
https://e2e.ti.com/support/motor-drivers/f/38/t/655432

In addition to it, we would like to know how DRV8711 detects Predriver Fault condtion. 
-Do Gate drive & OCP detect Predriver Fault condtion using flowing current?
-Or, does Isense block detect Predriver Fault condtion using flowing current?
If Gate drive & OCP detect Predriver Fault condtion, could you let us how much the threshold for detection is?

And thenm there are description as follows;
8.1.2 Optional Series Gate Resistor
In high current or high voltage applications, the low side predriver fault may assert due to noise in the system. In
this application, TI recommends placing a 47 to 120-Ω resistor in series with the low side output and the gate of
the low side FET. TI also recommends setting the dead time to 850 ns when adding a series resistor.
->What does "assert due to noise in the system" indicate? If you have some concrete example and solution, could you share us?

As the background of this question, our customer's board occurs  Predriver Fault condtion in case of startup sometimes.
So, they would like to judge whether it depends on the noise of Isense block or not.

Kind regards,

Hirotaka Matsumoto

  • Hi Matsumoto-san,

    We will investigate and reply by Tuesday of next week.
  • Hi Matsumoto-san,

    In addition to it, we would like to know how DRV8711 detects Predriver Fault condtion. 
    -Do Gate drive & OCP detect Predriver Fault condtion using flowing current?
    -Or, does Isense block detect Predriver Fault condtion using flowing current?
    If Gate drive & OCP detect Predriver Fault condtion, could you let us how much the threshold for detection is?

    Predriver faults are detected using voltage and timing. After the gate is enabled or disabled, a timer is started.
    At ~2.2us, the voltage is checked on the xxLS or xxHS outputs.
    If the Vgs voltage is >1  when disabled, or <1V when enable a predriver fault is asserted.

    One cause of the predriver fault is coupling as shown in the image below.

    B2LS has turned off. Approximately 2.2 us later, A2HS turns on (A2OUT transitions to high). This couples to the B2LS causing B2LS to rise to ~1.7V. The coupling creates what appears to be a predriver fault and the outputs are disabled.

    Adding the gate resistors and increasing the dead time as recommended minimizes the effect of this coupling.

  • Rick san

    Thank you so much for your reply!
    OK, we got it!

    Kind regards,

    Hirotaka Matsumoto

  • Rick san

    Thank you so much for your support always!
    The customer confirmed the wave form as the attachment file.
    20181205_DRV8711_XPDF fault.pdf

    According to ① noise on the attachment file, might PDF fault occur?

    Kind regards,

    Hirotaka Matsumoto

  • Hi Matsumoto-san,

    According to ① noise on the attachment file, might PDF fault occur?

    It is possible, but unlikely. The 1.5V on B1LS could be caused by capacitive coupling between the drain of BOUT1 and gate of B1LS. This voltage spike appears to occur before the check for a predriver fault.

    If debugging predriver faults, it is important to first determine which predriver is faulting ( A or B ).
    Once determined, the next step is to attempt to capture the fault event using nFAULT as a trigger while monitor the fault side low side gate signals and the xOUT of the side that did not fault. This should provide insight on where the fault occurred.