The schematic mistakes I'm going to discuss today are small enough that most people never notice them until the boards come back.
Break these rules and you can get units that die in customers' hands, boards where the chips can't talk to each other, or a batch where some of the units never even boot.
Rule #9 - NEVER Skip ESD Protection on External Connections
A product that works perfectly on your bench can start coming back dead once it's in customers' hands and they start plugging in cables.
The cause is usually static electricity, or ESD, and a person can carry thousands of volts without ever feeling a zap.
Every chip does have some ESD protection built into its pins, but that protection is only meant to get it through handling and assembly at the factory.
It's not built to survive a customer who walks across the carpet and touches your USB port.
If you're selling in Europe, the CE lab will even zap your product with thousands of volts on purpose to make sure it survives.
So any signal that runs to a connector, or to exposed metal a person can touch, needs an ESD protection diode placed right where that signal enters the board.
For fast signals like USB data lines, pick a low-capacitance part so the protection doesn't mess up the signal.
Power inputs need a TVS diode, which stands for transient voltage suppressor, and it clamps voltage spikes before they can reach the rest of your circuit.
Those spikes happen more often than you'd think, because just plugging in a power adapter can make the input voltage overshoot for an instant, sometimes to almost double its normal level.
Pick a TVS that stays off at your normal input voltage but clamps below the maximum voltage your regulator can handle.
These diodes cost a few cents each, which is nothing next to a batch of returns.
Rule #8 - NEVER Drive a Load Straight From an MCU Pin
A typical microcontroller pin can only source or sink somewhere around 8 to 20 mA.
That means one bright LED is already near the limit, and a relay coil or a motor is way past it.
Hook a relay coil directly to a pin and either the relay never closes, or it does and the pin's output driver burns out.
Motors and relays add a second problem, because when the current through a coil stops, the coil kicks a voltage spike back into whatever was driving it.
A microcontroller pin won't survive that.
So put a switch between the chip and the load, like a BJT or a MOSFET for simple DC loads, or a driver IC for LED strings and stepper motors.
Then give every coil a flyback path, which is usually just a diode across it.
Rule #7 - NEVER Leave Boot or Strapping Pins Undefined
A batch of boards where most units boot fine and a few sit there dead in bootloader mode is almost always a strapping pin problem.
Many microcontrollers and wireless chips check a few pins, called strapping pins, right as they come out of reset.
The levels on those pins decide whether the chip runs your firmware or sits waiting in bootloader mode.
The ESP32 is the classic example, with GPIO0 and GPIO2 deciding the boot mode.
It also has a pin called MTDI that sets the supply voltage for its flash memory.
On the STM32, a pin called BOOT0 decides the boot mode.
The levels on those pins have to hold steady through a short reset window that's spelled out in the datasheet.
On the ESP32, those pins only have weak internal pull-up or pull-down resistors.
That means the usual failure is something else sharing the pin and overpowering that weak resistor during the reset window.
A common example is an SD card line on the MTDI pin, since SD cards need a pull-up on that line.
And on a chip with no internal pull-up or pull-down resistor at all, a floating strapping pin can read high on one board and low on the next.
The fix is to pull every strapping pin to its correct level with a resistor.
And if a pin does double duty, make sure nothing else connected to it can overpower that resistor during the reset window.
Rule #6 - NEVER Ship a Schematic Without Test Points
Testing a prototype on your bench is easy when you can probe right on the pins of any chip.
But leadless packages like QFN and BGA put their pins under the chip or flush with its body, where a probe can't get to them.
So even for your own testing before production, you need test pads on the signals you'll want to measure.
A factory has the same problem, because it tests boards using something called a bed of nails fixture.
That's a jig with rows of spring-loaded pogo pins that press onto the bottom of the board while software runs a test on every unit.
Those pins need pads to land on.
If you didn't put test pads in your design, the factory either tests a lot less than you think, or somebody probes every board by hand.
Add test pads on the power rails and on any signals you need for debugging and production testing.
Just keep them off the crystal pins and off high-speed lines like USB, because the extra capacitance from the pad can hurt both.
Draw these into the schematic now, since adding them after layout means moving parts that were already placed.
Rule #5 - NEVER Skip I2C Pull-Ups or Stack Them
If your I2C bus randomly drops bits, it can look exactly like a firmware bug, but a lot of the time it's really a pull-up resistor problem.
I2C is an open-drain bus, which means every chip on it can only pull the lines down.
The only thing that pulls them back up is the resistors you add.
Leave those resistors off and the bus is either dead, or it limps along on the microcontroller's weak internal pull-ups.
That's why nobody notices until you add a longer cable or a second module to the bus.
Every chip and every inch of cable adds capacitance to the bus, and a weak pull-up charges that capacitance back up slowly.
That means the line rises too slowly to reach a clean high before the next clock pulse, which limits how fast your bus can run.
The opposite mistake bites you the moment you start building with modules.
Most sensor breakout boards ship with their own pull-ups already installed.
Put four of those modules on one bus and you've got four sets of resistors in parallel, which turns 4.7k into about 1.2k.
On a 3.3V bus, that's close to the maximum current the I2C spec guarantees a chip can pull down, and on a 5V bus it's already over.
A chip with a weaker pull-down device then struggles to pull the line low enough, and that's where the dropped bits come from.
So pick one place for the pull-ups and remove them from any modules you add.
The bus speed and the total capacitance limit the highest value you can use, while the bus voltage and the chip with the weakest pull-down limit the lowest value.
Rule #4 - NEVER Assign a GPIO Without Checking What It Can Do
A pin labeled GPIO can still have a list of exceptions buried in a datasheet table, and on most chips it does.
The ESP32 has several pins that are input only, with no output driver and no internal pull-up or pull-down resistors.
Route an LED or a chip select to one of those, and it just never moves.
Analog is the other trap, because a chip might advertise a dozen ADC channels but only bring them out on certain pins.
On the ESP32, a whole bank of those channels stops working the moment you turn on Wi-Fi.
Before you wire anything, pull up the pin function table in the datasheet.
Then check every signal against it, whether it needs output drive, analog, PWM, or the ability to wake the chip from sleep.
Rule #3 - NEVER Skip Level Shifting Between Voltage Domains
Plenty of products end up with two voltage levels on one board, like a 5V microcontroller talking to a 3.3V sensor, or the other way around.
The mistake is wiring those signals straight across.
When a 5V output drives a 3.3V input, current can flow through the protection diode inside the chip and backwards into the 3.3V rail.
That pin might work for months before it fails, or it can lock up the whole chip.
Going the other way, a 3.3V output driving a 5V input is the sneakier problem.
A 5V CMOS input often needs at least 3.5V to be guaranteed to see a logic high.
A 3.3V signal falls short of that, which means it gets read correctly on some units and not on others.
That's the worst kind of failure, because it passes on every prototype and then shows up as returns.
Now, some pins are marked 5V tolerant in the datasheet, but check the fine print on that.
On some chips, that tolerance goes away when the pin is used for analog, or when the chip is powered off.
Level shifting doesn't always mean a dedicated translator chip either.
For a slow signal going one direction, from a higher voltage down to a lower one, a simple voltage divider made from two resistors does the job.
Going up in voltage, a small MOSFET and a pull-up resistor to the higher voltage does the job.
For anything faster, use a buffer or a level translator IC that's rated for it.
Rule #2 - NEVER Place a Crystal Without Load Caps Sized to Its Spec
A wireless product that fails at the certification lab, or a USB product that never shows up on the computer, can both trace back to two tiny capacitors next to the crystal.
A crystal's datasheet gives you a load capacitance, something like 12 pF or 18 pF.
That's the total capacitance the crystal needs to see to run at the right frequency.
The common mistake is putting two 18 pF caps on an 18 pF crystal.
From the crystal's point of view, those two caps are in series, which cuts their value in half.
The right way is to subtract the stray capacitance from the chip pins and traces, then double what's left.
For an 18 pF crystal, that usually lands you closer to 30 pF for each cap.
The crystal still runs with the wrong caps, just a little off frequency.
That's fine for a blinking LED.
But a radio builds its channel frequency from that crystal, so its transmit frequency can land outside the limit, and the lab fails you.
USB can fail too, because if the caps are way too big, the amplifier inside the chip that drives the crystal may not have enough gain to get it going, so the oscillator starts late or not at all.
Without a stable clock, the USB connection never gets set up.
Use the formula from the crystal datasheet, and if the chip maker doesn't give you a stray capacitance number, assume a few pF.
Then measure the frequency on your first prototype.
Rule #1 - NEVER Leave a MOSFET Gate or Driver Input Floating During Reset
I saved this one for last on purpose, because every other rule on this list can break your product, and this one can hurt somebody.
When power first comes up, most microcontroller pins start out as high impedance inputs, which means they aren't driving anything.
They stay that way until the firmware sets them up, which can take a few milliseconds, or a lot longer on chips with a slow boot.
The same thing happens every time the chip resets.
If that pin is the only thing holding a MOSFET gate off, the gate is now floating.
It drifts to whatever voltage leakage and nearby noise push it to.
That can be enough to turn the MOSFET partly on.
A MOSFET is often what switches power to a device outside the board, and if that's something like a motor, a heater, or a pump, it can be running before a single line of your code has run.
So every gate and every driver enable pin gets a resistor that holds it off, usually around 10k.
That's a pull-down for a low-side N-channel MOSFET, or a pull-up to the source for a high-side P-channel.
If you're using a gate driver IC, put the same resistor on its input.
And check the reset state of the exact pin you picked, since some pins turn on an internal pull-up during startup, and some even output a signal while the chip boots.
In those cases, you can't count on a pull-down resistor on the FET gate to keep it from turning on during reset.
Talk soon,
John
P.S. If you need help with schematics or PCB layout, then you can get help from me and other experts inside the Hardware Academy.