H-Bridge Driver Circuit Critique Request

[Pack34]

I'm working on an NFET H-Bridge motor driver circuit.

Chosen MOSFETS:
Part Number: IRLZ34NSTRLPBFCT
Link: http://www.digikey.com/product-detail/en/IRLZ34NSTRLPBF/IRLZ34NSTRLPBFCT-ND/2441092
Why? I'm running the bridge over 5V PWM logic so I need FETS that can properly switch at that voltage level. Also, keeping it lower at 2V should take care of any issues with the charge pumps getting up high enough. The package is larger and beefier than needed but that's intended. The larger FET will make heat sinking easier. The low Rds(on) and input capacitanc should also keep the temperature down.

Chosen Driver:
Part Number: IR2302
Link: http://www.digikey.com/product-detail/en/IR2302SPBF/IR2302SPBF-ND/812495
Why? The driver only requires 5V which will eliminate a required additional voltage level. The driver also takes care of some dead-timing for me.

Schematic (see attachment)
The schematic is simple. I have two of the driver chips that will actuate easch side of the bridge independently. The protection diode for the boost is a standard 1N4001 diode and for the charge pumps I'm using some beefy 10uF ceramics to be sure that the high side gets to where it needs to go.

The input signal for the bridge is generated by an enhanced PWM signal from a micro-controller that takes care of dead-timing and signal inverting. The PWM frequency is set to 20kHz.

My main question, is if anyone can see something I'm missing with this design? Is there a fundamental characteristic that I'm missing? How's my component selection?

[Pack34]

I was originally using this circuit but the high side signal just wasn't as clean as I would like it to be. Using the drivers in the previous post solved that.

[zapta]

I have hard time to read the fine labels. Are you using N chan on the high side? If so, how do you drive it? The gate need to be high enough above the source. Have you considered to have P chan on the high side?

[fed0r]

The gate need to be high enough above the source.

That's the reason he uses a high side driver in the first place, to be able to use fast and powerful N-channel fets
As for the circuit, isn't 100 ohm  for gate resistor a bit too much for a 5v supply? I'm not used to low voltage stuff yet, but 100 ohm is about right for charging at 15v. And, personally, i think 10uf is a total overkill, but who knows. Maybe this appnote will clear this out. http://www.irf.com/technical-info/designtp/dt98-2.pdf And also, AN-6076 seems to be relevant.
I probably would stick a protection diode across every fet, since motors can indeed cause large voltage spikes which aren't good for fets.
Anyway, the gate waveform should tell whether it's done right, and we still need experts in this thread.

[Pack34]

I have hard time to read the fine labels. Are you using N chan on the high side? If so, how do you drive it? The gate need to be high enough above the source. Have you considered to have P chan on the high side?

In the updated schematic in my first post it's being handled by a half bridge driver. In the second I'm achieving the VBATT + 5V using the charge pump capactior attached to the motor channel and a diode protecting the 5V rail.

[Pack34]

The gate need to be high enough above the source.

That's the reason he uses a high side driver in the first place, to be able to use fast and powerful N-channel fets
As for the circuit, isn't 100 ohm  for gate resistor a bit too much for a 5v supply? I'm not used to low voltage stuff yet, but 100 ohm is about right for charging at 15v. And, personally, i think 10uf is a total overkill, but who knows. Maybe this appnote will clear this out. http://www.irf.com/technical-info/designtp/dt98-2.pdf And also, AN-6076 seems to be relevant.
I probably would stick a protection diode across every fet, since motors can indeed cause large voltage spikes which aren't good for fets.
Anyway, the gate waveform should tell whether it's done right, and we still need experts in this thread.

I can probably drop the resistor value. For the charge pump, I've tried 0.1u and 1.0u caps and it wasn't up until I went to 10u that the waveforms started to look right. Thank you for the app-notes. I'm giving them a read now.

Both schematics work and I can control a motor with them. I just can't shake the feeling that I'm missing something with them that could affect it under higher loads. I'm a bit of a novice with these and I appreciate input.

[granz]

What are the specs on the motors you are driving?

Also, what is your battery voltage?

Schematically, it looks like what you have is good, but you may need to play with some values.

For best performance, you'll want your gate drive voltage (GS) up in the 10-15V range, not lower at 2V (if I understand your intentions correctly).  The gate threshold voltage is really just when the FET *begins* to conduct, but for this type of application you want a much higher voltage.  Take a look at figure 3 in the FET datasheet: at 2V VGS the FET is just barely on.

Also, Increasing your switching frequency to something like 40kHz will reduce the requirement for the bootstrap cap.  Of course, higher switching frequency means more switching losses, so it's a trade off.

Hope that helps.

[Pack34]

I'm using a single 24V motor with an expected output current of 6-12A.

For the FET thresholds, is there a rule of thumb for the recommended delta? With these drivers (and in the circuit on my second post) I'm achieveing the VBAT + 5V which elevates me to twice the threshold voltage. I'd like to try to eliminate the need for a third voltage level, but if I'm forced into it to improve the reliability, then I am.

For deadbanding, is there a range that's just too much? I'm implementing it in the PWM signal before the bridge driver rather significantly and then the drivers implement their own. This provides me with everything shutting off and then the lower FET opens and then the appropriate high side FET.

EDIT:// My main issue right now is that they seem to work the majority of the time and then sporadically the bridge fails. I can drive the thing all day and then under the same conditions it'll blow. There's no way that I'm pushing the FETs past their limit. The maximum voltage is 55V and the maximum current is 30A, so I should be opperating at 50% max. Which should make the weakest point the motor and not the motor controller. This is making me look at how I'm driving the bridge itself.

The few key points that I'm thinking are the issue are dead-timing and the circuit driving it. For dead-timing, the microcontroller is taking care of it and the two PWM channels will never be high at the same time. My only concern with this is if there could be an issue driving the bridge low for too long.

I had thought for sure that using these newer drivers would have solved all of my issues. The waveforms on the scope look fantastic. Right now I'm thinking the cause of the failure would be related to the physical layout of the board. I'm moving from my schematic to the FET driver on the same board which means that I have the drivers on breakout boards that are wired into the motor controller. Being that the wires are rather long and I'm operating at 20kHz I'm thinking that this could be an issue. However, I don't want to spin another board with the hunch that I just need to shorten up all of my traces.

I was told that when it blew, the FET driver itself got really hot. My exact setup is that I have the driver on a SOIC8 breakout with a 10uF ceramic soldered to the floating supply voltage (Vs) and floating absolute supply voltage (VB). I also have a 0.1uF ceramic wired across Vcc a ground. Then I have the appropriate pins wired to their destinations with one driver attached to one side of the bridge and the other to other side.

EDIT2:// Ah, one thing I noticed was that the side of the bridge that failed was actually missing the gate resistor on the high side FET. This is the one that ended up blowing. I had used the footprint for the signal FET on the working side to hack in the gate resistor. I think I ended up flicking off the resistor on this side when troubleshooting why the drivers were not functioning properly. That issue was caused by insufficient capacitance on the bootstrap capacitor. This could very well be a cause of this board's failure.

[T3sl4co1l]

I never did like "logic level" FETs.  Yeah, they turn on at 5V, but not very hard, and switching takes forever (you need a solid driver to compensate, and you still only get so much due to internal limits).  That may or may not be a problem.

The only thing that jumps out at me is the lack of protective circuitry, and what your physical layout is.  Ideally, you'd control the motor by instantaneous current first and foremost, then adjust for average PWM or output voltage based on that.  That way, if the motor suddenly decides to be a short circuit or some approximation thereof, your FETs aren't left alone to chomp on it.

Protective circuitry includes something to clamp voltage spikes.  An H-bridge with MOSFETs is naturally constrained by the supply voltage (if the motor tries to drive power back into your circuit, the worst it can do is get dumped into the supply by the MOSFET body diodes).  But if the supply voltage isn't stable (say, there's a lot of stray inductance in the layout, or the bypass capacitor and wiring have high ESR and ESL), nasty awful things can happen.

What frequency are you running this at?  Are you at liberty to share your layout, and do you have any waveforms of this thing in operation, at a known load (not just like spinning the motor, but actually delivering real power)?  How hot do the transistors get normally, and what's happening when they fail, has it been running under heavy load for a while so they were getting really hot?  Or what?

Probably, you're at risk of two failure mechanisms: either just dumb thermal overload (the transistors get too hot, magic smoke is released), or avalanche failure (switching too much current, too suddenly, with too loose of a layout), where voltage spikes cause local failure inside a transistor, leading to further destruction.

Tim

[Pack34]

I never did like "logic level" FETs.  Yeah, they turn on at 5V, but not very hard, and switching takes forever (you need a solid driver to compensate, and you still only get so much due to internal limits).  That may or may not be a problem.

The only thing that jumps out at me is the lack of protective circuitry, and what your physical layout is.  Ideally, you'd control the motor by instantaneous current first and foremost, then adjust for average PWM or output voltage based on that.  That way, if the motor suddenly decides to be a short circuit or some approximation thereof, your FETs aren't left alone to chomp on it.

Protective circuitry includes something to clamp voltage spikes.  An H-bridge with MOSFETs is naturally constrained by the supply voltage (if the motor tries to drive power back into your circuit, the worst it can do is get dumped into the supply by the MOSFET body diodes).  But if the supply voltage isn't stable (say, there's a lot of stray inductance in the layout, or the bypass capacitor and wiring have high ESR and ESL), nasty awful things can happen.

What frequency are you running this at?  Are you at liberty to share your layout, and do you have any waveforms of this thing in operation, at a known load (not just like spinning the motor, but actually delivering real power)?  How hot do the transistors get normally, and what's happening when they fail, has it been running under heavy load for a while so they were getting really hot?  Or what?

Probably, you're at risk of two failure mechanisms: either just dumb thermal overload (the transistors get too hot, magic smoke is released), or avalanche failure (switching too much current, too suddenly, with too loose of a layout), where voltage spikes cause local failure inside a transistor, leading to further destruction.

Tim

Tim,

Thank you for your reply. I feel comfortable posting a cropped image of the layouts that I'm working with. Layout_a is the previous version that I'm hacking to work with the new driver circuit. Layout_b is what I'm moving to but haven't had produced yet. I'm currently using Layout_a but have the drivers connected in using some SOIC8 breakout boards. The general layout is that the FETs are on the bottom and located as close to the motor and power connector as I could. The lone pad near the buck circuit on the top and the square pad at the bottom is the beefy battery filter cap that I'm using (330uF). You should be able to follow the circuit using the schematics found at the top of the thread.

The PWM feeding the drivers is at 20kHz. I can try to grab some waveforms before I head home. Under standard load it gets warm but not scorching hot. I did have some issues with the motor really heating up when it's run for periods of time but that was resolved when adding an inductor in series with the motor. I wasn't around when the bridge failed but I was told that the drivers were exceptionally hot. This had occurred after extended use.

For protection circuity on the bridge, do you have any suggestions or reference designs I can look at?

[Pack34]

Here's some waveforms of the board with no load. I disabled the main power going to the board and wired in logic power in order to get the waveforms. I wanted to be able to look at what's going on before applying main power. If there was a glitch somewhere then it would have immediately blown.

Bridge Waveforms
-----
scope_2: Motor Forward
scope_3: Motor Backward
Yellow is low side channel B
Green is high side channel B
Red is low side channel A
Blue is high side Channel A

Pwm Input waveforms.
-----
scope_4: Motor Forward
scope_5: Motor Backward
Green should be channel A
yellow should be channel B

Timing measurement
----
scope_7:
For deadbanding, I measured 3.4us

[T3sl4co1l]

This is all with zero volts 'main battery', right?  So in scope_2 and scope_3, the high side gate drives are *just* the gate drive?

Are the green and yellow both supposed to be overlapping positive like that?  The red and blue appear to be pleasantly apart.

Or... is it actually, Ch2 = HS A, Ch3 = LS A, Ch1 = HS B, Ch4 = LS B..?

It shouldn't be possible to convince an IR2302 to produce the waveform pairs green-yellow, and red-blue, respectively.  (If that's your problem, it's certainly an interesting one!)

Also, on closer inspection, I see "Filtering capacitors between motar[sic] channels" 2 x 0.1uF, is that really between the output pins??  That's death right there.  You need a series choke first, then some cap to take the RFI out (if it matters).

Tim

[kxenos]

I think I would add 4 fast diodes to protect the mosfets as tesla coil suggested

[Pack34]

This is all with zero volts 'main battery', right?  So in scope_2 and scope_3, the high side gate drives are *just* the gate drive?

Are the green and yellow both supposed to be overlapping positive like that?  The red and blue appear to be pleasantly apart.

Or... is it actually, Ch2 = HS A, Ch3 = LS A, Ch1 = HS B, Ch4 = LS B..?

It shouldn't be possible to convince an IR2302 to produce the waveform pairs green-yellow, and red-blue, respectively.  (If that's your problem, it's certainly an interesting one!)

Also, on closer inspection, I see "Filtering capacitors between motar[sic] channels" 2 x 0.1uF, is that really between the output pins??  That's death right there.  You need a series choke first, then some cap to take the RFI out (if it matters).

Tim

Yes, in this test setup the VBATT for the circuit is 0 volts. I wouldn't put it out of the possibility that I mixed up some of the channels in the waveforms. I was at the office 14 hours at that point. I know green and yellow are low side (channels 1 and 2 of the scope) and red and blue are the high side gates. The ending waveforms with just the two channels are the inputs to the feta drivers.

As for the caps across the motor channels, the choke is in the motor line. I am working with a much higher quality motor so I can flick those off. On cheaper Chinese motors noise can mean death for a lot of my electronics. A small cap across the motor terminals and ferrite beading next to the motor tends to help significantly.

[Pack34]

I think I would add 4 fast diodes to protect the mosfets as tesla coil suggested

I completely overlooked that. I'll see if I have any in stock that I can slap in there in the morning. I wish I had read those app notes earlier.

[granz]

I think I would add 4 fast diodes to protect the mosfets as tesla coil suggested

I completely overlooked that. I'll see if I have any in stock that I can slap in there in the morning. I wish I had read those app notes earlier.

You actually don't need protection diodes when using MOSFETs because of the inherent body-diodes.  Take a look at the datasheet and you'll find that the Source-to-Drain current rating is also 30A via the body diode.

A quick test for your motor: Connect it directly to 24V and check the current when the motor is stalled (hold it from moving).  I've found that sometimes the current ratings are very optimistic.  Alternatively just measure the DC resistance.  That way you'll know if it's possible with close to 100% duty cycle to be exceeding the ratings of your FETs.

A few scope measurements across a small in series resistor (use differential probes, of course) would also probably prove useful.

[Pack34]

Here's the properly lined up waveforms.

Motor Channel A:
High Side: Red
Low Side: Green

Motor Channel B:
High Side: Blue
Low Side: Yellow

The first pair (scope_8 and scope_9) show each side of the bridge lined up. The second pair shows the low side of one channel lined up with the high side of the other channel.

[T3sl4co1l]

I was at the office 14 hours at that point.

Yikes, hope you slept well!

As for the caps across the motor channels, the choke is in the motor line. I am working with a much higher quality motor so I can flick those off. On cheaper Chinese motors noise can mean death for a lot of my electronics. A small cap across the motor terminals and ferrite beading next to the motor tends to help significantly.

I can't quite make out the net names very well, but if those caps are across the transistors, then each time they switch, they burn 0.5 * 0.2uF * Vbatt^2 microjoules (multiply by frequency to get power loss), probably with a peak current in the range of 10-20A.  I wouldn't think they would even last long, since the dielectric loss in an X7R type for example might desolder itself.  Maybe not such a big deal at 20kHz after all, but I don't see an inductor indicated, so it doesn't look right.  The inductor has to come first, then caps.  Then more caps at the motor if it's nasty.

Gate waveforms look fine then, now how about... like 5V current limited supply, and no load?  Then with known load?

Tim

[Pack34]

Here's the same setup with a 5V power supply.

[Odysseus]

Why is channel A not the exact complement of channel B?  I understand and can see the small amount of dead-time in each channel.

The sequence should be like this:
1. Channel A high-side and Channel B low side turn-on simultaneously.
2. Wait first half of switching period.
3. Channel A high-side and Channel B low-side turn-off simultaneously.
4. Wait deadtime (all mosfets off)
5. Channel A low-side and Channel B high-side turn on simultaneously.
6.Wait second half of switching period.
7. Channel A high-side and Channel B low-side turn-off simultaneously.
8. Wait deadtime (all mosfets off)
9. Repeat.

This would be achieved by making the logic signal to the drivers just the complement of each other.

[T3sl4co1l]

Nothing suspicious there, bootstrap seems to be working.  Not obviously ringing or exploding or anything, which is reasonable with deadtime and no load.

Now, with a load?  An inductive one preferably, say 10mH + resistance equivalent to full rated load.

Tim

[granz]

I looked back at the thread and didn't see it anywhere: I assume you are driving a regular DC (brushed) motor, correct?  After seeing your waveforms--why are you switching the direction of the current through the motor on a cycle-by-cycle basis?  Normally you turn on one or the other high-side FET and then modulate the opposite low-side FET.  Your gate drive waveforms look like how I would drive an AC motor with a variable frequency drive by changing the duty-cycle with time to produce a lower frequency sinusoidal current through the motor.

(See attached from Microchip App Note).

The outputs A/B/D/C from the Enhanced PWM module on PICs (shown in their datasheets) is essentially exactly what you want if you are driving a brushed DC motor, but the driver IC you have will generate complementary outputs to each side of the bridge (different).

[Pack34]

I looked back at the thread and didn't see it anywhere: I assume you are driving a regular DC (brushed) motor, correct?  After seeing your waveforms--why are you switching the direction of the current through the motor on a cycle-by-cycle basis?  Normally you turn on one or the other high-side FET and then modulate the opposite low-side FET.  Your gate drive waveforms look like how I would drive an AC motor with a variable frequency drive by changing the duty-cycle with time to produce a lower frequency sinusoidal current through the motor.

(See attached from Microchip App Note).

The outputs A/B/D/C from the Enhanced PWM module on PICs (shown in their datasheets) is essentially exactly what you want if you are driving a brushed DC motor, but the driver IC you have will generate complementary outputs to each side of the bridge (different).

Yes, I'm using a DC brushed motor. I'm using halfbridge mode on the ECCP module to drive a full bridge circuit. Essentially what is seen on this microcontroller's datasheet. PDF page 147, document page 145
http://ww1.microchip.com/downloads/en/DeviceDoc/39599g.pdf

Is there a detriment to this? I had originally planned to use just the two in order to minimize the amount of pins use on the PIC. I'm guessing this is why most of the bridge drivers I've seen have individual high side and low side inputs.

[Pack34]

waveforms running at voltage with no load. The bridge heats up slightly to 89 degrees F

[Pack34]

Some updated waveforms under load. The bridge heats up to about 102F and the motor eventually heats up to 120F when run for long periods of time.

I do seem to be seeing some glitches when moving in one direction but I'm not entirely certain if it's some sort of ghost on the scope or if it's a cause of concern.