Investigate firmware update feature

[Gadgetoid]

It should be possible to update the 32Blit firmware using a binary saved to SD card, loaded into QSPI flash and run just like any other executable.

We need to investigate the internal flash unlock and rewrite procedure to see if a program running in QSPI flash can accomplish this.

This would allow us to ship firmware updates that are run just like normal applications, so that the firmware itself doesn't need to bake in any update functionality, and the updater can be improved independent of the firmware itself. IE: you always get the latest and greates uploader no matter how old your firmware is.

DFU mode would still always work as a fallback.

[AndrewCapon]

Just thought I would post here that I have started looking at this.

As well as having the SDCard update route I will look at using "PROG" as well.

[Gadgetoid]

The way I see it, there are a couple of methods of approaching this:

1. Firmware has a loader built in for updating itself and looks for a BLIT-FW.BIN on the SD card
2. The firmware updater is a self-executing .bin that gets flashed to ext flash and does a second stage update to internal flash from either an appended bin or BLIT-FW.BIN on SD card.

I'm not sure what the practical implications of the internal flash being updated while the system is "running" so number 2 might be tricky unless the app is linked as some horrible hybrid of firmware/PIC software.

Both setups require the firmware to at least be functional and not a bad flash, DFU will always be the Get Out Of Jail Free fallback if something goes wrong.

[zenodante]

The stm32h750 internal flash only have 1 section (1 bank). If you want to update the firmware in internal flash, you have to erase them all. So the loader in internal flash is not possible to finish the job.
One possible way is to run the update loader in internal ram and erase the internal flash (whole 128kB), then copy the bin from sd card into the internal flash. However, if there is something wrong during the whole process, user need to use DFU bootloader in system memory to reflash the stm32h750.

[Gadgetoid]

A firmware update via ext flash would be possible, but some very careful considerations would have to be taken to make it work. Since binaries are going to be position-indepedent on ext Flash there are some.. potential complications. That said, once the existing firmware has set up the updater and jumped to it- all jumps are then relative so all code can run on ext Flash until the update process has finished. The trick would be de-initialising the firmware and initialising the hardware from inside a PIC update binary, since otherwise the whole system would fall flat on its face as soon as the int Flash is erased.

Even if it does go wrong sometimes, the alternative is that the user must always use DFU. Though to be fair DFuSe is supposed to be a protocol you implement in your own end-user firmware update tool anyway.

[Gadgetoid]

This has been nailed and is- in my experience- rock solid.