Reading the ESP32-S3 Memory Map Before Blaming Firmware

Observed flash and PSRAM capacity define what the build and runtime can actually support.

The first engineering constraint behind Reading the ESP32-S3 Memory Map Before Blaming Firmware was concrete: The LOUP EVT hardware reported 16 MB flash and 8 MB PSRAM, and that has to be verified before partition or heap assumptions are trusted.

A build can succeed with an incorrect mental model of the board and fail later when OTA partitions, assets or buffers collide with real limits. Bring-up therefore starts by reading chip features, flash size, PSRAM detection and partition layout from the target rather than copying values from a reference board.

I kept the experiment narrow by changing one variable, capturing the observable result, and comparing it with a preserved working build before moving on. Evidence marker: 16MB-flash-8MB-psram.

Board identity should be measured from the unit on the bench. Configuration copied from another ESP32-S3 design is evidence only after the hardware confirms it. In practice that keeps the next LOUP change measurable because the baseline remains available for comparison.

Project evidence

LOUP engineering marker: 16MB-flash-8MB-psram. This note records the design or debugging lesson without publishing device credentials, private keys, customer data or manufacturing secrets.