Tips for squeezing flash space out of ESP32 builds that nobody talks about

Nov 01, 2026 Last reply: 1 day ago 4 Replies
Jump to replies (4)

Spent way too long fighting the 6 KB flash ceiling on a C6 running a WLED lightshow, so here's what actually helped. The big one was realizing the Arduino core drags in code you never touch. If your sketch never opens a Serial connection, the build tools still bundle the whole serial stack because the startup code name-checks it. Swapping to a leaner build where that reference is dropped saved me roughly 6 KB on a C6 and a bit more on an S3, which was exactly the headroom I needed for a bigger effect array.



Second tip, check your partition table. alot of boards ship with a default layout that reserves way more space for the app than a basic light controller needs. Trimming that down gave me another chunk without touching a line of code. Last thing, if you drive LEDs on a pin that doubles as the default serial recive pin, make sure the receiver actually lets go of it when Serial isn't in play. I chased a flicker on one strand for a week before realizing the pin was still being held. Worth a look if your build skips Serial entirely.


I hit a similar wall with my S3 build driving a matrix in my garage workshop. WLED kept refusing to compile with a few of the bigger 2D effects enabled, so I poked around the map file out of curiosity. Turned a decent chunk of the flash was going to Bluetooth stuff I will never use on a light controller. Once I confirmed the board variant let me leave that out, I got my effects back with room to spare.

On the partition table side, I did the same thing you did. The default layout on my dev board was way bigger than the app needed, so I trimmed the app slot and gave more of the chip to the filesystem. Handy now that I want to store a couple of custom animations locally instead of pulling them over WiFi every boot. The pin thing rings a bell too. I run data into my first strand through a pin that the bootloader likes to use, and til I made sure nothing was holding it at startup I got random garbage LEDs at position one every few boots. Swapped which pin the data starts on rather than fighting it, and the problem vanished entirely. Sometimes the easy fix is just picking a quieter pin.

Not sure I buy the 6 KB figure though. When I did the same thing on my own build, the map file showed the savings landing in a few different places, and most of what I got back went straight into RAM pressure instead. My effects array kept crashing until I also trimmed the buffer sizes, so the flash win alone didn't fix anything for me. Did you actually check where your freed space went, or did the sketch just compile bigger after you added the array?

The second reply about the map file matches what I saw too. I did the same thing on my C6 build, and when I read thru the map file myself I found a bunch of flash going to stuff I never called. Trimming my buffer sizes after that kept my effects array stable, so for me it was flash and RAM together that finally made it fit. Might be worth checking both if yours is still tight.

Curious how this plays with the newer cores, since the last couple releases changed what gets pulled in by default. I updated mine a while back and my sketch grew even though I didn't touch anything, had to rebuild with the same tweaks all over again. Makes me wonder if the serial reference creeps back in on some versions. Also, on the pin thing, I've had luck just defining the LED data pin before anything else runs, seems to keep the bootloader from grabbing it.

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required