DRV8353RS-EVM: Gate Drive Fault (GDF)

Alec,

Back driving is not recommended, especially during the initial motor identification because the algorithm does some fancy things to measure the motor parameters automatically.

I would recommend replacing the DRV if you can since it is likely busted.

Regards,

-Adam

Okay, just to be clear, it didn't receive any outside interference during initial motor identification -- only once it was running the constant spin loop provided with the GUI app.

Is it possible to hand solder a replacement, or would it require repurchasing the entire EVM (including the MCU daughter board)?

And just so I understand what happened, is it possible that it was providing a large amount of current in a "stalled" state while fighting with my hand, and then if my hand pushed it back one hall sensor state, the controller changed the MOSFET direction, and the large amount of current in the windings caused a voltage spike to overpower VM and force the stored energy back into the circuit?

Also, do you know what resistance I should be seeing across the high/low MOSFET VDS when powered off, to determine where the issue is?

Thanks,

Alec

Alec,

If you have hot air available it is possible to replace the chip by hand.

The situation mentioned above may have caused the damage but it's hard to say for sure.

I would measure GHx to GND and GLx to GND with the EVM disconnected from any USB/power supply and list all six values here, we can then compare it to a known good board.

Regards,

-Adam

Okay, I will give the hot air a shot; will be a new experience :).

I removed all external connections (except for hall sensor terminals, hopefully that doesn't matter), and the values I got were:

GLx<>GND 136-137kOhm

GH{A,C}<>GND 535-536 kOhm

GHB<>GND 391 kOhm (Issue here?; If so, does that mean I can just replace the MOSFET, or the DRV instead/in addition to?)

- Alec

Alec,

It's hard to say for sure but this does give us a clue that something is weird with GHB. I would try measure this once the device is removed from the PCB and compare it to a new IC off the board.

Regards,

-Adam

Okay, to be clear, are you saying take off the DRV part or the MOSFET?  Or in other words, what component(s) do you think could have failed?  I ordered additional DRV parts to compare, but not MOSFETs.

In the meantime, not sure if you have an extra EVM you can compare the above values to.

- Alec

Alec,

We only need measurements and replacement of the DRV, not the FETs, unless they have also been damaged. I don't have an EVM with me at this time but I will check later once I do.

Regards,

-Adam

Okay, got the chip (DRV8353RSRGZR) off the board.

Old Chip Measurements:

GND<>GLx ~3.7MOhm

GND<>GHx ~4.35-4.45MOhm

New Chip Measurements:

GND<>GLx ~3.7MOhm

GND<>GHx ~4.3-4.4MOhm

So not seeing any difference there.  From the schematic, I'm wondering if the MOT terminal pins (SHx) experienced a voltage spike/drop in order to force current through the MOSFET body diodes, and the DRV potentially got damaged that way?  However, I figured the MOSFET turn-on time would have been fast enough to mitigate this, and the capacitors would have absorbed the excess current on VM, though.

I also went through and measured all R_DS of the (off) MOSFETs while still attached to the board but DRV taken off: they were all ~.35-.36MOhm.

I tried attaching a new chip, but the board had even less response afterward (probably didn't get all the pins attached).  In any case, I went ahead and purchased another EVM.

However, I would still like to get a theory why this "broke" when back-driving, as how could someone use this in a back-driving application otherwise?

-Alec

Additionally, I want to point out that there is a presentation of Insta-FOC (which the GUI uses) that states it is robust in 4-quadrant mode (e.g. "back-driving"/generating), though Insta-FOC is a software solution and am not sure how that relates to the specific HW implementation of this EVM.  See 12:37 of "InstaSPIN: Expertise enabled silicon for 3-ph Motor Applications" under the Videos section at https://www.ti.com/tool/MOTORWARE.

If you guys want to comp me for the replacement EVM I just purchased through TI, I would appreciate it :).

-Alec

I've been thinking about this more, and I really can't understand why anything might have "burnt out".

The attached image is from the MOSFETs on the board (CSD19532Q5B), indicating that any excess opposing current in the motor should have escaped at least through the body diodes (if there wasn't a closed FET path) long before voltages on the MOT terminals would have reached high voltages -- assuming the body diodes react fast enough (I had the understanding that in general they do).  Therefore, no damage should have occurred on high-side sense inputs SHx of DRV.  The MOSFETs should have been likewise undamaged given that the spike currents/voltages would be well below their rated values.

Moreover, any excess energy (in the form of current) that was returned to the voltage rail, while I'm not sure would have been absorbed well/at all by the 12V off-the-shelf switched mode power supply, I can't imagine would have resulted in such a large voltage (on top of the existing 12V VM) that it would have exceeded the DRV's 75-80V max VM rating, especially because there are capacitors (~700uF) that I would expect to absorb the current.

I also just now measured back EMF on the scope when I was turning the motor at a faster speed to what it was being turned at before, and the relative EMF between two terminals peaks at less than +/-10V, so couldn't have been a spike from back EMF.

I'm just really confused why anything would have burned out given the scenario.  Even if full (or double in the case of "plugging") VM was applied across the motor terminals, the supply would have limited the current to 30A, which should have been acceptable for a brief moment had it occurred, or blown the EVM fuse otherwise.

Hi Adam,

Do you have time to look at this further, or is there someone else knowledgeable who could look at it?

Thanks,

Alec

Hi Adam,

Have you had a chance to test against an EVM board to identify the potential issue?

Thanks,

Alec

Alec,

Was the system performing the initial motor identification when the backdrive happened? Or had you already completed that process and the motor was simply running the speed loop?

Regards,

-Adam

Hi Adam,

This was after the motor identification process.  It occurred during the speed loop.

- Alec

Alec,

The protection you mentioned and 4 quadrant information is not implemented on the EVM in this version of Instaspin, you would need to integrate that with the C2000 team's help. Please reach out to them for assistance. 

If needed I can forward your post to them, let me know.

Regards,

-Adam

Hi Adam,

Thanks for clarifying on Instaspin 4-quadrant support.  

I am still seeking to understand what caused the EVM to throw an error after relatively "light" usage.  Could you please look into this?  I feel I have provided a fair amount of context and probing of the board (before I desoldered the DRV) and DRV (after desoldering).  If you need to consult with or forward me to someone more familiar with voltage and current dynamics of the driver circuit during operation (e.g. the author of this article:

The art of stopping a motor – VM pumping

In my last post we talked about methods to stop a motor . As a refresher, check out the table below. In this post, we will dive deeper into the VM pumping mechanism and how to avoid the…

By Wilson Zuo over 11 years ago in Technical articles > Industrial

Thanks,

Alec

Alec,

At this point it still isn't clear to me what got damaged or how. To address a few of your points above:

1. The body diodes won't always help you in the case of an overvoltage on the SHx nodes, yes they will react but not very quickly. Since the SHx node is directly connected to the motor back-EMF, it's possible to damage SHx before the body diode conducts. 
2. VM bulk capacitance would help some but not as much as may be needed to prevent damage due to spikes above VM. They do not smooth out current spikes like an inductor would.

Did you order another EVM?

Thanks for the reply, Adam.

1.  According to the DRV datasheet, SHx should be able to withstand ~100V, so I don't think that's what got burnt out.  Also, in my application, I am not concerned with the motor being externally driven beyond its "top speed" as defined by back emf.  However, I am surprised that you think the body diodes would not be able to turn on fast enough to dissipate residual energy stored in the inductive windings.  If that was the case, wouldn't the motor controller not even be able to function, because as soon as one current path of the 3-phase H-bridge was turned off, a spike would occur on SHx (unless, I guess, there was a low-side closed current path)?

2.  Re: VM, it was more about current flowing backwards through a body diode (as opposed to a voltage spike), though I suppose a build up of charge would cause a voltage spike.  I guess it's hard to talk about this without specific numbers/specs, but I'm pretty sure there would not be near enough charge build-up to cause any significant increase in the (large) bulk capacitance.  Though I don't know what the equivalent "RC constant" of the bulk capacitor charging would be, so maybe they couldn't absorb the charge fast enough and the VM line went way above spec.

I did order another EVM, but I am wary about using it, as I clearly don't understand enough about what is going on to prevent this one from malfunctioning as well.  The board that "broke" has already had the DRV chip removed, so I don't think it's really possible to debug further, save for probing individual components.  I just would have liked a theory as to why the GDF fault permanently tripped given the situation, which reiterating here, was:

- Initial motor identification completed as usual; no issues.  12VM, 15A max.

- Provided "loop" program (appProgram.out) started running as usual; no issues.

- I applied light resistance to the loop program and then released (potentially negative RPM, thus backdriving slightly); the program fought back and then continued as usual; did not seem to have any issues (had also done this in the past with no issues).

- I applied much more "rigorous" force against the loop program, though I'm almost positive I didn't spin the motor (in the opposite direction) fast enough to generate a back emf higher than VM (i.e., the voltage across phase terminals could have been up to 2*VM = 24V, and I measure the resistance across a single phase pair at ~.35Ohm; thus max instantaneous current could have been ~70A depending on the program loop's gate control).  After some periods of "backdriving", the program/board gave out.  I suppose it could have been due to fatigue/overheating, or to a backdriving event that went beyond some threshold.

If you know of any components or terminals I could measure in isolation for potential failure (beyond the ones we've already discussed/tried), that would be helpful.

-Alec