cancel
Showing results for 
Search instead for 
Did you mean: 

Writing a program that updates itself at runtime

smoothmanifolds
Associate III

How can you write a program that updates itself for an STM32, eg. for an STM32F103C8?

I'm not talking about a bootloader, since (as far as I know), a bootloader lives from (say) 0x08000000 to 0x08001000 in Flash and then updates another program (another part of flash), in this case, eg., starting at 0x08001000.

One option I thought of would be to run the code not from flash but from RAM/SRAM, like in this question and then update the flash memory, reset, and boot from flash. However, the answers there involve booting from SRAM, which I think I may not want to do. (One of the reasons being that this must run in production, without a debugger.)

Rather, what makes more sense to me is to flash the program to the STM32 flash, as usual, at 0x08000000, run the code from flash, and then, at runtime, upon receiving the update command from the user, move the entire program (or perhaps just the strictly necessary parts) to RAM/SRAM, continue execution from SRAM, and then update the entire flash memory and reset the MCU and boot from flash, again, as usual. (In particular, you never boot from SRAM, and you only run code from SRAM when you want to update.)

So, can this (or something logically similar) be done, in order to have a program that updates itself completely?

Now, I know this is possible if you only want to update a subset of flash memory (eg. I think VIA does a partial update of flash memory at runtime in order to update keyboard mappings without reflashing the keyboard and without as much as reconnecting your keyboard), but I wonder how it can be done if you want to update the entire contents of flash memory.

15 REPLIES 15

Well generally you don't want to erase / overwrite the existing firmware as the window for failure and bricking is exceedingly high.

Configuration type stuff, you separate the pieces so the configuration has it's own entity, and perhaps if corrupted gets written with some default.

You could move enough code to RAM to erase flash, and update via say X-MODEM, but you're not really going to be able to do things concurrently, ie run your app whilst updating.

If you have enough RAM to stage the entire firmware, then just do that, and reflash when you have a complete and valid image. Shrinks the window for failure significantly.

If you have MicroSD or SPI FLASH, you can stage there too.

 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I forgot to say that my current setup uses a bootloader for USB DFU updates, and all updates to the firmware should be done over USB DFU. Do you think this is still possible?

Not clear on the benefits of running a DFU update from RAM, vs just using the ROM

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

How does using the ROM work? This is new to me.

Here's some more detail: the STM32 project I'm working on is part of a USB HID device that goes to end-users with the assumption that they don't have any programming tools except something to run updates over USB.

The DFU method uses PC side tools like DfuSe or STM32 Cube Programmer.

Several of the STM32F1 support DFU mode out of the ROM, ie restart with BOOT0/BOOT1 set so device appears as "STM32 BOOT DEVICE", irrespective of firmware you have running from FLASH

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Questions to ask yourself.

How large is the firmware you're running?

Will the firmware run in RAM based on it's size of code/data foot print?

Does your HID firmware implement a Compound USB Device with HID + DFU ?

 

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

I'm working with an STM32F103C8, which as far as I know doesn't come with the ROM DFU.


@Tesla DeLorean wrote:

Questions to ask yourself.

How large is the firmware you're running?

Will the firmware run in RAM based on it's size of code/data foot print?

Does your HID firmware implement a Compound USB Device with HID + DFU ?

 


- Assume the firmware does fit in RAM.

- One current version isn't DFU + HID: the bootloader is DFU and the program after that is HID.

Another version is HID + HID: the bootloader is HID and the program is also HID.

The "self-update" version I'm talking about would be (I guess) DFU + HID or just HID, since doing the updates over HID is also okay.

Well should definitely be possible to migrate the firmware into RAM, I'd approach via code in Reset Handler, and immediately after the Vector Table.

As there's no DFU in ROM, overwriting the FLASH gets to be a proposition with a lot of risk, and very few avenues for recovery.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..