We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I'm looking for some ideas (or solution) to the following problem :-
1. I using an STM32F207VG and I want to operate from 2 x separate code executables. An "old" version, and the "new" uploaded version. 2. Loading a binary executable to the upper-half of the FLASH (0x0808 0000) from an old dongle is easy. That's not the problem. 3. The problem lies in "reseting" to start execution from 0x0808 0004 (and not from 0x0800 0004). 4. I really don't see a way around this other than to copy the "new" executable code over the default FLASH boot space (0x0800 0000). 5. I've searched the Cortex-M3 manual and there is no register whereby you can change the default reset vector (i.e. from 0x0800 0000) to another value. Unless it's hidden. 6. Using a FLASH based "system memory bootloader" IAR is not an option. 7. That should make some sort of sense, if not, then I haven't explained it very well.
All positive comments and ideas are most welcome.
Hi Paul,
Thanks very much for the info. What you write all makes perfect sense. In fact it's what I've been working towards for the past week, and what you've written confirms that there might be some method to my madness. Thanks for that.
I've implemented a simple boot scheme that will be built into all of the executables (i.e. the same boot mechanism will always be in each released executable) :-
1. Restart & initialise based on the restart type (H/W, or S/W). 2. Check which FLASH sector we're going to vector off to and perform some rudimentary checks. 3. Setup the SP and vector off to the reset vector of the selected executable.
As I say, this code will be in every executable. I don't need a sophisticated stand-alone bootloader executable.
The info on setting up the STM32F2xx_TP.ini file for the debbuger is particularly useful, that's something that I hadn't thought of.
Once again thanks for your input, it's been a great help. And if you have any other useful tips on this matter then I am a welcome audience.
Best, Rich.
"I don't need a sophisticated stand-alone bootloader executable."
Sounds like you are doing it wrong.
You shouldn't try to integrate the boot loader in the application. It may sound like a good idea to just have two binaries but in reality it is a more complex solution because how do you handle the situation when you need to erase the flash for one application? What boot loader will you then have? How do you get the processor to look for the boot loader in the other application binary - the boot loader that is at the "wrong" address? How can you then guarantee that a power loss at any arbitrary state of a firmware update will not leave your processor as toast?
With a 3-binary solution, you have a boot loader that is never erased. That is always there to check the two application areas and decide which of them may be selected between. That have a fixed address - always where the processor expect to find initial code.
A separate boot loader isn't "sophisticated". It is the standard way to make sure you don't brick your units accidentally. Google for bricked units, and you will know that the programmers involved have thought they could do it smart. Or that they felt the suggestions they received was too complex. So they cheated.
Just a footnote: If the dedicated boot loader have transfer capability, then it's possible to have just one application binary. So that application binary can be erased by the boot loader and a new application retrieved.
Still no danger of bricking. But the unit will have a service downtime until the new application have been correctly downloaded into the unit and it has rebooted.
With a two-application + bootloader solution, it is possible to retrieve a new application and program into the unit, and then just take a quick reboot to switch. So almost zero service downtime. And the user will know that the new application they downloaded from the net is valid before the reboot - instead of getting a "download error" by the boot loader after the original application had already been erased.
Per,
"Google for bricked units"
Thanks, I'll have a read.