PCB design - high side switch causes VCC drop (controller reset)

Hello everybody,

I'm facing an issue with a PCB which I can't seem to debug, so I'm reaching out to you good people.

Background:
The board in question features a high side switch, which connects four analog sensors to VCC, as well as the SD-card module of the circuit. I built the complete circuit on perfboard before sending the pcb out for production and the system worked like a charm.

I then proceeded to order and build an SMD version of the circuit to have a cleaner and more compact system. Initially, I thought everything was working fine - after building up the PCB and testing it with my firmware, all stages seemed to work well. At that point, I had not yet recieved the SMD JST sockets though, so I couldn't connect the analog sensors properly and just manually connected the signal input pads of the analog sensors to different volages to check the analog readings, which came out as expected. The HSS did supply the correct voltage to the sensors and the SD module attached to the HSS was working fine as well.

HSS:


MOSFET: https://datasheet.lcsc.com/szlcsc/1808281739_Infineon-Technologies-IRLML2244TRPBF_C169763.pdf

Problem:
The problems started after soldering the JST sockets to the board and actually connecting the analog senors: As soon as a single sensor is connected to any of the four input sockets, the system VCC breaks down and the controller resets, the second the HSS tries to switch and connect the sensors + SD-card module to VCC. Using my "toy" oscilloscope (handheld DSO150), I was able to visualize what's happening. The VCC switched by the HSS climbs up to about 1.5V after switching and then stagnates with a slow decline, causing the controller to reset.

Observations:
I switched around all sensors and sockets, the problem is independet from the used sensors or socket number. A single connection is sufficient to make the problem appear.
To make sure the sensors aren't responsible for the issue, I replaced them with simple resistors across VCC and GND of the sensor sockets - even using a resistance of 10kOhm, the VCC drop occurs. Only once the resistance reaches mega ohm territory, the dropout no longer happens.

I have also removed the SD card module and the status LED of the HSS, neither of which made a difference.

Interestingly, the problem does not occur if I manually connect a sensor after the HSS has "finished switching". So the system does not reset if the load is connected once the HSS is already supplying VCC to the sensors.

Another thing that I noticed: The HSS makes a clicking noise when switching (at least is sounds like the noise orginiates there). With no attached sensors, the clicking noise is already audible, when the sensors are attached and the 220uF is in place (see below), the noise is significantly louder. From what google could tell me, this is a sign of an overcurrent scnenario, though I couldn't quite place the physical reason behind the clicking.

Successful workaround:
I managed to fix the issue by placing a big 220uF cap across the Arduinos VCC and GND. When the cap is in place, the HSS manages to switch VCC to the sensors and the voltage breakdown no longer occurs. However, upon switching VCC at the controller drops from 4,9V to about 4V. This sounds to me like there is a big inrush current going to the sensors, for whatever reason.
I tried to measure the current going to the sensor sockets with a makeshift shunt resitor: I connected a 10 ohm (smallest value I had on hand) and a 330 ohm resistor in series and measured the current flow with my multimeter, which gave me a reading of 13 mA. I then measured the voltage drop across the 10 ohm resistor with my multimeter and it gave me a relatively clean step response (no spike/transient) of about 0.12V, so same story here (12mA). I have a hard time imagining that this amount of current is the issue...

Circuit/board data
Unfortunately, I failed to save the production version of the eagle project and made some changes to the layout (switched around the analog pins, some minor touch ups in the layout). However, the concept of the analog stage of the pcb remains the same, so I would imagine the problem will still occur in the revised layout.

I do have the gerber files of the board in question, which show the orignial layout. The schematic of the HSS stage and the sensors have been slightly modified (changing the input pins of the four sensors, status LED connected to A0, adding a missing resistor pad to the status LED of the HSS in the new layout).

I did add the missing resitor for the HSS LED manually on the current PCB

I used the sparkfun Design Rule Check on the board before sending it out for production, it did not give me any issues. The ERC of the circuit also didn't give me any warning despite the obvious ones (unconnected unused pins etc.)

Gerber files of the current defective PCB:
Watering_System_3.1_2022-01-06.zip (317.1 KB)

Schematic (new revision):
Watering_System_3.1.pdf (57.0 KB)

Eagle project (new revision):
Arduino_Watering_System_3.1.zip (100.0 KB)

I really appreciate any help or feedback on my design, thank you very much in advance!

PS: I separated the GND plane of the analog sensors from the rest of the circuit, probably very unneccessary to do in this application, but I thought is was good practice.

I would seriously consider using a high side power switch IC which aren't really that costly.

Probably a more convenient solution. However, the application is low power and I'm trying to learn the basics here. A simple HSS should do fine in this application in my opinion. The theoretical current draw is very small (SD card plus four sensors).

How do things go if you disconnect S_HSS from the Arduino and jumper it to GND?

The HSS switches on when GND is connected to S_HSS (checked that). Before I cut up the trace on the PCB, what are your thoughts behind that step?

You connected S_HSS to GND, manually, and all is well?
Why start cutting traces?

Switch on spikes like this, which sometimes cause the processor brownout reset to activate, can happen if what the MOSFET is switching draws enough current.

Not really - the SD card would have high peak currents, especially when powering up. I suspect your MOSFET switch would have an order of magnitude slower turn-on time than an integrated IC solution, so the SD card is demanding high currents before your switch completely turns on.

You can "soften" the switching of the mosfet by wiring a 100nF capacitor between the gate and ground. This may help if the load you are switching has big smoothing capacitors.

Sounds like you are hard switching something with significant capacitance leading to massive inrush current spikes - this explains why adding lots of decoupling at the Arduino helps.

Switch soft - arrange that the rails rise in about 10 to 20ms, not a few microseconds, and all should be much less "exciting"! Try changing R1 to 100k so it works with the MOSFET gate capacitance to slew-rate limit the switching.

BTW, did I miss the part number to the P MOSFET ?

Okay, it is a IRLML2244TRPbF

Agreed.

I have found this slowdown of the MOSFET to be mandatory, without it the fast switch on of devices such as GPS will in a lot of cases cause a processor brownout reset.

I did a quick simulation of the "100nF" variant and the @markT "100k" variant;

100nF:

.
100k (assuming 570pF input capacitance for IRLML2244TRPbF) :


.
These are quite similar.

And if you compare with the sample rise times of a commercial load switch, e.g. https://www.ti.com/lit/ds/symlink/tps27081a.pdf

image

these timings fall in the lower middle of the example configurable range

Thank you everybody for your input.

@runaway_pancake: I thought you meant disconnecting S_HSS from the controller with the arduino in place, hence the trace cutting. I have removed the arduino from its PCB socket and just connected VCC and GND to the board. When connecting the signal pin of HSS to GND manually, the controller resets - just as when switching the pin D9 on the controller. The HSS still switches on though, with GND connected to R1/the gate.

@srnet, @dlloyd, @MarkT : That's the tricky thing - the problematic load doen't draw much current at all, neither does it have a high capacitance: The circuit works perfectly fine when ONLY the SD card is connected, but nothing across the sensor supply pads (like you said, the SD card has the much higher current draw of the two load types connected to the HSS). At the same time, with the SD card disconnected, but a 10k Resistor across VCC and GND of a sensor socket, the brownout does occur. Between this scenario, and the scenario with no load across the sensors VCC/GND pads, the capacitance of the switched load doesn't change. But in the first one, there is no brownout, while in the second one, there is one.

@6v6gt: I have tried placing a 100nF cap across the gate and GND, it doesn't change the behavior of the system unfortunately.

Again, I have used the same circuit on perfboard, same caps, same loads, same gate resitors, and everything was working fine. In the perfboard version, I'm using this MOSFET for the HSS: IRLIB9343PBF

That's why I suspect the board layout to be the issue here, but I can't see any obvious problems with the design (proper gerberfiles are uploaded in the initial post):

What colour led are you using here ?

image

The valves use green LEDs, the pumps blue ones. I calculated the resitors according to the Datasheets of the leds. The values of the gate resistors are 82 ohms.

Good that these are not red.
Can you force S_VALVE_2 on (5 volts) and measure the voltage at the gate of the Mosfet N-MF4

Placing the LED (with resistor) across the load would tell you much more than gate to GND.

The gate voltage of N-MF4 is 3.05V with a clean step response when switched.
I'm using a red LED on the HSS, but I measured the current draw and it's normal, I have also already tried removing it and the problem still occurs without the LED.

@LarryD: True, but I don't always have the 12V connected. I wanted the LEDs to work as well when only running on 5V VCC. Either way, the LSS work fine.

OK. What is the part number of this N channel mosfet. That performance appears to be quite good even for a logic level mosfet (if it stays cool under load, that is).