Posted on May 17, 2011 at 13:39In this thread I discuss how to reboot the processor and alter the startup behaviour here :
https://my.st.com/public/STe2ecommunities/mcu/Lists/ARM%20CortexM3%20STM32/FLASH%20Copy%20%20Vector%20Table%20Update%20%20Core%20Reboot I program the flash in the early boot conditions because I can strongly control the environment, and there aren't random parts of the system running from flash and interrupting. To improve the chances of success flashing should be done in a quiet system.
I've been doing this a while so the process is reasonably well understood. I reviewed the STM32 TRM documents, I looked at the flashing examples and library code, and I experimented programming unused scratch areas of flash from my application code. I also tested and coded assembler routines, and the code to copy them into RAM from the app. The boot loader code is compact and written in assembler. In other words the code is efficient and very much self contained.
I'm not going to post full source, but might consider posting some blog entries on the techniques if there is general interest.
The general flow of the reset is
Check for a magic constant in RAM early in the boot, prior to executing the C runtime initialization.
Initialize the CPU, clocks and core peripherals.
Copy a block of location agnostic (ie PC relative) code and literals from it's fluid location within FLASH, to a known scratch area of RAM, and execute it.
Code in RAM, determines the size of the new flash update, then a block at a time. It checks to see if the the new data is different, erases the block if not blank, and then writes the new data, and repeats for all the blocks in the image. Once this completes the system is reset, and the processor restarts without a magic constant, and the boot loader drops into the C runtime initialization and executes the applications as normal.
-Clive
