Mystery issue driving load through NFET with microcontroller

Question

U1 is a microcontroller driving M1 to drive a load. I am running into some bizarre behavior and I'll try to include all the relevant information. Hope it's not too much.

• M1 is a logic-level FET.
• U1 is running off a 3.3V supply derived from the 3.7V battery in the system. There are no other power sources connected, like benchtop power supplies. All share a common ground.
• Although I have drawn the load as a resistor, that was more of I didn't see another option in CircuitLab for generic black-box load. I literally am driving a black box load as well, one of those high-voltage generators you can buy on eBay like this one. My understanding is that the first stage input inside their cavernous epoxied insides is some sort of blocking oscillator, and so it's entirely possible this load is not purely resistive. Just keep it in mind, but so far I don't think it's inductive as I haven't had any reliability issues with like back-EMF destroying the FET as if there was a solenoid inside the box.
• The load draws high current, about 2A.

Here's what's happening:

1. I am doing this on a breadboard. If I hook VGATE directly to the 3.3V supply to U1 (what the GPIO is pulling to), it works fine.
2. When I toggle a pushbutton that drives an ISR to pull the gate high, it does so very briefly and then the IC resets (I have the code blink a different LED at startup so I know it's reset). This made me suspect voltage droop on the supply lines due to the sudden surge from the battery.
3. To fix the suspected supply droop, next I added a ton of decoupling capacitors on both the input side of the LDO linear regulator and the output side. This did seem to help a bit but still would only drive the load for less than a second then reset.
4. I added an LED to the output and surprisingly this seemed to help. Perhaps it loads down the GPIO a little bit more, reducing voltage slew rate on VGS and thus reducing supply droop?

Now here's where things get weird:

• If I connect a Logic Analyzer probe to VGATE (I wanted to see what the waves looked like), it completely works! Damn you, Werner Heisenberg.

I have done a few experiments and it doesn't matter if both the signal probe and the ground are connected or just one (either, doesn't seem to matter). Yes, a single wire with no return path for current is somehow affecting this. Could this be some weird antenna thing going on, or noise coupling onto the wire which might be doing something? I will say that since I am breadboarding, my wires are getting a bit long, nothing longer than 6" though.

It also doesn't matter if the logic analyzer is plugged into my computer or not (USB logic analyzer, Saleae Logic Pro, if it matters). I was thinking at first maybe there was some different ground potentials going on, though I'd expect the ground in the analyzer to be isolated from my PC USB port. Either way, with a single wire connected I don't see how current can be flowing in or out of that wire anyway and thus doing anything.

Anyway, I'm banging my head against the wall trying to figure this out and figured sometimes it's not good to work in a vacuum. Thanks to anyone who can help me out.

EDIT: Testing the idea again that CGD coupling might be turning off the FET, I tried to make the cap to ground there larger with a cap on VGATE to ground. Though this didn't work, I notice that if I just touch the top of the cap (it is electrolytic), the circuit works again no problem.

So, touching my body to the top of the cap fixes the issue. Putting a wire from a logic analyzer on that net (either GND or VGATE) fixes the issue. And putting an LED load on the GPIO pin also helps (but doesn't completely fix it).

What theory could possibly explain all three and why they fix it?

EDIT2: Getting somewhere... taking Spehro's suggestion that the di/dt from switching such a large load could inductively coupling, I put a large RC filter on VGATE so that would limit the di/dt switching. What I find is that, all else unchanged, the LED on the GPIO slowly dims brighter until the FET is fully on, and when the HVGEN sparks, the micro resets. If you record video of the circuit on a phone, the picture is noisy due to the large EMI.

I basically think the EMI from the sparks is resetting the microcontroller independent of di/dt spikes or other events like this. For some reason when I touch the capacitor on VGATE, the problem goes away. Is it possible I'm a large body that "absorbs" the EMI somehow and thus the micro does not reset?

If so, how can I fix this permanently, short of touching the circuit at all times? ;) Is there some way without enclosing the entire PCB in a Faraday cage?

Answer 1

Note that in the IRF530 spec sheet (an older IR brand) the gate threshold voltage (gate turn on) is shown as 2V min to 4V max. So your 3.3V I/O line might not be so well suited. The mosfet may be listed as a logic level part, but this may only be related to 5V logic I/O's. So with a marginal gate drive any additional noise on the gate (inductively or capacitively coupled) could make a big difference.... See: irf.com/product-info/datasheets/data/irf530.pdf . If the microcontroller you're using is capable of running at a 5V level try that to confirm the gate drive issue.

You can also place bypass caps (in this case higher values, maybe 100uf or more) right at the "Load" +V point to ground. This would help to provide initial high current to the load and further prevent negative spikes from getting to the regulator. (If that is the cause of the Reset issue)

Answer 2

While all of the answers here were helpful in debugging, none of them turned out to be the complete story.

In short: I needed to shield the microcontroller from EMI with a Faraday cage.

As noted in my second edit, putting excessive gate load on the MOSFET to limit the di/dt showed that it wasn't the spike in current (since I limited it by limiting Vgs slewrate), but rather when the device sparked, the EMI from the device caused it to reset.

Spehro's suggestion to not do this on a breadboard was apt, and proper layout on a professional PCB (including lots more decaps and proper star grounding techniques) did dramatically help the issue. These techniques alone would allow the device to run without resetting, as long as the HVGEN was not directly on top of the microcontroller.

However, when placing the unit directly on top of the PCB (the HVGEN unit is fully insulated), there was still enough EMI that the proper layout could not overcome and it would reset again.

The only thing that fixed it for good even with it sitting straight on top was an EMI shield like this one. Thankfully I put a footprint on my PCB for this, just in case, hoping I wouldn't have to populate it, but doing so was the trick. A full Faraday cage around the microcontroller fixed the issue.

Answer 3

You know you shouldn't be doing this kind of thing on a breadboard.

Try adding a 10K or so resistor in series with the gate. You may be getting spikes coupled from the drain to the gate which are upsetting the micro, or spikes below ground due to inductance from your breadboard setup. Or there is a bypass capacitor in the black box which if you switch too rapidly will cause the micro to reset.

You can diagnose the latter if you put a pushbutton switch from the gate to the +3.7 (disconnect the port pin) with the micro running-just that one connection broken- and see if pushing the switch a few times resets the micro (the 10K will discharge the gate charge).

Also make the connections between the source, the battery (-) and the ground wire running to the breadboard outside the breadboard, or at least use an isolated set of connections to tie them together at one (and only one) point, which is then jumpered to each of the three.