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 after an hour of milling

Other Parts Discussed in Thread: DRV8711, CSD18531Q5A

Hi,

I have I custom made DRV8711 driver board with CSD18531Q5A mosfets and small MCU controling the DRV8711 over SPI (yes, TI has special kind/mode of SPI :) ). In standalone PC application user can set "user" parameters covering most of the DRV8711 setup parameters (other are hardcoded and calculated based on recommendation in datasheet.

We are getting really great feed rates (reaching the DRV8711 limits) but the PreDriver fault is really annoying. Usually driver is configured to get best current curve and best audible noise performance and settings saved. Then driver operates for 10, 20 minutes or even hours and suddenly between operation PreDriver fault occurs.

Example of settings where fault occurs after 9 minutes of operation:

1/32step, 1.8A full scale current, Use mixed decay all the time, off time 15us, mixed decay time 7.5us, adaptive blanking OFF, blanking time 1us, DTIME 650ns, TDRIVE 2us, IDRIVEN/P 200/100mA.

What am I missing or doing wrong?

Regards, Uros

  • Hi Uros,

    You may not be doing anything wrong. Have you noticed section 8.1.2 (page 29) of the most recent datasheet?

    If you are seeing low side predriver faults this may apply.
  • Hi Rick,

    yes I did. I the newest revision of hardware we put 0R resistors just in case if software solution will not help. But it is hard to add or replace resistors on boards that are at customers.

    Why the fault happens after certain amount of time? Or asking differently, how can I know the settings I have are bulletproof?

    Is there a set of setting which shall not have PreDriver fault in any case, but the performance is not that optimal? I would like to have default settings and allowing experts to optimize their drivers (but still avoiding possibility of PreDriver fault event).

    Moreover, I guess decreasing IDRIVE and TDRIVE would help, but then thermal performance would be jeopardized.

    Would fixing DTIME to 850ns make any improvement?

    Regards
    Uros
  • Hi Uros,

    Glad to hear you have the footprint.

    Can you confirm that the fault is a low side predriver fault?

    If it is a low side predriver fault, it can be due to noise coupling from one phase into the other LS gate output. If the noise occurs at the wrong time and is above approximately 1V, this can trigger a false predriver fault.

    Some suggestions to eliminate it are:
    Replacing the zero ohm resistor with a 47 to 120 Ohm in series with the gate, and setting the dead time to 850ns (this is in the datasheet)
    Also, reducing the IDRIVE to the minimum values. As you mentioned this may have an affect on thermal

    FYI -- changing DTIME should have no impact. The reason the DTIME change is recommended is to prevent possible shoot through between the high side and low side FETs.

    If it is a high side predriver fault, we will have to investigate further.
  • Hi Rick,

    How can I determine whether it is low or high side predriver fault, I mean from fault status register? Or shall I just try it in HW as datasheet recommends?

    Regards

    Uros

  • Hi Uros,

    The quickest method is to try it in hardware. It is disappears, you should be good.

    To determine if it is a high side or low side requires some amount of effort to capture the signals and interpret.
    Ideally you want a scope that can capture all 4 low side gates and can be triggered with nFAULT. Once triggered you can look for a voltage spike of approximately 1V or more approximately 2 to 2.2 us after the low was driven low. You can read the status register to determine which of the two low sides to examine.

    If you don't see any of the low sides, it is probably a high side.

    Feel free to send scope captures if you need help. They should be zoomed to 10us or less per division when capturing them.