Dissecting Linker Maps: Flash and RAM Placement

A Tour of Your Program's Memory Footprint

Before we can read the map, we need to understand what it's mapping. When the linker assembles your final program, it doesn't just throw everything into one big blob. It organizes all the code and data from your various source files into standardized categories called sections. Your knowledge of computer architecture will be helpful here, as these concepts are fundamental to how compiled programs are structured.

The three most important sections for now are:

• .text: This section contains the executable machine code—the actual CPU instructions for all your functions.
• .data: This contains any global or static variables that have an explicit initial value (e.g., int global_counter = 100;).
• .bss: This section is for global or static variables that are uninitialized or initialized to zero (e.g., int command_buffer[256];).

Let's also add .rodata for "read-only data", which stores constants like const int LUT[] = {...}; and string literals. The article "How C Code Really Ends Up in FLASH and RAM" provides an excellent breakdown of these sections.

As you read, you'll notice a fundamental division: some sections are destined for non-volatile Flash memory, while others belong in volatile RAM.

Here is a summary of where each section lives and why:

• Flash (Non-Volatile):

  • .text (Code): Instructions are read from Flash and executed directly by the CPU.
  • .rodata (Constants): Since this data never changes, it can live permanently in Flash, saving precious RAM. This is why using const is so important for large lookup tables or configuration arrays in embedded systems.

• RAM (Volatile):

  • .bss (Zero-initialized variables): These variables need to be writable, so they must be in RAM. The linker reserves space for them, and a special piece of code called the startup file fills this entire memory block with zeros before your main() function is ever called. This is a clever optimization: why waste Flash storing thousands of zeros when you can just create them on-the-fly at boot?
  • Stack: Used for local variables, function arguments, and return addresses. It grows and shrinks dynamically as functions are called and return.
  • Heap: Used for dynamic memory allocation (e.g., with new or malloc). This is often avoided in high-integrity systems, a topic we'll explore in depth later.
  • .data (Initialized variables): This is the most interesting case. A variable like int gain = 42; must be in RAM to be modifiable. But since RAM is volatile, where does the initial value 42 come from after a power cycle?

The Double Life of the .data Section

The .data section has a dual identity, which is managed by the linker using two different addresses:

1. LMA (Load Memory Address): This is the address in Flash where the initial values (42 in our example) are stored. This is their permanent, non-volatile home.
2. VMA (Virtual Memory Address): This is the address in RAM where the variable will actually live and be manipulated at runtime. The rest of your code knows the variable by its VMA.

Before main() starts, the startup code copies the initial data for the entire .data section from its LMA in Flash to its VMA in RAM. This "initialization dance" is a cornerstone of the embedded C/C++ boot process.

The "inpyjama" podcast provides a very clear explanation of this process.

This concept is so fundamental that it's worth seeing the formal definition in a technical article as well.

The Map File: Your Ground Truth

Now that you understand the sections, let's learn how to verify their placement. The linker can be instructed to generate a human-readable text file—the map file—that details its every decision.

To generate it, you typically add a flag to your linker command: -Wl,-Map=output.map. The -Wl, part tells the compiler driver (like gcc) to pass the subsequent command (-Map=output.map) directly to the linker (ld).

The Fastbit Embedded Brain Academy channel has an excellent, practical walkthrough of generating and interpreting a map file. This video is the core of this lesson, as it shows you exactly what to look for.

After watching the video, let's put your knowledge to the test with a quick reference. The dev.to article we saw earlier has a fantastic "Truth Table" for predicting where a variable will land.

By cross-referencing this table with an actual map file, you can gain complete confidence in your program's memory layout. If you see a variable in the .data section of your map file, you know its initial value is stored in Flash and it occupies space in RAM at runtime. If you see it in .bss, you know it only takes up RAM and will be zeroed at boot.

Conclusion

This lesson closes the loop on the entire embedded software build process. You now know not only how to instruct the linker with a script but also how to verify its work by inspecting the map file. This is not just an academic exercise; it's a critical skill for professional embedded engineers, especially in aerospace and defense where resource constraints are tight and verifiable correctness is paramount.

Key Takeaways:

• A compiled program is organized into sections: .text (code), .rodata (constants), .data (initialized data), and .bss (uninitialized data).
• The .text and .rodata sections are placed in Flash.
• The .data and .bss sections, along with the Stack and Heap, are placed in RAM.
• The .data section has a unique lifecycle: its initial values are stored in Flash (at the LMA) and copied to RAM (at the VMA) during startup.
• The linker map file is the definitive report showing the address, size, and composition of every section and symbol in your program.
• You can generate a map file using the -Wl,-Map=<filename> linker flag and inspect it to debug memory issues and confirm your program's layout.

With this lesson, you have completed the foundational module of this course. You've built a solid mental model of how a microcontroller executes code and how our development tools translate C++ into a precisely placed binary image.

In our next module, "Development Environment and Bare-Metal Debugging," we will transition from theory to practice. You will install the toolchain, configure your IDE, connect to a real microcontroller, and use a hardware debugger to see these very memory sections and registers live on the target. It's time to get your hands on the hardware.