The ESP32 is easy to get working on a prototype, but turning that prototype into a product is where things go wrong.
One pin wired the wrong way can stop your finished product from booting, one antenna swap can leave you paying thousands for certification you thought you already had, and one skipped security setting can let anyone copy your firmware.
None of these show up while you’re prototyping, and by the time they do, they’re a lot more expensive to fix.
So I’m going to count down 11 ESP32 design rules you should never break in your product, and for each one, I’ll show you what goes wrong and how to get it right.
Table of Contents
Rule #11 – Keep 5V Signals Off 3.3V Pins
ESP32 GPIO pins are only rated for 3.3V, and unlike some older microcontrollers, they aren’t 5V tolerant.
That catches a lot of people when they move from sensor breakout boards to their own custom PCB.
Many breakout boards run at 5V, and they often tie their I2C pull-up resistors to that 5V rail.
Copy that circuit onto your board, and every high signal pushes 5V into a pin rated for about 3.6V at most.
That puts the pin outside its rating, and it might keep working for weeks before the damage finally shows up.
The fix is to power the sensor at 3.3V whenever it supports it, and tie its pull-ups to the 3.3V rail instead.
If the sensor truly needs 5V, add a proper level shifter between it and the ESP32.
Rule #10 – Never Trust Raw ADC Readings
On the original ESP32, your battery monitor can stop taking readings the moment Wi-Fi turns on, depending on which analog pin you picked.
That’s because the analog-to-digital converter, or ADC, is split into two blocks called ADC1 and ADC2, and the Wi-Fi driver uses ADC2.
Raw readings also aren’t accurate out of the box, because the internal reference voltage varies from chip to chip.
The readings get very nonlinear near the bottom and top of the input range, too.
Two boards measuring the exact same battery can disagree by close to 10% if you just use the raw numbers.
Put every analog signal on ADC1 pins and use Espressif’s calibration functions, which apply the factory calibration values stored in most chips.
Then keep your signal away from the ends of the input range, and check your readings against a known voltage.
Rule #9 – Lock In the Exact Module Variant Early
ESP32 modules that look identical on the outside can have very different memory inside, and picking the wrong one can cost you a board spin.
Each module comes in versions with different amounts of flash and PSRAM, which is extra external RAM for things like displays or audio.
The catch is that the memory inside can take over some of the chip’s pins.
On some ESP32-S3 modules, GPIO35 is free for your circuit, but on versions with a different type of PSRAM, it’s already being used by the memory.
So a button that worked on your prototype can stop working the moment you switch modules for production.
Flash size matters too, because over-the-air updates need room for two copies of your firmware.
Choose the exact module part number early, check which pins it reserves, and size the flash for two firmware images plus room to grow.
Rule #8 – Keep Circuits Off the Strapping Pins
ESP32 boards can boot perfectly on their own, then refuse to start once a sensor or button is connected to the wrong pin.
Those pins are called strapping pins, and the chip reads them every time it powers up or gets a hardware reset to decide how to boot.
The exact pins change between ESP32 versions, so check the datasheet for the chip you’re using.
GPIO12 on the original ESP32 is a classic trap, since pulling it high at boot tells the chip its flash runs at 1.8V instead of 3.3V, and most modules won’t boot.
GPIO0 held low at power-up does something similar, putting the chip into programming mode instead of running your firmware.
Keep external circuits off the strapping pins whenever you can.
If you have to use one, make sure the external circuit puts that pin in the state the chip needs to boot normally.
Rule #7 – Measure Battery Life on the Whole Board
ESP32 battery life estimates go wrong when they’re based on the chip’s deep-sleep current instead of the whole board.
The original ESP32 datasheet lists deep sleep at around 10 uA, which sounds like years of battery life.
But a cheap regulator like the AMS1117, which shows up on a lot of dev boards, can draw around 5 mA by itself, and that’s 500 times the chip’s sleep current.
Then add a USB-to-serial chip, a power LED, a battery voltage divider, and sensors that never fully shut off, and the total adds up fast.
Waking up costs even more, because connecting to Wi-Fi can take a second or more at around 100 mA, and that often uses more energy than all the time spent asleep.
Choose a regulator with low idle current, and switch off sensors and other circuits that don’t need to stay powered while the chip sleeps.
Then measure your whole board through a full sleep and wake cycle with a power profiler, which is a tool that records current over time.
Rule #6 – Plan for Factory Programming
ESP32 dev boards make programming easy because they include a USB-to-serial chip and an auto-reset circuit, so you just plug in a cable.
Many product creators copy that whole circuit onto their production board, or remove it without giving the factory another way to load firmware.
If that USB bridge is only there for programming, you’re paying for it on every unit you build.
Removing it with no plan is even worse, because now the factory can’t program your boards.
The fix is to add test points for the UART0 transmit and receive pins, the EN reset pin, and the boot-mode pin, plus power and ground.
The boot-mode pin is GPIO0 on the original ESP32 and the S3, but it’s GPIO9 on the C3.
Those test points let the factory press your board onto a fixture with spring-loaded pins and program it in seconds.
Newer chips like the S3 and C3 also have built-in USB that can handle programming, so check whether that fits your design before you add a separate USB chip.
Rule #5 – Turn On Secure Boot and Flash Encryption
ESP32 chips ship with their security features turned off, and a lot of products go to market that way.
Without secure boot, the chip will run any firmware that gets loaded onto it, so someone can replace yours with their own.
Without flash encryption, and with the programming port left open, anyone with access to those pins can read your firmware out of flash, along with any Wi-Fi passwords, API keys, or certificates stored there.
Secure boot checks that every firmware image is signed with your private key before it runs.
Flash encryption scrambles your firmware with a key that’s locked inside the chip, and the storage area where your Wi-Fi passwords and settings live needs its own encryption option turned on too.
The catch is that both features permanently burn settings into one-time programmable memory called eFuses, so a mistake during setup can leave a unit non-functional.
Plan for both early, practice the full process on a few test units, and build key handling into your factory programming steps.
Rule #4 – Only Use Antennas the Module Was Certified With
ESP32 modules come with a modular certification, which can save you most of the radio testing, but only if you follow the conditions in the module’s approval.
The biggest condition is the antenna, since the certification only covers the antenna types and gain levels listed in the module’s filing.
Modules with a U.FL connector, which is a tiny snap-on antenna connector, let you add an external antenna, and that’s where trouble starts.
Pick an antenna of a different type, or one with higher gain than what’s listed, and your product is no longer covered by the module’s certification.
That can mean extra testing or even your own FCC certification, which costs thousands of dollars and weeks of delay.
Check the module’s FCC filing first, and pick an antenna of the same type with equal or lower gain than the one that was approved.
Even with a fully covered module, your finished product still needs its own testing for unintentional emissions, which is the electrical noise every electronic product gives off.
And if your product is handheld or wearable, the module’s filing may require an extra RF exposure review.
Rule #3 – Keep the Antenna Clear of Copper and Metal
ESP32 module antennas are tuned with the assumption that they have open space around them, and a bad layout can wipe out most of your wireless range.
Espressif’s design guidelines call for no copper on any layer under or around the antenna, and they recommend placing the antenna so it hangs past the edge of the board whenever possible.
A metal enclosure, screw, or shield near the antenna can block the signal or detune the antenna, which means it no longer works well at the frequency it was designed for.
Batteries are the one people forget, since a lithium battery is basically a big piece of metal, and in a small product it often sits right next to the module.
The result is a product that connects fine near the router and drops out two rooms away.
Follow the module’s layout guidelines exactly, keep metal and the battery away from the antenna, and test range inside the finished enclosure.
Rule #2 – Start With a Precertified Module
ESP32 bare chips cost less than modules, and that price difference tempts a lot of first-time product creators.
But you still have to add the parts the module already includes, like the crystal, the flash chip, and the antenna circuit, so the real savings per board is smaller than it looks.
The bigger cost is certification, since a bare chip design needs full FCC radio testing plus the equivalent for other countries, and that often runs well over $10,000.
If your RF layout fails a test, you pay for a new board spin and another round of testing.
Even if you save a dollar per board, $10,000 in testing means selling ten thousand units just to break even.
So for a first product, use a precertified module, and save the bare chip for when your sales volume justifies the extra work.
And if size is the issue, look at Espressif’s smaller MINI modules before you take on RF design yourself.
Rule #1 – Power the ESP32 for Battery, Not Just USB
ESP32 power problems take the top spot, and since my whole TI career was spent designing power management chips, this is the one I most want you to get right.
Most dev boards run from a steady 5V on USB, and a simple regulator drops that to 3.3V with plenty of headroom.
A single-cell lithium battery is very different, since it starts around 4.2V when it’s full and drops to about 3V when it’s empty.
Many of the regulators used on dev boards need about 1V of headroom, so on a battery they fall below the ESP32’s 3V minimum once the battery drains a little.
Wi-Fi makes it worse, because the radio pulls bursts of a few hundred mA every time it transmits, and Espressif recommends a supply rated for at least 500 mA.
On USB, the regulator has plenty of headroom, but as the battery drains that headroom disappears, and each Wi-Fi burst can pull the voltage low enough for the brownout detector to reset the chip.
That’s how you end up with a product that works perfectly on USB and keeps resetting on battery.
The fix is to use a buck-boost converter that holds 3.3V whether the battery is above or below that voltage, or a low-dropout regulator if your product shuts off before the battery gets too low.
Either way, size it for at least 500 mA plus the rest of your board, add bulk capacitance close to the module, and test at your lowest battery voltage while it’s transmitting.
If you want an engineer to check your ESP32 design for things like strapping pins, antenna placement, and your battery power rail before you order boards, you can get that help from me and other experts inside my Hardware Academy.