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 currently working on a BLDC motor controller board with an STM32. Right now the STM32, the gate driver and the BLDC power are all powered by the same battery. I have an LED indicator which turns on when it is currently working, but as I turn it on, the LED immediately shuts off, with a couple of the MOSFETs’ flyback diodes blowing.
I’m sure my design works, since I used a very similar design with an arduino and gate driver powered externally.
I did later realise that in the datasheet it says the MCU should be powered by an external supply.
I’m so glad to see you persevere with this design.
Questions:
What is GVDD voltage - needs to be about 12 VDC?
How confident are you that the return for GVDD and the return for your uC are at the same potential?
What are the start-up conditions for your uC. For example, a worst-case situation would have the uC initialize with active pull up resistors commanding all DRV8300 drivers to turn on.
Have you considered adding a hardware-controlled delay for activation of GVDD. This would ensure that you uC in a ready state before the DRV8300 could respond.
As for single battery usage, have you considered modern-switch mode regulator (one of the new 7805 family replacements)?
What do you mean by “return” (I’m assuming you mean ground)? Yes they are both at the same ground potential.
I currently have a GPIO interrupt on the STM32 which is connected to a switch. When I switch it low, it starts the “startup” process of the motor.
The microcontroller controls when the motor starts operation. I am sure it is fine for GVDD to be connected at the same time as the microcontroller, until I manually flick the switch to start the motor.
Right now I am using this switching regulator for to power the 3.3V components, which works perfectly fine without the motor connected (oscilloscope tested).
My assumption is that the DRV8300 datasheet is correct and there is no way to power it with the same battery.
The DRV8300 seems fine, I’m pretty sure only the flyback diodes for INHA and INLA are destroyed. Not entirely sure why that has happened, because I am using the exact same MOSFETs as last time with no trouble. My guess is that shutting down the microcontroller while in use destroys the components.
“RE single battery; not without that regulator to step uC down to 3.3.”
Can you explain this? I am using one battery with the switching regulator to 3.3V. Is there a different one I should be using?
And no I did not verify commutation with resistors, I already verified the waveforms with oscilloscope for each phase without the motor connected and seems to be in order. Problem is the motor shorts the microcontroller while in use.
“You can feed the esp with a diode and place a cap directly across the esp. That way transient voltage drops won’t make it all the way to the esp. The cap obviously needs to be large enough to supply the esp during those glitches.”
Hi @tomz0840 ,
I’d humbly guess (I can be wrong) that what happens here is that while your MCU is in reset, all the half-bridge outputs are completely OFF, thus the running motor will dissipate all the EMF via the diodes… Should have pull-ups for INLx pins to ensure that all the LOW side FETs are conducting to brake the motor.
Cheers, heke
Potential, we are dealing with three different power supplies"
uC (3.3 VDC)
gate drive (about 12 to 15 VDC)
motor (application and driver dependent ranging from 7.2 to 500 VDC)
As I understand your design, the gate drive and motor are both driven by a battery (assume 14 VDC). That leaves the uC. It looks like you are using a buck converter.
Very strange that you are destroying the diodes and not the driver IC. I would expect a freewheeling motor to act like a car’s alternator with the diodes forming a three-phase bridge rectifier dumping the excess kinetic energy back into the power supply.
How do you differentiate between a destroyed MOSFET and a destroyed integral MOSFET diode?
Ideas:
uC conduction at improper times (most likely). The code may periodically glitch e.g., reset as mentioned in the article. You could also have an ISR prioritization issue assuming the driver calculations are performed in an ISR. NVIC? Optical isolation of the motor driver?
too small (unlikely given the bridge worked with Arduino)
high frequency (unlikely) but solved with a snubber
After thinking about it, the problem described in the article is probably the issue. The motor noise is probably high enough to shut down the microcontroller. I am assuming that the arduino worked fine as:
Either my power supply powering the gate driver and arduino provided a stable enough voltage to allow the arduino to work fine
OR
The fact that the arduino operates at 5V and any ground noise would still allow the mcu to operate with a lower voltage but high enough to still operate.
I am going to try to run the arduino again to see how much localized noise I see at the motor ground versus the ground at the microcontroller, so I can judge the size of bypass capacitor I need for the STM32 during the transients.
I honestly do not know why the diodes blew, and I am fairly certain that was was the component that blew up due to the minimal smoke and my multimeter claiming there was a short circuit across it, instead of the 0.5V diode voltage. Very confused since if it was truly shorted, then there would be a short circuit and should’ve had way more damage to the component when the battery was connected.
I’ve tried getting the arduino version working again. It worked a couple of times but most of the time this happens:
It seems to stop working after the startup phase which possibly suggests that the comparator is either damaged or is not getting enough charge? My guess is it’s the latter, as the very first time I started it, it had this behavior, but worked the second and third time. Right now I have a 0.1uF cap in parallel which may not be enough? I’m using my power supply to power the FET driver with 12V and an LM7805 to step that down to 5V for the arduino and the comparator.
If you are concerned with the hardware, I recommend you drive a DC motor with 2/3 of your bridge. This will allow you to use an oscilloscope to view the waveforms.
Add a buck converter to step down the motor voltage (e.g., 12V or 24V) to 5V or 3.3V for the MCU and gate driver. This provides a clean, regulated supply. Use star grounding or separate ground planes for power and control circuitry to avoid noise coupling. * Minimize the length of high-current traces and keep them away from control signal traces. Use thick traces or copper pours for high-current paths. Use separate planes for power and ground, ensuring good decoupling. You can see the following design of STM32 BLDC Motor driver.
I figured this out. The original design powered a low torque, high RPM motor which did not produce much noise, compared to the one I used. I added a simple low pass filter for each one of the phases which cleaned up the high frequency noise.
I did use a switching buck converter. I looked at others’ designs and often they move the microcontroller quite far away from the FET driver whereas mine was quite close (will probably change this). I still need it close enough because the back EMF signals and current sense should be close to have a more accurate reading.
How would you suggest to implement star grounding, when power is connected to one connector on the side of the board, whereas star grounding to me means it should converge to one central point? I tried seperating the power ground and signal ground a little bit, but I’m sure it could be improved.
I might just need more decoupling capacitors on the input of the buck converter to smooth out the input signal so the switching duty cycle remains quite consistent to keep up with any transients.
Blunt answer: don’t. Just use a solid ground plane, and in increasing order of emphasis, do not completely swiss-cheese it with vias, Do Not route traces on it, and DO NOT for the love of all that is good and holy, go carving gaping chasms in the ground plane.
This is a good example of the difference between theory and practice, and why it’s important to learn how to tell the difference between sources that are reciting theories and those speaking from a position of practical experience.
The star-ground idea is great in simplified theoretical diagrams and in purple-unicorn applications where none of the different points of one’s “star” need to talk to each other.
In practice, attempts to apply that theory are likely as not to make problems worse. Assuming that the blue transparency is your ground, the circled region represents a choke point through which the entirety of the motor current in all its vile, ugly noisiness (big green arrows) must travel. Because of the gap in the ground plane, the return path associated with things like your current sensing signals (skinny yellow arrows) also passes through that bottleneck.
If there are 3 people running jackhammers at the far end of a subway tunnel and one of their phones rings, what are the chances that you’d be able to recognize the ringtone? Kinda the same idea here…
