We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
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.
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:
Minimize the gate trace length with little to no extra resistance.
Add over voltage and under voltage protection (can you please elaborate on this, and explain how that may occur)
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.
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?
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.
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.
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.
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.
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.
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.
I will ensure to make sure the duty cycle does not go past 95% as you suggested.
For undervoltage and over voltage do you suggest using a designated IC for that or some other circuit configuration?
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.
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?
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.
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.
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:
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.
Use a current limited bench power supply. If this is not possible, use series current limiting resistors for each winding.
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.
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.
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!
You likely already know this material, but you have inspired me to write the attached article. In the near future, I will have another showing how to get started with a breadboard version of the circuit.
So I followed what you suggested by using my current limited power supply. The issue, though is that the power supply I have only has a 10A limit, which was not sufficient current to move the motor (which I tried just now).
For your #3 point, I am using code that has already been tested by other arduino enthusiasts so I am confident that the code is not the issue.
#4: I am considering making a new board, but one worry I have is if I start to include more and more components onto the board, if it blows, it will be a lot more wasted time soldering and wasted components. Although that is the eventual goal, I am not confident enough with my components to do that.
#5: I could just change the code to limit the PWM, but still I believe this not the problem.
I am also struggling with the installation of the heatsinks as it is difficult to heat it up with the heat gun, and even when it is partially attached, it is very easy to accidentally rip off (annoying when I have to go to school every time as I dont have a heat gun). I feel that finicky heatsink and BLDC connections make it very easy for electrical faults and heat issues.
Moving forward, I am considering buying a BLDC that is designed to work with a few amps so I can use my power supply with it (to test the back EMF signals).
Also I will do more research to find mosfets with very low RDS on (ones that are affordable) to limit the amount of heat produced.
I have not given up just yet because I have made it work once and just need to strengthen the connections to limit problems.
The arduino code is on the link provided in the first message. There isn’t any other firmware other than the signals to start the motor and continue it. It cannot detect whether it is working or not.
Tried again with an A2212, but the traces seemed to destroy themselves, which has happened quite a few times now. I personally thought something was wrong with the rest of the system but I’m guessing the traces need to be a lot wider. Mine right now are 2mm but this website suggests (PCB Design, Fabrication, and Assembly Tools | AdvancedPCB ) that it should be around 10x that? Which seems unreasonable especially because there are ESCs which are smaller than the board I have (they possibly have more copper though).
It’s possible that there is still some other issue at hand as the fets burn up without even getting hot.
Operating without feedback never ends well for this type of system.
Years ago, I attempted to run a system open loop. The problem is associated with slipping a pole. If everything is works correctly, the rotating magnetic field is locked to a particular magnet. However as soon as we slip a pole the lock is lost. The rotor will try to catch up, but will immediately be pushed in the opposite direction as soon as the pole flies overhead. Instead of rotating, the rotor will vibrate. Without rotation, there is no back EMF. The end result is high current and destruction of the motor or driver.
Do I understand correctly that your system works at slow speed but stalls as the speed is increased?
I initially thought there was an issue with the mosfets themselves, but after some careful thought I reasoned that the finacky breadboard layout probably had too much impedance to the gate signals to be consistent.
I made the gate traces wider (15.7mils), tried to make them as short as possible. Put the bootstrap capacitors (probably tantulum for approximately 5-15Ω ESR) as close as possible to the BSTx and SHx pins. Going to put a large through hole electrolytic capacitor and ceramic capacitor between PVDD and GND (high side drain mosfet and ground) and a low ESR tantulum capacitor across the mosfet driver and ground. Also added the LM339 for the back EMF signals, and changed all resistors to be surface mount.
For close up images, I have this PDF here with closer ups (sorry, some are low quality for some reason). pdf24_images_merged (1).pdf (394.2 KB)
Ok I have some questions:
What can be improved of this design (specific examples preferably). Any traces which should not cross, bad shape, etc.?
What is considered a low ESR capacitor? Does it have to be a few millohms or a few ohms works well too?
Should I change any of the capacitor choices or values I made? For example, would a polymer capacitor be suited better for this application? I picked tantulum because they use little surface area and their ESR is written in the datasheets versus ceramic ones which generally don’t.
Is there a capacitance that is too high for the bootstrap capacitors? Because in this case the gate charge of the mosfets I am using are 63.9nC and even with 300uA of leakage current at 31kHz PWM (63.9+300/31 approximately 74nC/1V = 74nF). So anything above that is fine? With no downsides? So I arbitrarily picked 1uF capacitors for the bootstrap capacitors.
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.
You have beautifully answered that call to action! You will never look at a switching power supply motor drive or VFD the same way again.
In truth, you have passed my level of knowledge. All I can do is recommend is that you study and reverse engineer existing drives.
Reverse engineer the ESC recommended for the motor you are using.
Explore the datasheet for evaluation boards designed for motor control. Examples here.
Explore how others have solved the problem. For example, here is a related video series by greatscottlab.
Enjoy the process as you confront those learning challenges one by one.
