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.

DRV8312: Motor Driver FET Failing Closed

Part Number: DRV8312

During multiple operation modes, the DRV8312 fails with the low-side FETs closed. This happens during regeneration events as well as normal operation. This is a complex problem and I have documented a few operating conditions.

For config, the motor driver is connected to a 48V power supply, being driven by a micro-controller. It is configured for cycle-by-cycle current limiting with a 6.9A limit.

The failure occurs when resets are both on and off.

Our switching frequency is 20kHz and we reduced the maximum duty cycle to 90% (giving plenty of time for the bootstrap to recharge) and still observed the original failure condition.

As this is a highly complex issue, I imagine there are many variables to clarify. I have attached an image of my schematic to help with any obvious issues.

Motor Driver Sub-block

  • Greg,

    The first thing I would check for is voltage anomaly on the gate and phase nodes. What have you seen there?

    Looking at the schematic, I don't see anything alarming.

    Regards,

    -Adam
  • Hi Adam,

    When watching the gates, we did not notice any particular anomalies. The bus voltage would, at most, rise from 48V to 52V (measured directly at the input to the driver chip). Watching the phase nodes, we never noticed any sharp rises above these voltages. The most curious failure condition observed was while the gates were floating (DRV Resets On), we spun the motor and stopped it abruptly, which resulted in a broken driver chip (shorted to ground again)).

  • Greg,

    Spinning the motor and stopping it causes additional voltage spiking, especially when the outputs are High-Z this can damage the driver. Which node is shorted to GND?

    Regards,

    -Adam
  • Adam,

    Phases A and C are shorted to ground (Assuming through the FET). High side looks okay. This is just one of the many failures as this was the only failure to occur during High-Z (15+ chips during active loading). My original conclusion for the High-Z failure was as you described.

    We actually managed to get some readings during operation and we observed the readings below. Yellow is bus voltage and Blue is phase voltage. The motor driver did not break during this but it doesn't look good. For reference, we have 18 ohm Gimbal Motors.

  • Greg,

    I cannot gather much information from the scope image unfortunately. 

    Do you have any additional information?

    Regards,

    -Adam

  • Adam,

    What information would you like me to specify? I would like to give you the best information I can related to the problem.

    Best,

    Greg

  • Greg,

    The voltage spikes mentioned, what is the magnitude of these and where are they measured?

    Regards,

    -Adam

  • Hey Adam,

    The voltage spikes reached 75-80V and were measured at the phase outputs from the motor controller. We attached leads directly to the outputs.

    There's been a lot of debugging going on and we believe the issue might be one to do with integration although we're still not sure why it's causing the driver to fail. One of the damaged boards shows the 12V supply breaking down. Do you see how this might cause damage to the IC? (This doesn't happen on all damaged boards though).

  • Greg,

    The Absolute Maximum rating for the OUTx pins is 70V with respect to GND so likely some internals are being damaged by the 75-80V spikes.

    It's hard to say exactly what may fail when the ABS MAX is violated. I can say that the gate drive and pull-up/down circuitry for the gates is definitely at risk. 

    Have you tried adding any TVS or similar to the switch node to limit the over-voltage?

    Regards,

    -Adam

  • Hey Adam,

    We have not added external TVS diodes. We fixed an error that was causing a low-impedance path to form within another device that seemed to cause a cascading effect which damaged the DRV8312. I have, unfortunately, had to bench the process of debugging the error as our system is now stable and I have higher priority issues to solve. Thanks for your help. 

    I'll leave this post open in case something turns up soon (a new failure) but I think we have, hopefully, solved out issue.

  • Greg,

    If that's the case, could we close the thread? You can always use the "Ask a related question" button later if needed. 

    The thread will be preserved but leaving it open isn't an option.

    Regards,

    -Adam