Address Space Hexadecimal Mapping: ESP32 and STM32 Memory Explained

Address space hexadecimal mapping is the method of using base-16 numbers to define the exact physical and virtual memory locations where a microcontroller stores code, variables, and peripheral registers. When configuring an embedded system, these address space hexadecimal values dictate where the bootloader ends, where user flash begins, and how the Memory Management Unit (MMU) routes data, ultimately preventing memory overwrite crashes and firmware bricking during updates. Beginners frequently confuse the hex memory address (the physical location where data lives, like 0x3F400000) with the hex payload value (the actual data stored at that location, like 0xE9), or they fail to account for little-endian byte ordering when parsing multi-byte telemetry streams.

The Core Concept: Navigating Memory Space Hexadecimal Regions

Microcontrollers do not see memory as a single, continuous block. Instead, the silicon is divided into distinct physical regions: Instruction RAM (IRAM) for fast code execution, Data RAM (DRAM) for variables, and external SPI Flash for bulk storage. Because these physical chips are wired to specific pins on the internal memory bus, the CPU accesses them via a virtual memory map.

The MMU translates the virtual addresses your C/C++ code uses into the physical addresses on the silicon. We use hexadecimal instead of decimal because base-16 aligns perfectly with binary nibbles (4 bits). A single hex digit represents exactly half a byte, making it trivial to spot memory boundaries. For instance, an address ending in 0x...0000 instantly tells an embedded engineer they are looking at a 64KB-aligned boundary, whereas the decimal equivalent 65536 hides that structural alignment.

Standard ESP32 Address Space Hexadecimal Table

Below is the foundational memory map for the original ESP32 (Xtensa LX6 architecture). This table defines the hard-coded virtual address space hexadecimal ranges that the MMU expects. If you are writing custom linker scripts or bare-metal firmware, these are your absolute boundaries.

Source: Espressif ESP-IDF Memory Management API

The most critical takeaway from this table is the gap between physical and virtual space. The SPI Flash chip physically sits outside the ESP32 silicon, but the MMU maps a 4MB window of it into the 0x3F400000 virtual range. When you read a file from LittleFS, the CPU is actually fetching from this mapped hexadecimal window, relying on the internal cache to handle the SPI bus transactions.

Worked Example: Calculating Flash Space Hexadecimal Offsets

Let’s calculate the exact address space hexadecimal boundaries for an Over-The-Air (OTA) update scheme with a LittleFS filesystem on a 4MB ESP32 flash chip. The bootloader occupies the first 4KB, and the partition table sits at 0x8000. We need to define two app partitions (for OTA rollback) and one data partition.

Step 1: Define App0 (Factory/Initial Firmware)
App0 must start after the bootloader and partition table. We align it to a 64KB (0x10000) boundary for flash erase efficiency.
Start: 0x10000
Size: 0x180000 (1.5MB)
End: 0x10000 + 0x180000 = 0x190000

Step 2: Define App1 (OTA Update Slot)
App1 must start exactly where App0 ends.
Start: 0x190000
Size: 0x180000 (1.5MB)
End: 0x190000 + 0x180000 = 0x310000

Step 3: Define LittleFS (Data Partition)
The remaining space is allocated to the filesystem, stopping before the final 4KB reserved for the MAC address and chip info.
Start: 0x310000
End Limit: 0x400000 (4MB total) - 0x1000 (reserved) = 0x3FF000
Size: 0x3FF000 - 0x310000 = 0xEF000 (956KB)

This translates directly into your partitions.csv file:

# Name,   Type, SubType, Offset,   Size
nvs,      data, nvs,     0x9000,   0x6000
otadata,  data, ota,     0xf000,   0x2000
app0,     app,  ota_0,   0x10000,  0x180000
app1,     app,  ota_1,   0x190000, 0x180000
spiffs,   data, spiffs,  0x310000, 0xEF000

If you miscalculate the hex addition and overlap App1 into the LittleFS region, the ESP32 will silently overwrite your configuration files every time you push an OTA update, leading to phantom boot loops.

Where You Meet This in Practice

You will interact with address space hexadecimal maps in three primary scenarios on the bench or in the field:

1. Debugging HardFaults and Panics: When an ARM Cortex-M (STM32) or Xtensa (ESP32) crashes, the serial monitor dumps a stack trace. You will see hex addresses like PC: 0x400D1234. By cross-referencing this address space hexadecimal value with your compiled .map file, you can pinpoint the exact C++ function that caused the segfault. If the PC points to 0x00000000 or an unmapped peripheral region, you know a null pointer or uninitialized hardware register was called.
2. Custom Linker Scripts (.ld): If you are writing bare-metal firmware or optimizing an RTOS, you must manually edit the linker script to place specific arrays into the RTC Fast Memory. You do this by defining a custom section and assigning it the hard-coded hexadecimal origin (ORIGIN = 0x3FF80000) so the compiler places your deep-sleep variables in the correct silicon domain.
3. Aerospace and Space Telemetry (CCSDS): In satellite communications, the Consultative Committee for Space Data Systems (CCSDS) standardizes packet telemetry. Ground stations receive raw RF demodulated as hexadecimal byte streams. Engineers must parse the primary header (which contains the packet sequence count and length) using strict address space hexadecimal offsets within the payload buffer. Misaligning the hex pointer by a single byte shifts the entire telemetry frame, corrupting the orbital parameters. For deep-space missions, adherence to these CCSDS Blue Book standards is non-negotiable.

Frequently Asked Questions