Why Does My ESP32 Already Have Code on It? | Factory Flash

If your board starts blinking, opens a Wi-Fi network, or prints text to the serial monitor before you write a line of code, don’t panic. An ESP32 keeps firmware in onboard flash, so anything loaded at the factory, by the board vendor, or by a reseller stays there until you replace it.

“New” does not always mean “empty.” On microcontroller boards, the hardware may be new while flash still holds a test image, AT firmware, or a demo.

Some code is also meant to be there. The ESP32 boots from flash, and a normal layout includes a bootloader plus a partition table before your own app runs. The chip expects structured flash data, not a blank chip.

Why Does My ESP32 Already Have Code On It? Common board-side reasons

The usual reason is factory testing. A board maker may flash a program to blink an LED, print a serial log, test Wi-Fi, or check that the module, flash, and power rail work. Once that check passes, many boards leave the line with that firmware still present.

Another reason is reseller handling. Some shops batch-test boards before shipping. Some bundle boards that were set up for another buyer, then sold again as open-box stock. Others preload AT firmware because their customers want serial commands more than a fresh sketch slot.

A third reason is simple persistence. Flash memory is non-volatile. If someone flashed a sample sketch months ago, the board can still boot that same sketch today.

Factory test firmware is normal on many boards

Espressif publishes material for production testing, and that tells you a lot about what happens before a board lands on your desk. During production, manufacturers can flash firmware and run checks to verify radios, flash access, and basic board behavior. You can see that flow in Espressif’s production testing guide.

That does not mean every board ships with the same image. It means preloaded firmware is ordinary, so treat it as routine unless the board gives you a reason not to.

Bootloader code and app code are not the same thing

When someone says the board “already has code,” they may be talking about two different layers. Espressif’s bootloader docs and partition table docs show how the startup path and flash layout fit together.

• Bootloader code starts the chip and hands control to the right app image.
• Partition data tells the chip where app slots, NVS data, and file storage live.
• Application firmware is the sketch, demo, AT image, or test program you actually notice.

So yes, your board may have code by design, and it may also have extra firmware from factory handling or a prior flash. Those are separate things.

Boards from different sellers arrive in different states

An official Espressif dev kit, a board from a known brand, and a no-name clone can all arrive in different states. One may boot to silence. Another may blink forever. Another may start a serial log at 115200 baud. That spread often points to different vendor habits.

If the board identifies itself, enters download mode, and accepts a new flash cleanly, preloaded code is more nuisance than threat. If it resets in a loop, locks up, or behaves in ways that don’t match the board listing, then it’s worth checking what you bought.

What You Notice	Usual Reason	What It Means
Blinking LED on power-up	Factory test or demo sketch	The board was flashed before shipping and is running a simple app.
Text appears in Serial Monitor	Demo firmware or prior owner sketch	The flash holds an app that writes logs during boot.
Wi-Fi network appears after boot	Sample web server or setup firmware	The board has an app image, not just a bootloader.
AT commands respond	AT firmware was loaded	The seller may have prepared it for serial modem use.
Board restarts in a loop	Bad sketch, wrong power, or bad flash settings	Preloaded code exists, but the stored image may be broken.
Nothing visible happens	No LED on app pin or quiet firmware	The board can still have code even if it looks idle.
Upload fails until BOOT is held	Normal download-mode timing on some boards	This often comes from board design quirks, not bad firmware.
Old behavior vanishes after upload	Your app overwrote the old one	The earlier image was just normal flash content.

When Preloaded Firmware Is Fine And When To Pause

Most of the time, preloaded code is harmless. You can erase the chip or flash your own project and move on. That’s the normal path for hobby work, class labs, and bench testing.

Pause for a minute if any of these show up:

• The board listing promised one model and the serial output points to another.
• The chip ID, flash size, or PSRAM details do not match the product page.
• The board gets hot fast, resets at idle, or drops off USB at random.
• You bought surplus or open-box stock and the firmware looks like a custom product build.

In those cases, treat the firmware as a clue. It may tell you the board was reused, mislabeled, or flashed with settings that do not fit the hardware.

How To Check What Is On The Board

You do not need to read every byte to answer the everyday question. Start with the checks that save time.

Watch the boot log

Open a serial monitor at a common ESP32 speed such as 115200 baud and reset the board. A log can tell you if the chip is booting cleanly, whether the app crashes, and if the image looks like AT firmware, a demo, or a custom sketch.

Upload your own small test sketch

Try a simple blink or serial print sketch. If it uploads and the old behavior vanishes, you already have your answer: the board had ordinary flash content and your new app replaced it.

Erase the flash if you want a clean start

If you want no leftovers at all, erase the chip first. esptool can wipe the whole flash, then you can upload your own image from a clean state. That is often the neatest way to start when a board came from an unknown seller or keeps booting into a noisy demo.

Task	Command Or Action	Result
Check that the chip responds	esptool.py chip_id	Confirms the computer can talk to the ESP32.
Wipe old firmware	esptool.py erase_flash	Removes prior app data from flash.
Flash a new build	Upload from Arduino IDE, PlatformIO, or ESP-IDF	Your app replaces the old behavior.
Verify boot messages	Open Serial Monitor after reset	Shows whether the new image starts cleanly.
Rule out board mismatch	Compare chip details with the listing	Helps catch mislabeled boards or wrong flash settings.

Best First Step If You Want A Blank Starting Point

If your goal is a clean slate, use this routine:

1. Connect the ESP32 and confirm the serial port.
2. Run a full flash erase.
3. Upload a tiny test sketch that prints one line and blinks one LED.
4. Reset the board and check the serial log.

That clears the guesswork. If the board still acts strange after a clean erase and a tiny known-good sketch, the issue is more likely tied to power, cable quality, driver setup, board selection, or the hardware itself.

Should You Worry About Security?

For casual maker use, preloaded firmware is usually just leftover factory or seller code. For work tied to private networks or shipped products, a stricter habit makes sense: erase first, then flash only what you trust.

A used or unknown board should not keep talking on your Wi-Fi just because it boots. Clear it, flash your own build, and store your own settings fresh.

What This Means For Your Next ESP32

If your board already has code on it, that’s usually normal. The ESP32 is built to boot from flash, manufacturers often write test firmware during production, and sellers do not always wipe boards before shipping. A blinking LED or serial log on first power-up is common, not proof that the board is fake.

The practical move is simple: treat any preloaded image as temporary. If the board uploads and runs your own sketch, you’re good. If you want a clean slate, erase the flash first and start there. Once you know that flash keeps whatever was written last, the whole thing stops feeling strange.