MOSFET latching problem - Page 1
Forum section: electronics / projects

author: robotix3
author_rank: Regular Contributor
timestamp: February 10, 2016, 10:57:47 pm
content: 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 problemsMotor driving circuitry consists of 2 AON7611 half-bridgeshttp://aosmd.com/res/data_sheets/AON7611.pdfand 1 TC4428A mosfet drivershttp://ww1.microchip.com/downloads/en/DeviceDoc/20001423J.pdfMotor stall current is 5 amps maxEverything 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 fineEverything works until a motor is connected to the bad channelTLDR: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?

author: KL27x
author_rank: Super Contributor
timestamp: February 10, 2016, 11:05:27 pm
content: Did you roll back to a trusted firmware when u made the new board?

author: robotix3
author_rank: Regular Contributor
timestamp: February 10, 2016, 11:09:23 pm
content: 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

author: Andy Watson
author_rank: Super Contributor
timestamp: February 10, 2016, 11:20:59 pm
content: Quote from: robotix3 on February 10, 2016, 10:57:47 pmEr ...Quote from: robotix3 on February 10, 2016, 10:57:47 pmPresumably 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.

author: robotix3
author_rank: Regular Contributor
timestamp: February 10, 2016, 11:24:22 pm
content: QuoteBut what scenario would cause this to happen with my circuit?schematic ->https://drive.google.com/file/d/0B8gXTJQEnbqQbVpfZ0hlMmM4WjA/view

author: Andy Watson
author_rank: Super Contributor
timestamp: February 10, 2016, 11:28:36 pm
content: Quote from: robotix3 on February 10, 2016, 11:24:22 pmHard 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.

author: robotix3
author_rank: Regular Contributor
timestamp: February 10, 2016, 11:32:52 pm
content: 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?

author: rob77
author_rank: Super Contributor
timestamp: February 10, 2016, 11:37:59 pm
content: 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...

author: Andy Watson
author_rank: Super Contributor
timestamp: February 10, 2016, 11:38:33 pm
content: Quote from: robotix3 on February 10, 2016, 11:32:52 pmYou 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)

author: mackrc1
author_rank: Contributor
timestamp: February 10, 2016, 11:48:12 pm
content: 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.

author: robotix3
author_rank: Regular Contributor
timestamp: February 10, 2016, 11:50:16 pm
content: 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

author: langwadt
author_rank: Super Contributor
timestamp: February 10, 2016, 11:55:55 pm
content: Quote from: robotix3 on February 10, 2016, 11:24:22 pmwith the gate tied together and not separately controlled with deadtime I expect you'll get massive shoot through i.e. both top and bottomfet 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

author: brumbarchris
author_rank: Regular Contributor
timestamp: February 11, 2016, 08:09:17 am
content: I am just surprised this has worked for so long without any problems!

author: alsetalokin4017
author_rank: Super Contributor
timestamp: February 11, 2016, 08:21:46 am
content: Quote from: robotix3 on February 10, 2016, 11:09:23 pmWell... 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_ !!

author: rob77
author_rank: Super Contributor
timestamp: February 11, 2016, 08:23:39 am
content: Quote from: brumbarchris on February 11, 2016, 08:09:17 amit 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

author: brumbarchris
author_rank: Regular Contributor
timestamp: February 11, 2016, 11:23:16 am
content: Interestingly, out of this figtht between mosfets it is always the mosfet in the same position getting it all the time.

author: rob77
author_rank: Super Contributor
timestamp: February 11, 2016, 12:19:22 pm
content: Quote from: brumbarchris on February 11, 2016, 11:23:16 ambecause the one with lower Rdson has a much higher chance to survive.

author: nuno
author_rank: Frequent Contributor
timestamp: February 12, 2016, 01:23:52 am
content: You do have quite some flaws in that design but, is your motor ok?...

author: robotix3
author_rank: Regular Contributor
timestamp: February 12, 2016, 04:34:44 pm
content: QuoteYes motor is fine, coil resistance is within spec.For those curious, I have switched to a very safe design using the DRV8701http://www.ti.com/lit/ds/symlink/drv8701.pdfand two N-Channel arrayshttp://aosmd.com/res/data_sheets/AON7804.pdf(These are the moments I wish I stuck with programming lol)