Hi,
I'm using the STM32F103ZD uC and the Keil IDE uVision V4.03q.
I wrote two programs: a default Application and a Bootloader. The Bootloader can load the Application by some interface and execute it.
Now I want both programs to be combined into one single project so I can compile both and flash both in one go into my uC.
But, the Bootloader should reside at a predefined memory address.
What's the best way to achieve this?
Thanks in advance,
Henk
"Best" is to build two projects or targets.
Then merge two hex files or two bin files.
The important thing is that you want two completely separate compilations, to make sure that you don't get any shared symbols that will make your boot process fail when you later makes any change to the application. You must be able to guarantee that whatever you do with the application, your boot loader still stays identical. And that whatever changes you do to the boot loader, the application stays identical.
Ok, thanks.
Henk.
And that whatever changes you do to the boot loader, the application stays identical.
That part is actually quite unimportant. After the first device with a boot loader in it has left the shop, the boot loader should never change. Period.
But if the boot loader does have to change, it doesn't matter whether the application has to change, too. The very need to change the loader decrees that all devices with the old boot loader in them have to be considered broken. So there's really no need to worry whether the application has to change to work with the new boot loader --- it won't have to run with the old boot loader any more, anyway, because that boot loader was buggy.
"That part is actually quite unimportant. After the first device with a boot loader in it has left the shop, the boot loader should never change. Period."
No it isn't. You are just not imaginative enough.
You can have multiple releases of your hardware, that gets newer boot loaders. An initial boot loader might support RS232. A newer version may also support USB or CAN. And there may be reasons to release updated boot loaders that supports interface bridging.
A developer should never decide beforehand, that he/she will know the future. So it is important to have a build process where the application doesn't get changed by changes in the boot loader. Either the application should have zero coupling with the boot loader, or there should be a fixed memory region or similar where application and boot loader may exchange information. But a change to the boot loader code should not result in any changes to application binaries.
You can have multiple releases of your hardware, that gets newer boot loaders. An initial boot loader might support RS232. A newer version may also support USB or CAN. And there may be reasons to release updated boot loaders that supports interface bridging. however replacing a bootloader will require "engineer load" where replacing the app only requires "customer load"
or there should be a fixed memory region or similar where application and boot loader may exchange information. VERY risky, I'd stay away from that one
Erik
"VERY risky, I'd stay away from that one"
Not at all. It can be enough to decide that a couple of bytes of RAM or EEPROM should be dedicated for application/bootloader information.
There may be regulatory requirements (such as for Telco equipment) that a device have multiple applications installed, and that the boot loader is capable of automatically switch from one application copy to the other in case there is corruption or if one application copy for some reason fails to run and gives watchdog resets. In that case, the application may after an OTA update need to inform the boot loader that the currently running application shouldn't be used for the next boot since there is a newer version downloaded.