STM32 DFU Memory Requirements

[AAgar.2]

How much memory should be available in the device flash to do the firmware install? If my application takes up >80% of my device's flash is it even possible to do a firmware update since most of the flash is already used up.

Appreciate your support.

[Tesla DeLorean]

Second 3)

Presumably you'd need to partition your firmware into two pieces, one with the core application, and an initial loader/validator which implements the update of the application, and addresses all the update, recovery, and de-bricking operations. In the most robust scenarios you never update the loader.

[AAgar.2]

How would the application know which piece to use on boot up? How is this implemented, would I have 2 main() functions?

How much memory should be available on the device? It seems to me that I would have to ensure enough memory for both the current firmware and the new firmware. This is correct?

(Also splitting the question in to multiple for ease of readability)

Appreciate your time.

[Tesla DeLorean]

Should really just leave everything in one thread, it's related. Editing the question just confuses everyone.

The processor is only going to start in one place, the loader daisy-chains into the application once it has validated its integrity.

In the model I'm suggesting the loader always remains, and the app gets replaced.

If you have some secondary memory to stage the new firmware, the loader can find and validate this before erasing/replacing the old application. And can also repeat the process if the replacement gets interrupted by a power glitch or whatever. The loader is always present, and always gets run by the processor, and thus always provides a means of secure recovery.

[AAgar.2]

Thanks!

[Pavel A.]

> How would the application know which piece to use on boot up?

Some STM32 families can assign variable start address, via the "option bytes", and some families have dual banked flash.

In the simplest case you always start from 0x08000000 and there you put the "initial loader".

>  It seems to me that I would have to ensure enough memory for both the current firmware and the new firmware. This is correct?

If the "loader" knows how to get the new firmware, it can erase the whole memory of the "main" part and then move the update in. Then you don't need double space for the application. But for complicated update protocols (wireless....) the loader itself needs to be updated often, then you need more complex scheme and more flash reserved for this.

-- pa

[AAgar.2]

Got it that makes sense. Thanks!