Brushless DC Motor Thermal Issues

I am trying to run this BLDC motor, but I am having a lot of trouble with the choice of MOSFETs I am using, and thermal management.

Here are the schematics of the wiring.
pdf24_images_merged.pdf (442.4 KB)

I am using an Arduino Nano connected to a DRV8300 FET driver, connected to all 6 mosfets. I connected the mosfets drains (296-47449-2-ND) to their own heatsinks (‎DV-T263-201ECT-ND‎) to dissipate power. I have a LiPo 4S battery for power.

(Code for Arduino Nano is here: How to determine (or improve) BLDC motor at lower speeds when using Back-EMF for timing the 6 step commutation? - Motors, Mechanics, Power and CNC - Arduino Forum)

Although the mosfet I chose has low RDS on, for startup, the HIGH A mosfet let out a flying shock and I could smell burning parts. Other mosfets may have been damaged too.

I am wondering if I picked the right mosfets because this motor was rated for a 70A ESC, and mine has a max of 110A (Tc), and 194A (Tc) with 188W Max (Tc) with 2.6mOhm minimum RDS on at 10Vgs, which should be fine especially with the heatsinks I picked. I know the wiring is right because I was able to get it to spin partially (but slower) with less powerful mosfets with amp limits.

Does anyone have any insight here? I have been working on this for a while now and cannot seem to get this to work. Thank you.


First off, FET current ratings don’t mean what they might seem to mean. This post walks through that. Your immediate issues probably don’t lie in that area, but once you solve those immediate issues, it’s a topic you which you may find yourself returning.

This sounds like a classic “put it all together, flipped the switch, and it went poof” situation. It’s a common milestone in the skills development journey, and most folks usually need to repeat the lesson a number of times before learning that one should expect any new design to have faults.

Sometimes these faults are in construction; a rogue solder blob somewhere, wrong component placed, part placed backwards, etc.

Sometimes they’re simple oversights of implementation; lack of attention to polygon fills for example, have resulted in unintentional connections between nets on more than one occasion. A person can also make unintended connections by bad routing choices; the segment of the layout highlighted below seems rather suspect…

And other times the faults are a result of poor design, which is an inevitable part of producing good (or better) ones.

Things to consider here along the latter lines would be protection for the FET gates against over-voltage, and whether the drive waveforms are suitable for the task. R(1,4,5) are shown in the schematic having a rather high value of 100Ω; that’s going to slow the high-side transition times substantially, possibly to an extent that would allow for shoot-through on any given leg of the bridge. The gate drive traces also seem rather scrawny. A person can get away with that sort of thing with flea-power FETs, but as scale and speed increase the impedance of the gate drive network needs to be kept low, in order to provide adequate current to switch the FET in a timely manner.

Thank you for your insight. From your response I should:

  1. Minimize the gate trace length with little to no extra resistance.
  2. Add over voltage and under voltage protection (can you please elaborate on this, and explain how that may occur)
  3. Consider the temperature effects to the RDSon and max package current.

I still feel like I am having trouble interpreting the information on the data sheets as those are all controlled tests at fixed temperatures, fixed Vgs and often fixed ID, although here the current is always changing due to the coils in the motor. There’s just so many factors to consider which affect the RDS on which can drastically increase the power and overheat.

I did try simulating on LTSpice with rough guesses, but the graphs never seemed like what I was expecting to see when comparing to an engineering textbook for example.

One last point is that I feel like the heat sinks which don’t directly connect to the drain tab (the ones I’m using) are not as good as the ones that do connect to the tab directly, so I’m wondering whether these make a significant difference or not.

Thank you.


For your #1 you have above referencing Rick’s statement.

Along with the length reduction you can also increase the width of the trace if possible to assist in the overall resistance/impedance decrease.

As for the rest I am not sure myself. Maybe @rick_1976 will have more insight.

After some thought I think the reason why the mosfet burns is because the high side mosfets have a way lower VGS than the low side mosfets (since the closest path to ground is through two inductors and through VDS of the low side mosfet.) Should I increase VGS as high as I can get it to minimize RDSon?

Hello @tomz0840,

Please allow me to interject on this thread.

By chance have you assembled a breadboard representation of the circuit? For example, this picture shows a MOSFET-based bridge arm based on the IR2110 driver IC. Two such circuits may be used to drive a brush type DC motor. With proper drive signals we have directional and speed control.

There are several reasons for my recommendation:

  1. The system is a good learning platform when operated at low voltage e.g., 24 VDC. It is forgiving when coupled to a current limited bench power supply.

  2. This is a low-cost way to gain experience without releasing too much magic smoke. This is especially important as it allows you to probe the various signals.

  3. The breadboard circuit will give you an appreciation of the high-power RF nature of the circuit. It’s surprisingly difficult to make it stable.

Tech Tip: DO NOT operate the driver with a 100% duty cycle. If you do, the bootstrap circuit will not charge. Without a good charge, the upper MOSFET will enter its linear range and quickly destroy itself. As a starting point, limit the PWM to approximately 95%.

As to your question about V_{GS}, use the same MOSFET for all six positions. Also, be sure to account for the bootstrap. To measure true upper gate drive requires a differential probe or two probes with smart oscilloscope featuring a math function to derive the difference.

Best Wishes,



First thing to do is check the referenced portion of the layout. It looks as if it shorts the gate and drain of the A low side FET, which would be problematic.

Maybe. Better though to first understand why a person might consider such measures. It’s not “length” of the trace per-se, it’s about the resulting source impedance of the drive circuit from the FET’s perspective.

Violating Vgs(max) pretty much guarantees a failed device. Planting a zener between gate and source to mitigate that possibility is a common practice, to the extent that many (not all) devices build it in.

ESD (electrostatic discharge) is one way a violation of Vgs(max) can occur.

Another way is by accidentally creating an RLC circuit from parasitic inductance of the traces and the capacitance of the FET gate. Keeping that circuit from oscillating is the main reason a person would bother with adding a series gate resistance.

Thermals are always a thing to consider, but things take some time to heat up. Failures of the “flip switch and it blows immediately” variety (which I understand to be the case here) more commonly point to a violation of electrical specs or design fault.

That’s the universe’s way of signaling to a person that there’s something worth learning about. A person develops competence in the field by confronting those “I don’t understand this” moments one by one. Manufacturers’ application notes are usually one’s best resource for doing that. This one might be worth a read, as well as the others it references.

Not likely. The Cbst(x) store charge to drive the high-side FETs, with the return path being via the SH(x) pins of the device. Leaving the high-side FETs on for an extended period of time can deplete the charge on those capacitors and cause issue, but that’s not the sort of thing which appears to be happening here. Studying the working theory of the gate driver may be beneficial; this application note and others like it may be helpful.

Understand that textbooks often/usually provide simplified examples in an effort to communicate basic principles; reality is often much more nuanced. Likewise, simulations are only as good as the information one feeds them; garbage in, garbage out. The trace on one’s oscilloscope is typically the best representation of reality available.

1 Like

Thanks for everyone’s responses.


  1. I am using a breadboard for all the low power circuitry, like the arduino and fet drivers and comparators, but for the mosfets I made a PCB board as it is expected to have high current, which I believe does not work on a breadboard without it getting destroyed.

  2. I will ensure to make sure the duty cycle does not go past 95% as you suggested.


  1. For undervoltage and over voltage do you suggest using a designated IC for that or some other circuit configuration?

  2. How would u suggest determining the resistances of the outputs of the FET driver. When I checked the data sheet it doesn’t state it clearly.

  3. Most important point: I realized that I did not include these connections at all, which could have caused the fet to destroy itself (charges have nowhere to go?). Could that be a potential reason why it immediately shocks itself before it even heats up?

Again thank you everyone for the advice.


  • That wire IS the bootstrap (to pull oneself up by the bootstrap). In this case, the upper gate is pulled up by that wire in association with the bootstrap capacitor (C_{BSTA}). The capacitor is “flying” with the source of the upper MOSFET. When the lower MOSFET turns on the bootstrap capacitor charges, When the upper MOSFET turns on the flying capacitor is the source of the for the upper MOSFET gate driver.

  • Correct, for long life the breadboard current should be limited. However, IMO, in the name of education and time, it’s OK to push things to the limits.

  • You may be interested in this post regarding the MOSFET. It is written from a static perspective but may be a good starting point to answer some of your resistance questions. You will find that the resistance data is in the MOSFET datasheet but requires a bit of detective work. It is also highly dependent on V_{GS}.

  • BTW, what microcontroller frequency are you using to drive the bridge controller? This should be in the 10 kHz to 100 kHz range.


I resoldered the board with new components (with the SHx connections) and it was able to spin for a brief time before stopping. My presumption is that the back EMF circuitry did not work, which was probably the reason why it stopped. After a few attempts the mosfet burst (probably from electrical issues or connection issues). The connections were pretty shotty, so I am going to try again, except without the heatsinks as they were a real pain to solder on (fell off a few times) and the board did not heat up at all.

@APDahlen for your info, the program I used had 31kHz PWM so that is between your 10kHz to 100kHz range which you suggested. Code is the same as this forum: How to determine (or improve) BLDC motor at lower speeds when using Back-EMF for timing the 6 step commutation? - Motors, Mechanics, Power and CNC - Arduino Forum

Hello @tomz0840,

A random thought - instead of driving the three phase BLDC motor and melting another set of MOSFETS, could you try to drive a brush type DC motor?

This could be done by shutting down one bridge arm (ground each gate to the respective source for each MOSFET). You could then drive the DC motor with the two remining bridge arms:

  • motor’s positive terminal to the center of bridge arm #1

  • motor’s negative terminal to the center of bridge arm #2

  • bridge arm number 3 is unused

This would simplify your setup and allow you to troubleshoot the simple H-bridge as opposed to troubleshooting the full three-phase bridge, the feedback, and the code all at the same time.



Thank you for your suggestion, but I’ve already powered a DC motor using an H bridge at my school, so I really want to try to get this high power BLDC motor to work.

It seems like the traces themselves were destroyed which means I will have to create a new design with larger traces and possibly some protection on the gate to source connections so it doesn’t blow. I am not entirely sure why this happened even though it was working partially just minutes prior.

My guess is that something was not connected well which caused it to draw a lot more amps than it should have.

Understood, @tomz0840,

You have already used a H-bridge to drive a DC motor. However, have you used your three-phase bridge to drive a DC motor?

Ideas for your consideration:

  1. Use the DC motor as a temporary load so that you can evaluation your circuit. With running the simplified circuit, you may be able to probe the circuit and discovery what is and is not working.

  2. Use a current limited bench power supply. If this is not possible, use series current limiting resistors for each winding.

  3. This may or may not be applicable to your situation: The Arduino is a capable device, but you need to be very careful with blocking code. Use of interrupt is highly recommended as a missed cycle or jittery timing will not be tolerated by a high-speed motor.

  4. If you are contemplating another board revision, research the literature to determine the best location for the MOSFET gate resistors. Also, you may want to move the driver IC to the PCB. The high currents plus RF like signals associate with long wires can cause unanticipated oscillations.

  5. Research methods to protect or otherwise throttle back the PWM. Given the nature of your circuit, PCB and MOSFET destruction may be the appropriate response as this is a common “feature” for commercial Electronics Speed Controller (ESR). Then again, you may be able to do better.

While this is frustrating, you are certainly learning!

Please keep us posted.