DRV8350: DRV8350 driver chip failures again

Hi Nathan,

Thank you for posting this question! I will need to look into the information and threads you sent, and I aim to provide another response by the end of the week.

Best,

Davis

Hi Nathan,

To confirm, are you only seeing the Fault bit set from among all the bits in the two status registers? The Fault bit should indicate that at least one of the other status bits in Fault Status 1 register or VGS Status 2 register is set, which in turn reports the type of fault you might be having. Additionally, is the driver failing once you begin to provide a PWM input to drive a motor, or does it fail after the device turns on without driving anything? Thank you in advance for the information.

Best,

Davis

Fault is the only bit set in Fault Status.  There are a few bits set in VGS Status 2, after the fault occurs it typically has the value 0x16d, however I'm not sure this is valid since the top bit there is the SC_OC bit which shouldn't be present in the DRV8350S since it doesn't have the the current sense amplifiers.  We've been seeing some bits set in VGS Status 2 (pattern 0x65) which were not setting the global fault status bit so I'm unclear of the role of this register.  As far as I can see the charge pump and low side gate drive voltages are all valid and stable.

I'm afraid I didn't think to check if enabling without running PWM made a difference, our application is fairly well developed and was running reliably at lower VM so it enables the chip and starts generating PWM automatically.  Unfortunately the last board has now suffered damage from excessive rework so I cannot run a deliberate test on this at the moment.

Hi Nathan,

I will have to look into why the VGS Status register is providing values that do not make sense and aim to provide further response by the end of next week. If you able to work with the device again, you can refer to this FAQ which explains how to debug faults from a strictly hardware standpoint: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1160331/faq-debugging-faults-with-hardware-variant-devices. This resource helps explain how to find faults if the nFAULT pin is pulling low but there are no status registers, which can be useful if your status registers are not providing expected values.

Best,

Davis

I'm familiar with the debug strategies as I've used the hardware only gate drivers before.  The problem is that whatever is causing this fault is internal to the gate driver since replacing the gate driver (and nothing else) fixes the issue.

After the fault occurs there is a limited time from startup (a minute or so) before the over temperature bit is set and then the chip shuts down I've not yet observed anything that helps me identify what part of the gate driver has been damaged.

I would agree, it appears that some damage is occurring internally causing the device to shut down. You mentioned reproductive energy from the system in your original post, could you please clarify where that energy is coming from and going to in the system? Additionally, are you using the DRV8350 with the buck regulator? It is possible that significant current draw somewhere on the chip is causing excessive heat and damage.

We're using the lowest pin count part so no current sense amps and no buck regulator, it's just the gate drivers and SPI interface.

We seem to mostly be getting failures around events that cause significant regenerative energy; servo suddenly hitting a mechanical end stop or the actuator being violently back driven.  Obviously good motion planning would relieve most of these but we want to be robust.  Initially we were getting a different failure mode; VDRAIN and VM were becoming dead short and the chip would stop responding (normally these two are connected together near the FETs but we cut a track to test where the failure was).  We added more bulk capacitance and a comparator which clamps VDRAIN at bus voltage +3.3V with a separate FET and power resistor.  In testing this has solved the complete failure of the chip and we now observe much better managed supply pumping when measured with a 'scope.  When the most recent failure occurred I was logging the VDRAIN voltage on the 'scope and it did not exceed 55V.

This e2e post on supply pumping will have more information on ways of mitigating the issue while braking: https://e2e.ti.com/blogs_/b/industrial_strength/posts/art-of-stopping-the-motor-vm-pumping. If possible, could you share scope images of at least one of the phase output currents as well as drain to source voltage across one of the high side FETs? There could possibly be an overcurrent event during these high regenerative energy events.

Yeah, I've read several articles about regenerative braking, VM pumping etc.  As far as I can see we are following all the guidelines.  Our application is currently static running from a bench supply which can't take input current so we have to use a resistor dump but like I said above we've tested this part of the circuit thoroughly and it's not the supply going out of spec.

This is one transition in the gate driver inputs, blue is the high side, yellow is the low side.  Note that low side has twice the volts/div that high does.

Here's the output for the same phase.  The only odd thing I've noticed (as you can see from the shadowed persistence) is that sometimes the output rises much more slowly than others.

In the first scope image, it appears there is ringing on the high side gate and the high side slews very quickly. Although the low side is not completely on before the high side turns off, there is significant gate voltage and there could be a current shoot-through event. The device should automatically insert a dead time period where both FETs are turned off before switching, but if you are using independent PWM then this feature is bypassed and won't prevent a shoot through event. Please refer to sections 1 and 8 of this FAQ which discuss IDRIVE and shoot through events: https://e2e.ti.com/support/motor-drivers-group/motor-drivers/f/motor-drivers-forum/1176539/faq-quick-guide-to-debugging-common-issues-in-bldc-motor-drivers. Slowing down the IDRIVE might be able to mitigate some of these issues. Please let me know if this helps.