I have been making a brushless DC motor controller that is controlled through an ATSAMD21E16L and a MIC4609 mosfet driver. At low average currents of 2A or so, I drive the motor just fine, but when I give the motor a high current spike, like when trying to start it quickly to a high power, or increase the drive current from an already high current, the microcontroller will reset.
I currently have a setup where I drive the motor with 17V and a start-up duty cycle of about 33%, which causes the reset to happen reliably and instantly. I have used this reliability to probe all the pins connected to the microcontroller for anything suspicious, but everything appears normal. The reset pin has a small transient from 3.3V to 3.2V. The coil sense pins see the transients reaching no more than 1.5V. The current sense pin reaches no more than about 2V. The single-wire-debug clock and io pins also change only marginally. The PWM and enable values going to the mosfet driver also have small transients.
Basically, I can't find anything on my scope that goes at all out of spec, and yet the microcontroller resets reliably like this. I also have a separate board built up the same way with the same problem.
Since there is a fair amount of protection between the high current and voltage stuff driving the motor and the microntroller, I am starting to wonder if it is possible that EMI is somehow reaching inside the microcontroller to reset it? I really have no clue what is going on.
I tried adding a 100nF cap from RESET to GND, too, but this made no difference.
Any ideas about what may be going on or how to fix it is much appreciated!
EDIT: There is a 330uF electrolytic on +V_MOTOR (using the GND pad shown on the front render below). The motor power and ground connections are directly on the pads shown in this front render view. My hope is that the short low-impedance connections (aided by some extra copper wire on those strips) means the large motor currents have a short enough path to not effect the rest of the circuit too much.
I also don't have any interrupts enabled.
The logic power is a completely different power source than the motor voltage. The motor voltage now is from a bench power supply and the logic supply is from an Arduino.
Shorting RESET to +3.3V also did not help.
Conclusion: Changing the 4.7 ohm high side gate resistors to 100 ohm causes the resets to happen only half the time under my testing setup. So while I don't know exactly how the EMI is affecting the microcontroller, I do know that reducing the startup transients is helping.
Best Answer
Are you sure it's an actual reset though? It could be an EMI induced spike on another input that controls some sort of operating mode change in your MCU (in my case, it was the index line on the encoder input. If that thing misfires, it throws everything out of synch. It was happening on the encoder A and B inputs too but that just throws the encoder count off by a bit whereas something like the index line would completely make the MCU change operating states).
It could also be a brownout or ground bounce because I don't see any large (i.e. >470uF) decoupling capacitors for the motor currents.
It could also be EMI as it was the case in my circuit. When I ran into it, I was working on an FPGA so I was able to make a digital filter where all offending inputs (including the reset) would have to be stable for n-cycles before being accepted. On an MCU you can't do this so you would have to harden your MCU inputs by placing an R-C filter on the vulnerable input as close as possible to the input. There are other measures you can take too such as a tight PCB layout with good ground planes and small loops.
You can also help things by increasing the size of your gate resistors (or replacing them with ferrite beads whose impedance peaks at the ringing frequency you measure at the MOSFET gate pin). You can also add RC snubbers as well across your BLDC motor terminals or MOSFETs. All of the things mentioned in this paragraph work to slow the rise/fall times of transients in the power portion of your circuit which will reduce EMI.
But if it is EMI, I am not sure why you can't see it on the scope. In my case, I was able to scope the line and see it very clearly (but it is a very thin vertical line). Is it possible your scope isn't good enough or your measurement leads are too long?
EDIT: actually I think I lied. I don't remember seeing my EMI spike on the scope until AFTER I corrected the issue so the system could operate through the spike because if the system crashes you stop seeing anything and EMI spikes are spurios events that are difficult to trigger off of on a scope. You lose that critical tail end of the data where the untriggerable one-time event happens on a scope. You might need a DAQ running where you record high bandwidths for minutes so can scroll through all waveforms after-the-fact to see things. Mine was a software correction so it did not change the EMI itself so I could scope it after things were fixed. With a hardware solution so you might not see it on a scope after the problem was fixed.
If you're desperate, you can also reduce the size of your reset pin pull-up resistor with a capacitor to ground. Possibly even replacing it with a shunt so you can short-circuit it straight to +V. This is the most desperate of measures but simple to try out to confirm if it is EMI on the reset pin if you are unable to observe it on the scope. Unfortunately, this doesn't work on other lines that need to change states during operation.