MOSFET latching problem

[robotix3]

This one is pretty convoluted so I'm going to try and break it down.

• I have a custom board with a uC, 2 H-bridges, Li-Po charging and protection circuitry, a radio, and some LDOs.
• I have used the exact motor driving circuit on 3 different designs, never any problems
• Motor driving circuitry consists of 2 AON7611 half-bridges http://aosmd.com/res/data_sheets/AON7611.pdf and 1 TC4428A mosfet drivershttp://ww1.microchip.com/downloads/en/DeviceDoc/20001423J.pdf
• Motor stall current is 5 amps max

Everything has been working great until this morning when I uploaded new code that had to do with the radio. After 30 seconds of motor movement, the Li-Po protection kicked in (probably short-circuit protection). I had to bypass the li-po circuit with a wire because I first thought the protection circuitry was being screwy (I was wrong). One of the four mosfets proceeded to let out the magic smoke, I cut the power (note that both half-bridges are driven high by default) . The mosfet was already welded to the copper so I couldn't desolder it, so I just forced it on again to see if it was over, but it just flamed up and took the other fet with it, and scorched my board.

SO I whipped up a new board (same PCB design) with the same components (literally) except for the driver of the exploding mosfet side. I hooked everything up except for the motors and everything looked fine on my scope, both motor channels seem to match in every way. I let it sit there and altered the PWM for a while, everything is fine. I hook up both motors and instantly the li-po protection kicks in, I bypass it, SAME mosfet smokes, I cut power, I get a little frustrated and bypass the protection circuit again, mosfet unleashes long red flame, PCB is scorched again.   

Some recap:

• I checked the IO driving both mosfet channels with my scope and both are fine
• Everything works until a motor is connected to the bad channel

TLDR:
Only one mosfet keeps shooting out long red flames. It seems both sources of one (of four) of the complementary mosfets are latching together.

Any ideas?

[KL27x]

Did you roll back to a trusted firmware when u made the new board?

[robotix3]

Well that's kind of the question, is there any code that can be written that would cause this? I can't think of any.

schematic -> https://drive.google.com/file/d/0B8gXTJQEnbqQbVpfZ0hlMmM4WjA/view

[Andy Watson]

Any ideas?

Er ...

when I uploaded new code that had to do with the radio.

Presumably this code was uploaded to the same micro that controls the H-bridge? If the modified code has altered the timing of the bridge control code ... pooooof!
Can you revert to the old code? Do you have access to an oscilloscope - if so, observe the output of the micro before connecting mosfets.

[robotix3]

If the modified code has altered the timing of the bridge control code ... pooooof!

But what scenario would cause this to happen with my circuit?

schematic -> https://drive.google.com/file/d/0B8gXTJQEnbqQbVpfZ0hlMmM4WjA/view

[Andy Watson]

If the modified code has altered the timing of the bridge control code ... pooooof!

But what scenario would cause this to happen with my circuit?

Hard to say without knowing the details of the code. But, e.g. if the radio code disables the interrupts to do some time-sensitive operation - it could lock-out the bridge control leaving the mosfets on too long. Or perhaps there is an unintentional write to the port that controls the mosfets. Could be any number of things.

[robotix3]

The mosfets can be 100% on and be fine. From what I understand there is no bad combination of driving the fets, what combination of inputs would cause this?

[rob77]

did you really tied the 2 gates (N + P) together ? how will you prevent a shoot-through ? it's not the best design for high power.
use a correct half-bridge driver with N-chan mosfets only - the half bridge driver takes care of dead-time to prevent shoot-through.

half bridge drivers - e.g. IR2101/IR2102 , IR25602 - and add any N-chan mosftes suitable for your load.

if you just tie the gates together then it might (and will !!) happen that the P-chan is not closed yet and the N chan is already opening...

[Andy Watson]

The mosfets can be 100% on and be fine. From what I understand there is no bad combination of driving the fets, what combination of inputs would cause this?

You claim to be using a "H" bridge configuration - I briefly scanned the data sheets but I didn't see any hardware interlock to prevent both upper and lower mosfets on the same leg of the H, being turned on simultaneously (shoot-through). (I can't access google drive )

[robotix3]

[mackrc1]

Not sure I entirely understand the situation but if everything was working fine before check that the radio isn't somehow dragging down the gate voltage or something. If its overheating that fast my guess would be the mosfet isn't fully on.

[robotix3]

From reading a little I'm pretty sure it's shoot-through. I understand the principles but never thought about the real effects.

Thanks guys

[langwadt]

If the modified code has altered the timing of the bridge control code ... pooooof!

But what scenario would cause this to happen with my circuit?

schematic -> https://drive.google.com/file/d/0B8gXTJQEnbqQbVpfZ0hlMmM4WjA/view

with the gate tied together and not separately controlled with deadtime  I expect you'll get massive shoot through i.e. both top and bottom
fet on at the same time shorting the supply during the switching.

if you increased the switching frequency it might just be enough to go from getting hot to letting out the smoke

[brumbarchris]

I am just surprised this has worked for so long without any problems!

[alsetalokin4017]

Well that's kind of the question, is there any code that can be written that would cause this? I can't think of any.

schematic -> https://drive.google.com/file/d/0B8gXTJQEnbqQbVpfZ0hlMmM4WjA/view

Well... apparently there is, because the old code didn't do it and the new code does!   


I like your troubleshooting technique.... Let's see if we can make it shoot out long red flames _again_ !!   

[rob77]

I am just surprised this has worked for so long without any problems!

it can work if the gate threshold voltages are not very low (the lower the thresholds are the the bigger the overlap is) , the mosfets will survive some brief shoot-through without any significant issues (little heat, shorter battery life...no big deal). but it's always a matter of time when you cross the line (due to change the rising/faling edge , temperature change) and the mosfets will fight to death

[brumbarchris]

Interestingly, out of this figtht between mosfets it is always the mosfet in the same position getting it all the time.

[rob77]

Interestingly, out of this figtht between mosfets it is always the mosfet in the same position getting it all the time.

because the one with lower Rdson has a much higher chance to survive.

[nuno]

You do have quite some flaws in that design but, is your motor ok?...

[robotix3]

is your motor ok?...

Yes motor is fine, coil resistance is within spec.

For those curious, I have switched to a very safe design using the DRV8701 http://www.ti.com/lit/ds/symlink/drv8701.pdf and two N-Channel arrays http://aosmd.com/res/data_sheets/AON7804.pdf

(These are the moments I wish I stuck with programming lol)