Linker scripts control memory allocation in embedded projects, defining where each code and data section resides in memory during execution. Here’s a breakdown of how Flash-based and RAM-based linker scripts work, their setups, and their impact on project behavior.
Flash-Based Linker Script:
1. Configuration:
Ensure the linker script selected is configured to use Flash memory by reviewing the settings (as shown in the image below).
This setup will utilize both Flash and RAM for storing different code and data sections.
2. Memory Analysis:
After a successful build, use the Build Analyzer’s Memory regions tab to view an overview of the map file.
The Flash-based linker script displays the address and size of each section, distributed between RAM and Flash. Both the address and space usage can be customized according to project requirements.
3. Section Placement:
.data Section: Present in both RAM and Flash due to the Virtual Memory Address (VMA) and Load Memory Address (LMA). Initially, the `.data` section is stored in Flash but loaded into RAM at runtime.
Execution Sections: Sections such as `.init`, `.text`, and `.rodata` are placed in Flash. These sections are typically read-only and remain unchanged during execution.
Zeroed Data: The `.bss` section, which holds uninitialized variables, resides only in RAM and is zeroed out at program start.
4. Primary Characteristics:
Using Flash for read-only and persistent code helps save RAM and allows larger code storage.
Flash memory starts at address `0x08000000`, providing a stable reference point for code sections.
RAM-Based Linker Script:
1. Configuration:
To switch to a RAM-based linker script, change the linker settings as previously discussed.
In a RAM-only setup, Flash memory is no longer actively used during program execution.
2. Memory Analysis:
After a successful build, review the map file through the Build Analyzer’s Memory regions tab. Here, you’ll notice that all sections are now allocated in RAM.
Both address and size for RAM-only sections can be adjusted based on project needs, which are unique to each linker script configuration.
3. Section Placement:
.data Section: Although stored in RAM, VMA and LMA specifications allow the section to be loaded directly, so it does not require relocation.
Code and Read-Only Data: Sections like `.init`, `.text`, and `.rodata` are also placed in RAM, unlike in the Flash-based script.
Zeroed Data: `.bss` remains in RAM, as it does in the Flash-based configuration.
4. Primary Characteristics:
The RAM-only setup ensures faster access speeds, but as RAM is volatile, data is lost when power is turned off.
RAM memory starts at address `0x20000000`, serving as the base address for all sections.
5. Behavioral Differences:
In testing, the LED blink code did not operate as expected when using the RAM-based linker script. This occurred because `HAL_Delay` relies on Flash-stored `.text` sections, which aren’t available in the RAM-based configuration.
Adjustments were required for `HAL_Delay` since it was located below the `.bss` section and not initially included in the RAM-only linker file.
Summary:
Regardless of the linker script type, sections like `.data` and `.bss` are always present in RAM, although their addresses and sizes may vary slightly based on source code and configuration.
Starting Address: In Flash-based scripts, memory starts at `0x08000000`, whereas, in RAM-based scripts, it starts at `0x20000000`.
Project Suitability:
Flash-Based Linker Script: Ideal for larger programs that require non-volatile memory.
RAM-Based Linker Script: Suitable for faster execution with limited code size but requires RAM for all code and data.
Understanding these differences helps optimize your embedded project for speed, persistence, or memory efficiency.
Commenti