The AI-Thinker ESP32-CAM has a pin problem, not a chip problem. Its header carries 16 pins, but only 10 of them are GPIOs, and the camera, the PSRAM chip, the microSD slot and the flash LED each claim some of those. Once you subtract them, a project is usually left with one or two genuinely clean pins.
This guide goes through the board the way you wire it: the physical header order, power, then each pin type (GPIO, UART, I2C, SPI, ADC), the pins the camera and PSRAM keep for themselves, and the boot pins that can stop the board starting. It also covers the two mistakes behind most 'my pin doesn't work' questions: using GPIO 16, which belongs to the PSRAM, and wiring a sensor to a pin the SD card is still using.
Everything here describes the AI-Thinker board with the OV2640 camera. Other ESP32 camera boards use different pin maps, covered near the end.
The Short Version
Of the 16 header pins, 3 are ground, 3 carry power (5V, 3V3 and the VCC output) and 10 are GPIOs. Here is what each GPIO is worth once the camera and PSRAM are running:
| GPIO | Verdict | Why |
|---|---|---|
| 13 | Best free pin | No camera role, no boot role. The SD card takes it only in 4-bit mode |
| 14 | Free if the SD card is unused | SD clock line |
| 2, 12, 15 | Usable with care | Boot-sensitive pins that are also SD lines |
| 4 | Usable, but it drives the flash LED | Also SD data line D1 |
| 16 | Do not use | Chip select for the on-board PSRAM |
| 1, 3 | Only if you give up Serial | UART0 TX and RX |
| 0 | Do not use | Boot mode select and camera clock |
That is where the common claim of about six free pins comes from, and it holds only if you skip the SD card and accept a few boot-time rules. With an SD card in use, one pin (GPIO 13) is genuinely clean.
Header Pin Order
The 16 pins sit in two rows of eight. The positions below run from the end of each row where the 5V and 3V3 pins are. Confirm against the silkscreen on your board, because clones sometimes print the labels differently.
| Position | 5V row | 3V3 row |
|---|---|---|
| 1 | 5V | 3V3 |
| 2 | GND | GPIO 16 |
| 3 | GPIO 12 | GPIO 0 |
| 4 | GPIO 13 | GND |
| 5 | GPIO 15 | VCC (output) |
| 6 | GPIO 14 | U0R (GPIO 3) |
| 7 | GPIO 2 | U0T (GPIO 1) |
| 8 | GPIO 4 | GND |
Power Pins
| Pin | Function | Notes |
|---|---|---|
| 5V | Power input | The recommended way to power the board |
| 3V3 | Power input or output | Works as an input, but many boards are unreliable powered this way. Use 5V |
| GND (x3) | Ground | Three ground pins, use whichever is closest |
| VCC | Power output | Not an input. A solder jumper beside it selects a 3.3 V output (the usual default) or a 5 V output |
Do not feed power into the VCC pin. It is an output, and on most boards it simply mirrors the 3.3 V rail.
Power is the most common hidden cause of pin problems on this board. Ai-Thinker lists a draw of about 180 mA with the flash off and about 310 mA with the flash at full brightness (at 5 V), and the WiFi radio adds short, sharp current bursts on top. Ai-Thinker recommends a 5 V supply of at least 2 A. A weak supply or a long, thin USB cable lets the rail sag, and that shows up as random resets, camera init failures and garbled frames, not as a clean power fault. In order of how often they help:
- Use a proper 5 V supply with short, thick leads to the 5V and GND pins.
- Add a 470 to 1000 uF capacitor across 5V and GND, close to the board.
- For battery builds, use a boost converter from a single-cell LiPo that can deliver at least 1 A in bursts, not a direct connection to the 3V3 pin.
- For deep-sleep or solar builds, size the supply for the camera and flash start-up spike, not for the average current.
A sagging rail matters most at power-on, which is exactly when the boot pins (covered below) are read.
GPIO Pins (Digital I/O)
This is the status of every GPIO that matters, independent of which subsystem also uses it. Cross-reference the SD card, camera, PSRAM and strapping sections for any pin marked 'shared'.
| GPIO | Status | Shared with |
|---|---|---|
| 0 | Not usable | Camera XCLK, boot mode select |
| 1, 3 | Only if you give up the Serial Monitor | UART0 TX and RX, programming |
| 2 | Usable if the SD card is unused, with care | SD D0, strapping pin |
| 4 | Usable if you can live with the flash LED | SD D1, flash LED |
| 12 | Usable if the SD card is unused, with care | SD D2 (4-bit mode only), strapping pin |
| 13 | Best default choice | SD D3 (4-bit mode only) |
| 14 | Usable if the SD card is unused | SD CLK |
| 15 | Usable if the SD card is unused, avoid loading at boot | SD CMD, weak strapping role |
| 16 | Do not use | PSRAM chip select |
| 5, 18, 19, 21, 22, 23, 25, 26, 27, 32, 34, 35, 36, 39 | Not available | Internally wired to the camera |
GPIO 13 has no strapping role and no camera role. The SD card claims it only in its default 4-bit mode, so once you switch the card to 1-bit mode (covered below) it stays free even with a card installed. For a button, a PIR sensor or a relay trigger, this is the pin to reach for first.
The SD Card and the Flash LED (GPIO 4)
The microSD slot uses the ESP32's SD/MMC peripheral, and the Arduino SD_MMC library starts it in 4-bit mode by default. That claims six GPIOs at once:
| SD line | GPIO | 4-bit mode | 1-bit mode |
|---|---|---|---|
| CLK | 14 | Used | Used |
| CMD | 15 | Used | Used |
| D0 | 2 | Used | Used |
| D1 | 4 | Used | Free |
| D2 | 12 | Used | Free |
| D3 | 13 | Used | Free |
GPIO 4 is also wired to the bright white flash LED, so in 4-bit mode the LED flickers on every card access. The fix is to start the card in 1-bit mode by passing true as the second argument. This is SD/MMC 1-bit mode, not SPI mode, although forums often call it that. It frees GPIO 4, 12 and 13, costs a little transfer speed that rarely matters for photos and short clips, and stops the flicker.
If you use GPIO 4 for something else after this, that device shares the line with the flash LED and the LED will react to it.
Programming and Boot Mode (GPIO 0, U0R, U0T)
The board has no USB port of its own. You program it over UART0, using either a USB-to-serial adapter or a ready-made ESP32-CAM-MB base, which carries a USB serial chip and plugs onto the header.
With an adapter set to 5 V power and 3.3 V logic:
| Adapter | ESP32-CAM |
|---|---|
| 5V | 5V |
| GND | GND |
| TX | U0R (GPIO 3) |
| RX | U0T (GPIO 1) |
| (jumper) | GPIO 0 to GND, for upload only |
For an upload, connect GPIO 0 to GND, press the reset button on the board and start the upload. When it finishes, remove the jumper and press reset again so the board runs your sketch. With an MB base the boot handling is usually automatic. If the upload hangs at 'Connecting...', hold the base's IO0 button, tap reset, then release IO0 once the upload starts. The full wiring, board settings and a working sketch are in the ESP32-CAM web server tutorial.
GPIO 1 and 3 can be used as ordinary pins after boot, but then the Serial output is gone, which on a board with no display is a real cost.
I2C and SPI Pins
I2C is not fixed to particular pins on the ESP32. Any two free GPIOs can be SDA and SCL through Wire.begin(SDA, SCL). With no SD card, GPIO 13 (SDA) and GPIO 14 (SCL) are the clean pair.
With an SD card in use, the clean choices run out. GPIO 14 is the SD clock, GPIO 12 must stay LOW at boot (an I2C pull-up holds it HIGH), and GPIO 4 puts the pull-up on the flash LED line. In practice you choose between the SD card and an I2C sensor, or you log over WiFi to a server and drop the card. The same limit applies to SPI devices: the ESP32 can route SPI to almost any pins, but this board has too few free pins to run a second SPI bus comfortably.
ADC (Analog) Pins
The analog-capable pins on the header (GPIO 2, 4, 12, 13, 14 and 15) all belong to ADC2, and GPIO 16 has no ADC at all. The ESP32 disables ADC2 whenever WiFi is active, because the radio and ADC2 share internal hardware.
In practice you cannot reliably read an analog sensor on this board while WiFi is connected. This catches people out when a soil moisture sensor or potentiometer reads fine and then goes flat the moment the board joins a network. If a project needs analog input alongside WiFi, use an external ADC such as the ADS1115 over I2C.
Camera Interface Pins
The OV2640 connects through a ribbon cable to GPIOs wired on the PCB. They never reach the header, but they explain why the ESP32 loses so many pins on this board. This is the AI-Thinker mapping used by Espressif's CameraWebServer example:
| Function | GPIO | Function | GPIO |
|---|---|---|---|
| PWDN | 32 | Y9 (D7) | 35 |
| XCLK | 0 | Y8 (D6) | 34 |
| SIOD (SCCB) | 26 | Y7 (D5) | 39 |
| SIOC (SCCB) | 27 | Y6 (D4) | 36 |
| VSYNC | 25 | Y5 (D3) | 21 |
| HREF | 23 | Y4 (D2) | 19 |
| PCLK | 22 | Y3 (D1) | 18 |
| Y2 (D0) | 5 |
That is 15 GPIOs consumed before you wire anything. Note that GPIO 0 appears here as XCLK, the same GPIO 0 that selects boot mode. That is why you ground it to flash the board: it is a shared, load-bearing connection, not a spare pin.
PSRAM and GPIO 16
The AI-Thinker board carries an external PSRAM chip, and the camera relies on it for frame buffers, which is what lets it run at higher resolutions without crashing. GPIO 16 is wired to that chip's chip-select line.
GPIO 16 is on the header and labelled as a normal pin, which makes it look like a free GPIO. It is not. Driving it, or loading it with a pull-down, can break PSRAM access, and the symptoms (camera init failures, crashes while capturing a frame) look nothing like a pin conflict. Treat GPIO 16 as reserved. Some libraries also default UART2 RX to GPIO 16, which is another reason to leave it alone.
Strapping Pins (Boot-Critical)
Strapping pins are GPIOs the ESP32 reads at the instant it powers on to choose its boot mode and flash voltage. If an external circuit holds one in the wrong state at that moment, the board can fail to boot, and because it only happens at start-up it is a confusing bug to chase.
| GPIO | Strapping role | Practical guidance |
|---|---|---|
| 0 | Boot mode select (also camera XCLK) | HIGH or floating to boot normally. Grounding it forces flash mode. Never tie it permanently low |
| 2 | Boot mode select (also SD D0) | Leave floating or LOW at boot. Do not pull it HIGH externally at power-on |
| 12 | Flash voltage select (also SD D2) | Must be LOW at boot. HIGH selects the wrong flash voltage and the board will not start. Beware I2C pull-ups here |
| 15 | Boot log output (also SD CMD) | Generally safe, but best left unloaded at power-on |
If you use GPIO 2, 12 or 15 for a switch or sensor, make sure the connected circuit cannot pull the line the wrong way during power-up. A pull-up resistor on GPIO 12 is a classic cause of 'works sometimes, won't boot other times'.
Onboard LEDs
The white flash LED (GPIO 4) sits next to the lens. It shares its pin with SD data line D1, which is why the flash flickers during card access in 4-bit mode. Anything else you connect to GPIO 4 flickers with it.
The small red status LED (GPIO 33) is active-low: it lights when GPIO 33 is driven LOW. It is wired on the board but GPIO 33 is not broken out to the header on the AI-Thinker design, so it is not a pin you can use for your own wiring without soldering to the board. Treat it as a status light, not an extra GPIO.
Planning Your Pin Budget
Five minutes of planning avoids discovering a conflict halfway through a build:
- List every peripheral and how many digital, analog and communication pins each needs.
- Decide whether you need the SD card. If you can log over WiFi, dropping it frees GPIO 2, 4, 12, 13, 14 and 15 at once, the single biggest lever on this board.
- Assign pins in order of risk: GPIO 13 first, then GPIO 14 (if no SD card), then 2 and 12 (fine once past boot, mind the strapping rules), then 15, then 4 (accepting the flash LED), and only then GPIO 1 and 3 (giving up Serial). Never GPIO 0 or 16.
- If the list still does not fit, you have hit a hardware limit. The fix is an I2C GPIO expander (on GPIO 13 and 14, with no SD card), or a different camera board with more free I/O.
Quick Reference: Every Pin, One Table
| GPIO | Camera | SD card | Strapping | Other role | Free to use? |
|---|---|---|---|---|---|
| 0 | Yes (XCLK) | No | Yes (boot mode) | Flash mode | No |
| 1 | No | No | No | UART0 TX | Only if not using Serial |
| 2 | No | Yes (D0) | Yes | If SD unused, with care | |
| 3 | No | No | No | UART0 RX | Only if not using Serial |
| 4 | No | Yes (D1) | No | Flash LED | If you accept the LED |
| 5 | Yes (Y2) | No | No | No | |
| 12 | No | Yes (D2, 4-bit) | Yes (flash voltage) | If SD unused, with care | |
| 13 | No | Yes (D3, 4-bit) | No | Best default choice | |
| 14 | No | Yes (CLK) | No | If SD unused | |
| 15 | No | Yes (CMD) | Weak | If SD unused, with care | |
| 16 | No | No | No | PSRAM chip select | No |
| 18, 19, 21, 22, 23, 25, 26, 27, 32, 34, 35, 36, 39 | Yes | No | No | No, internal camera use |
Bookmark this rather than memorize it. Checking takes seconds and saves a long debugging detour.
Common Pin Problems and Their Actual Cause
The camera works until you add a component, then stops initializing. The new component is probably on one of the camera GPIOs, on GPIO 0, or on GPIO 16 (PSRAM). Cross-reference the camera and PSRAM sections.
SD card writes fail once you add a sensor on GPIO 2, 4, 12, 13, 14 or 15. The sensor and the card are fighting over the same line. Move the sensor to GPIO 13 and switch the card to 1-bit mode.
Analog readings are fine until WiFi connects, then go flat or noisy. That is the ADC2 and WiFi conflict, not a wiring fault. Use an external ADC.
The board boots standalone but fails when a circuit is attached. Check whether that circuit touches GPIO 0, 2 or 12. Even a pull-up or pull-down resistor on the wrong pin can corrupt the boot read, especially on a marginal supply.
The flash LED flickers whenever the SD card is used. The card is in 4-bit mode and sharing GPIO 4. Start it with SD_MMC.begin("/sdcard", true).
Putting It Together: A Motion-Triggered Camera
A minimal PIR camera trap that respects every rule above: the PIR on GPIO 13, the SD card in 1-bit mode and nothing near the strapping pins.
Every pin choice here traces back to a rule in the sections above.
How This Compares to Other ESP32 Camera Boards
The pin scarcity in this guide belongs to the AI-Thinker design, not to every ESP32 camera board.
| Board | Pin situation | What to check |
|---|---|---|
| AI-Thinker ESP32-CAM | 10 exposed GPIOs, few truly free | Cheapest option, no USB without an MB base |
| Freenove ESP32-WROVER CAM | Different camera pin map | Uses the CAMERA_MODEL_WROVER_KIT definition |
| M5Stack camera boards | Different camera pin map | Use the matching CAMERA_MODEL_M5STACK_* definition |
| ESP32-S3 camera boards | Usually more usable I/O and native USB | Each vendor wires the camera differently, so use that board's own pin map |
If a project needs more than two or three free GPIOs alongside a working camera, an ESP32-S3 camera board is worth the extra cost. Do not assume this guide's pin numbers apply to it.
Quick Answers to Common ESP32-CAM Pin Questions
How many GPIOs does the ESP32-CAM have? Ten are exposed on the header (GPIO 0, 1, 2, 3, 4, 12, 13, 14, 15 and 16). Of those, only GPIO 13 is clean once the camera and SD card are in use.
Can I use GPIO 16? No. It is the chip select for the PSRAM the camera depends on. It is on the header, which is why people try it.
Why does my flash LED flash when I use the SD card? The SD card in its default 4-bit mode uses GPIO 4, the same pin as the LED. Initialize it in 1-bit mode with SD_MMC.begin("/sdcard", true).
Which pins can I use for I2C? With no SD card, GPIO 13 and GPIO 14. With an SD card, the options are poor, so consider logging over WiFi instead.
Can I add more GPIOs with an I/O expander? Yes. An I2C expander such as the PCF8574 or MCP23017 needs only two pins and gives you 8 to 16 more, provided you can spare GPIO 13 and 14 by dropping the SD card.
Why does my clone have a different layout? This guide describes the AI-Thinker reference design. Other makers use different camera pin maps, so match your board to its CAMERA_MODEL_ definition before trusting any pin table.
Can I debug with Serial if I use GPIO 1 and 3? Not at the same time. They are the UART0 lines. A common workaround is to use them during development with Serial disabled, then repurpose them in the final build.
Where to Go From Here
Once GPIO 13 is your default answer for 'which pin is free' and the GPIO 4 flash LED stops being a surprise, the next step is a working camera. The ESP32-CAM web server tutorial streams live video from this board. For the standard ESP32 pin rules that the camera board inherits, see the ESP32 pinout guide, and the ESP32 deep sleep guide covers running the camera on a battery.