STM32F1 (Cortex-M3) Boot from RAM Behavior

The STM32F1 microcontroller based on the Cortex-M3 core provides the ability to boot from RAM instead of flash memory. This allows developers to update and test new firmware without erasing or reprogramming the main flash memory. Booting from RAM can be useful during development and testing but also has limitations that need to be understood.

How Boot from RAM Works on STM32F1

On system reset, the Cortex-M3 core will start executing code from the reset vector located at address 0x00000000. This is normally mapped to the flash memory on the STM32F1. However, the system has a BOOT pin that can be used to remap the reset vector and other exception vectors to a RAM location instead.

To enable boot from RAM, the BOOT0 pin should be tied high, either directly or through a jumper. The system reset will then remap the exception vectors to address 0x20000000 which is the start of the SRAM memory on the STM32F1. The user firmware must have been previously loaded into the SRAM starting at address 0x20000000.

The STM32F1 also has a BOOT1 pin that provides additional flexibility. With BOOT1 low, the embedded SRAM is used. With BOOT1 high, the system will instead boot from the external SRAM if present.

Loading Firmware into RAM

There are several methods to load the new firmware binary into RAM for boot from RAM:

• Option 1: Load the binary into RAM directly through SWD, JTAG or UART download at runtime before setting BOOT0/1 pins.
• Option 2: Load binary into RAM during regular flash boot, then trigger system reset with BOOT0/1 set.
• Option 3: Use DMA or other peripheral to load sections of flash into RAM, then set BOOT pins.

The firmware binary must be properly built and linked to run from the RAM address space starting at 0x20000000. It cannot rely on flash memory for any code or data.

Limitations of Boot from RAM

There are some limitations to understand when booting from RAM on the STM32F1 Cortex-M3 system:

• Size Limit – The internal SRAM size limits the firmware size, external RAM may be larger.
• Volatile Memory – Contents of RAM are erased on system reset, must be reloaded.
• Slow Execution – Code executes slower from RAM than flash memory.
• No Flash Access – Flash memory is not memory mapped during RAM boot.

For these reasons, boot from RAM is best suited for development, testing or recovery purposes. Critical applications will normally run from more reliable flash memory.

Development Process with Boot from RAM

Here is one method for utilizing boot from RAM during firmware development and testing:

1. Compile firmware and load BIN file into device internal RAM using SWD programmer.
2. Set BOOT0 pin high, with BOOT1 low for internal SRAM.
3. Device will now boot and run firmware from RAM.
4. Test and validate firmware functionality as needed.
5. Make code changes, recompile, and reload updated BIN into RAM.
6. Repeat process until firmware is finalized.
7. Program final firmware BIN into flash memory.
8. Set BOOT0 low for normal flash boot.

This process allows compiling, testing and updating the firmware rapidly without needing to erase or reprogram flash memory. Once validated, the final version can be flashed.

Recovery Mode with Boot from RAM

If the main flash memory has become corrupted and the system is unable to boot, RAM boot can be used to recover. A known good firmware binary can be loaded into RAM via SWD or UART bootloader. This will allow updating the corrupted flash memory to restore normal operation.

Optimizing Boot from RAM

There are some techniques that can help optimize the boot from RAM process and performance:

• Use only necessary memory regions – Tightly control the binary size.
• Load data into RAM only once – Retain across resets if possible.
• Minimize stack usage – May overflow SRAM capacity.
• Optimize for speed – Move time critical code into RAM.
• Enable instruction caching – Helps execution speed from RAM.
• Use minimal vector table – Only required exceptions.

By following best practices and testing different configurations, an optimal boot from RAM implementation can be achieved.

Conclusions

The ability to boot from RAM provides flexibility during development and field recovery of STM32F1 systems. Understanding the limitations and optimization techniques allows creating firmware that performs well when booted from RAM. With some added design effort, boot from RAM capability can become a useful tool for the developer.