ESP32 GPIO and Strapping Pins: What Not to Use
The ESP32 has more GPIO than an Arduino, but a third of them come with fine print. Strapping pins set boot modes, ADC2 disappears when WiFi runs, and GPIO34–39 are input-only. Wiring blind guarantees a board that boots into the wrong mode.
> At a glance: 7 minute guide · part 2 of 10 in the complete IoT and ESP32 guide track · includes a worked example and a quick-reference table.
## Strapping pins set boot behaviour
GPIO 0, 2, 5, 12 and 15 configure flash/boot modes at reset. Held in the wrong state by your external circuit a pull-down on GPIO0, say the board enters bootloader or boot-loops. Use them for outputs only after boot, never for switches that ground at reset.
| P | i | n | ( | s | ) | | |
| — | — | — | — | — | — | — | — |
| S | t | a | t | u | s | | |
| S | a | f | e | | u | s | e |
| GPIO 0, 2, 5, 12, 15 | Strapping boot modes | Outputs only, careful with pulls | | | | | |
| GPIO 34–39 | Input only | Sensors, buttons, ADC1 | | | | | |
| ADC2 group | Blocked by WiFi | Avoid for analog while wireless | | | | | |
| GPIO 21/22 | I2C default | Bus pins | | | | | |
| GPIO 18/19/23 | SPI default | Bus pins | | | | | |
## Input-only and WiFi-shared pins
What this means at the bench. GPIO 34, 35, 36, 39 read but cannot drive perfect for sensors and potentiometers, useless for LEDs. ADC2 pins (GPIO 0, 2, 4, 12–15, 25–27) cannot be read while WiFi is active the number one “analogRead returns garbage with WiFi on” cause.
## A safe-pin shortlist
GPIO 16, 17, 18, 19, 21, 22, 23, 25, 26, 27, 32, 33 behave conventionally. Reserve 21/22 for I²C and 18/19/23 for SPI duties. Everything else is fair game for general I/O in most builds.
## How to apply this in your build
Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.
1. Mark strapping pins on your pinout printout first
2. Assign sensors to ADC1 pins (32–39) if WiFi is used
3. Keep I²C/SPI default pins for their buses
4. Check each external circuit does not pull strapping pins at reset
### Worked example
A project with a button wired from GPIO0 to ground “randomly” entered flash mode pressing it at reset looked like a bootloader request. Moving the button to GPIO 17 ended the mystery. Run the numbers yourself with the related calculator and the result should agree to within rounding.
> Practical note from the bench. Pinout discipline saves hours: highlight strapping pins in one colour and input-only in another on the datasheet printout before wiring anything.
## Field mistakes we see again and again
– Buttons or LEDs on strapping pins without checking boot state
– Expecting analogRead on ADC2 while WiFi is connected
– Driving loads from input-only pins
## Key takeaways
– Strapping pins set boot behaviour the foundation of this guide; revisit it if any measurement here surprises you.
– Input-only and WiFi-shared pins the foundation of this guide. Revisit it if any measurement here surprises you.
– A safe-pin shortlist the foundation of this guide; revisit it if any measurement here surprises you.
## Prerequisites and preparation
Before starting: mark strapping pins on your pinout printout first and assign sensors to adc1 pins (32–39) if wifi is used. Keep a calculator to hand every number in the worked example is reproducible. Total time including the bench steps: about 6–7 minutes.
## Who benefits most
Hobbyists meeting this topic for the first time, students who want the version with real numbers instead of abstract symbols. Returning engineers refreshing a corner of the craft. The mistake list alone justifies the visit every entry in it was learned the expensive way.
### Quick reference card
| Aspect | Where to find it in this guide |
| — | — |
| Core theory | Strapping pins set boot behaviour |
| Application steps | How to apply this in your build |
| Worked numbers | Worked example |
| Failure modes | Field mistakes we see again and again |
## How this fits the complete IoT and ESP32 guide track
This guide is one stop in the structured learning path. Start from the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page for the full map, or continue with [ESP32 first setup](/tutorial/esp32-getting-started) and [deep sleep power saving](/tutorial/esp32-deep-sleep-tutorial).
## Frequently asked questions
Which pins should a beginner just avoid?
0, 2, 12, 15 and the ADC2 group during WiFi start with 16, 17, 25–27, 32, 33.
What are GPIO 36/39 good for?
Input-only with ADC1 excellent for analog sensors that must keep working during WiFi.
Where do I go next?
Back to the [complete IoT and ESP32 guide](/tutorial/iot-esp32-complete-guide) pillar page it indexes every guide in this track and updates as new ones are published.
## Continue this track
– Building a foundation? The [iot, sensors & esp32 complete guide](/tutorial/iot-esp32-complete-guide) maps every step in order.
– Next: [How to Measure Room Temperature Accurately at Home](/tutorial/measure-room-temperature)
– Next: [DHT22 with ESP32: Accurate Temperature and Humidity](/tutorial/dht22-temperature-humidity-esp32)
– Next: [ESP32 WiFi That Never Dies: Reconnection Strategies](/tutorial/esp32-wifi-reconnection-strategies)
– Work the numbers: [battery life estimator](/tools/battery-life) · [LM317 designer](/tools/lm317-regulator) · [wire gauge checker](/tools/wire-gauge-awg)
## Practical working notes
The fastest way to internalise this topic is to change one variable deliberately and predict the result before measuring. Wrong predictions are the curriculum, they show exactly which mental model needs revisiting, and the bench grades honestly.
Component substitution is a legitimate experiment as long as it is deliberate. Swap one part, predict the effect, measure, and record. That single habit converts a parts bin into a teaching lab and makes every future guide in this track faster to absorb.
## Formulas and checks from this guide
Verification checklist for this track: watch RSSI before blaming code, measure supply current during radio bursts. Confirm MQTT topics against the broker log. Wireless bugs are usually power or signal problems wearing a software disguise.
Bookmark this page against your next build in the track. The checklist above is the same one used across 23 guides in this series.
## Experience notes
Location, then device, then measurement. Document the tree before flashing the first device.
Measure current during transmit bursts. Sags under load are power problems, no firmware fixes those.
## One last piece of advice
A note on radio current, which defines this track: transmit bursts draw in spikes, not averages. Scope the supply or log RSSI before concluding the protocol is at fault.
Working through Strapping pins set boot behaviourand Input-only and WiFi-shared pins with that habit in mind takes minutes, and it is the difference between reading about this topic and owning it.
Procirel