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.
