OTA firmware update for a Nucleo F746.

[SWood.4]

*Edited, I had a long question about why the code wasn't working. I was using an example based on Embetronicx. Here is the git location for his example. https://github.com/Embetronicx/Tutorials/tree/ETX_Bootloader_3.0/Microcontrollers/STM32/STM32F7xx/Bootloader_Example

I found a video series from ST on building a bootloader also. The ST example is significantly different than the Embetronicx example. Embetronicx has good information and it may be good to use. I'm not sure based on the other info I'm finding.

So my question is; what is the best simple method of an OTA bootloader? Do you have links or examples?

Thanks

[Tesla DeLorean]

Well typically the tool-chain doesn't send the .BIN, it works off the .ELF, and that can be sectional and sparse. Perhaps use objcopy or fromelf to inspect. The .HEX might be more record based.

I might suggest

Instrument the code, outputting progress and sums

Get a Hard Fault Handler that outputs actionable data

Step the transition code

Avoid reconfiguring clocks, so don't teardown in SystemInit(), and just set SCB->VTOR =&__gfnVectors, then skip the SystemClock_Config()

[Pavel A.]

@Community member​ Why do you want to use this github example as a base for "OTA update"? UART is not a wireless ("air") interface.

[Tesla DeLorean]

Dramatically editing top posts removing the original question is unhelpful.

Open a new question, or add a new post to the thread to take it in a different direction.

[SWood.4]

The embedded cell modem connected to the MCU has a UART interface. The connection from the server application to the MCU ends up like a serial connection to the PC. The cell modem and ethernet connections in the middle end up transparent to the applications on both ends. So I need a way to update firmware over a cellular VPN, with a UART connection.

My thought is for the server application to send a UART command so the MCU knows what follows is a firmware update, the MCU can save firmware to a FLASH location, do check sum , CRC etc. if its good, save a value at a location the bootloader checks so it knows new firmware is available, reset MCU, boot loader checks if new firmware is available, copies firmware to the Application area of the MCU, jumps to that location and runs it.

I had also thought about having two application areas, the bootloader would jump to the one with the higher number, most recent version. Then the MCU application updates the firmware for the "offline" application, next reset the newer one runs.

Let me know there is a better approach or an entirely better way of getting new firmware on a remote MCU. Thanks

[Pavel A.]

@Community member​ Your approach generally looks good and should work.

(recently I've seen this thing from inside; it has the same STM32F7 and a similar UART-connected wireless interface. The update process works exactly as you describe, except that it pulls updates from a cloud web server).

> I had also thought about having two application areas, the bootloader would jump to the one with the higher number

This won't work unless you manage to make position independent binaries. By default the CubeIDE will produce code located at specific address, it won't run in place at a different address.

[Tesla DeLorean]

Cellular modems can generally pull from FTP or HTTP sources, or at least socket connections.

They frequently have local NAND or eMMC they run their OS from, and can download and stage files there.

You generally want something which you can control flow on as the STM32 Flash has a tendency to block operation. Staging via QSPI is an option.

I'd probably just make the loader permanent, and capable of pulling application firmware directly itself, at least in a recovery sense. Or have a smaller app with that sole task.

Don't update unless you can validate the integrity of the replacement image.

Update alerts, perhaps via SMS or reading a plan / strategy file from a server.