STM32F103ZG FW Upgrade

1. Use the fromelf.exe utility.
2. No, it won't. In order for it to work, it would have to be position-independent code (PIC). PIC code is generally bigger and slower.
3. Adding lots of external RAM would definitely make things easier. The question is: are you prepared to over-design your hardware when you can solve the problem in software?

There are a number of approaches to your problem. Here is how I do firmware updates.
- The nonvolatile memory is split into 3 regions: bootloader (small, never updated), main application, new application. New application can reside in off-chip memory.
- At power-up, the bootloader starts. It looks for new application (e.g. check signature, verify checksum). If found, it is programmed into main application area. Main application is started.
This can be made resistant to power failures. The drawback: the device can be bricked if a faulty new application is programmed. The advantage: it's simple.

1. Use the fromelf.exe utility.
2. No, it won't. In order for it to work, it would have to be position-independent code (PIC). PIC code is generally bigger and slower.
3. Adding lots of external RAM would definitely make things easier. The question is: are you prepared to over-design your hardware when you can solve the problem in software?

There are a number of approaches to your problem. Here is how I do firmware updates.
- The nonvolatile memory is split into 3 regions: bootloader (small, never updated), main application, new application. New application can reside in off-chip memory.
- At power-up, the bootloader starts. It looks for new application (e.g. check signature, verify checksum). If found, it is programmed into main application area. Main application is started.
This can be made resistant to power failures. The drawback: the device can be bricked if a faulty new application is programmed. The advantage: it's simple.

Thanks Mike...

Appreciate your quick answer.

The new application(app) is sitting in the Serial Flash. In boot loader I will check for the flag set by old application (some non-volatile means ) and once that is set I will erase the old app and read new app from serial flash and overwrite the old app area.

In this case I think vector remapping is not required as we are not moving the app execution area. Is it correct?

So my scatter file should have 2 execution areas one for BootLoader (will have it's own main) and one for main app.
So I should use sector 1 for boot loader and some other sector(s) for App.

I am thinking I should not disturb sector 0 as it will have vector table.

Venkat

In this case I think vector remapping is not required as we are not moving the app execution area. Is it correct?

Yes. Except if you use interrupts in both the bootloader and the main app, you'll have to switch the vector table from the former to the latter somehow.

So my scatter file should have 2 execution areas one for BootLoader (will have it's own main) and one for main app.

Actually, you should develop the bootloader and the main app as separate programs, each with their own scatter file.

I am thinking I should not disturb sector 0 as it will have vector table.

There is no need for that. The Cortex-M3 CPU allows you to place the vector table anywhere in memory. Have a look at the Vector Table Offset Register of the NVIC (at address 0xE000ED08).

Excellent Mike...
Thanks for the Help...