When selecting an STM32F1 microcontroller based on the Cortex-M3 core for a project, one of the key considerations is the density option. STM32F1 MCUs are available in different flash memory and SRAM sizes depending on the density option. This determines how much code can be stored and executed directly from flash memory versus needing to boot from RAM. Here we’ll examine the differences between density options and their impact on boot from RAM capabilities.
Overview of STM32F1 Density Options
STM32F1 MCUs based on the Cortex-M3 core are grouped into four density options – Low, Medium, High and Connectivity. Here is a brief overview of the memory sizes for each option:
- Low Density – Up to 32KB flash memory and 4KB SRAM
- Medium Density – Up to 128KB flash memory and 20KB SRAM
- High Density – Up to 512KB flash memory and 64KB SRAM
- Connectivity – Up to 512KB flash memory and 64KB SRAM plus additional hardware for connectivity features
In general, higher density options have more flash to store code and more SRAM to execute it from. The connectivity line adds communication peripherals without increasing memory size over the high density option.
Boot from Flash vs RAM
When an MCU first powers on, it needs to load the program code from non-volatile flash storage into volatile RAM in order to execute it. There are two main approaches to this:
- Boot from Flash – Code executes directly from flash memory. No copy to RAM needed.
- Boot from RAM – Code copied from flash to RAM on startup prior to execution.
For small programs, boot from flash allows saving the RAM needed for holding the copied code. However, execution from flash is slower than executing from RAM. As program size grows, some data or code must reside in RAM, requiring a flash to RAM copy on boot anyway. At that point, it becomes advantageous to just copy the entire program to RAM for faster execution.
Density Impact on Boot from RAM Feasibility
Whether an STM32F1 MCU can feasibly boot from RAM depends largely on the density option selected. Here are general guidelines:
- Low Density – Typically not enough flash or RAM space for boot from RAM. Must boot directly from flash.
- Medium Density – May support boot from RAM depending on program size. Up to 112KB flash could be copied to 20KB RAM.
- High Density – Supports boot from RAM for most typical program sizes. Hundreds of KB flash can fit in 64KB RAM.
- Connectivity – Same as High Density since memory is identical.
Note that medium and high density MCUs may still need to boot from flash if SRAM space is consumed by data requirements. But in general, the high density options provide enough headroom to make boot from RAM feasible in most cases.
Bootloader Code Impact
Another consideration is the memory needed for bootloader code. Typically an MCU boot process will consist of:
- Bootloader stored in flash runs on startup
- Copies main application code from flash to RAM
- Transfers execution to application code
Even if booting from flash, step 1 requires some bootloader code to always reside in flash. This consumes some of the available memory. Boot from RAM requires additional code to perform the copy in step 2. The more functionality built into the bootloader, the bigger its memory footprint in flash.
On lower density MCUs, say 32KB flash, using 8KB for a bootloader leaves only 24KB for the main application. This may dictate boot from flash instead. Higher densities have room for both bootloader and large applications in flash.
Optimizing for Boot from RAM
If aiming to boot from RAM on an STM32F1, follow these general guidelines for best results:
- Select a high density option MCU with at least 192KB+ flash and 40KB+ SRAM
- Allocate around 16-32KB flash for the bootloader
- Keep bootloader code lean and efficient
- Reserve sufficient SRAM for global data needs
- Use linker scripts to control memory segment placement
- Perform memory size checks and alarms during development
With careful design, even medium density STM32F1 MCUs can often be configured to boot from RAM. But high density options offer the most headroom and flexibility.
Case Study: Sample Project
Let’s look at a sample project to see how density options affect boot from RAM feasibility:
- Application code size: 150KB
- Data memory needed: 16KB
- Desired bootloader functionality: medium complexity
For this project, we would recommend:
- Low density – Insufficient flash and RAM. Must boot from flash.
- Medium density – Possible but tight. Use 128KB flash version and optimize bootloader for 8KB.
- High density – More than enough room. Use 256KB flash version for flexibility.
- Connectivity – Same as high density – a good fit.
The high density or connectivity line MCUs would be the best fit to allow booting 150KB of code from the 256KB of flash into RAM. The medium density MCU could work but lacks headroom for growth.
Conclusion
In summary, density options directly impact the feasibility of booting from RAM versus flash on STM32F1 Cortex-M3 microcontrollers. Low density options lack the memory needed for boot from RAM in most cases. Medium density may work for smaller applications. High density options provide ample headroom for both bootloader and application code. When aiming to boot from RAM on STM32F1, high density or connectivity line MCUs are usually the best fit for maximum flexibility now and in the future.
