Implementing OTA (Over The Air) firmware updates is a rite of passage for firmware engineers. Device firmware update is a key component of most hardware projects. Often, it is also one of the more complicated components.
Another awesome post! Unless I am missing, something, your link to ‘previous blog post’ is linking back to this blog.
Thanks,
Rajah
Oops, thank you for the comment. Fixed!
I think your svg images are not being rendered for some reason. There are lot of “Rendering Failed: blockdiag -T svg” in the post. For sanity, I checked across chrome, firefox, safari.
Looks like we temporarily broke the diagrams. It’s fixed now!
Since you shared your bootloader architecture, I wanted to share a tool that my work finds useful that for working with the multiple binary files that are to be flashed to hardware.
SRecord (tool not the file format) for working inserting data into your binary files? For work we use a combination of SREC and bin files and each we embed similar data as to what you describe and the process was automated with Python before. Since we found SRecord, we replaced the custom Python programs with SRecord and now just use Python as a wrapper around SRecord.
SRecord has some nice features in that can be used to calculate and generate a CRC, extract ranges of memory, merge multiple files together, fill ranges with a a specific value and it also works with many different file formats.
Thanks for sharing @nadesop728! srec_cat looks very useful indeed. I’m impressed that it even comes with an implementation for the STM32 CRC!
Nice to hear that you find it interesting. Its really a hidden gem. A very amazing tool hat has proved to be very helpful many times.
Hi
Really nice post. I found a little typo, check the URL of this example
https://github.com/memfault/interrupt/blob/maaster/example/fwup-architecture/patch_image_header.py
BR
Using Chrome Version 84.0.4147.89 (Official Build) (64-bit), I don’t get any renderings of your block diagrams. Here’s what I see:
…We start with the simplest possible description of what we want to achieve with DFU: an application that updates itself.
blockdiag blockdiag { // Set labels to nodes. A [label = “Application”]; A -> A [label = “Updates”, fontsize=8]; } Application Updates
It would be nice to see this as it’s intended to be rendered. Is it browser dependent?
thanks,
Keith
@krhill82 Thanks for letting me know. This is odd – the diagrams are rendered server side into an SVG block. Is it possible you are using an extension that disables SVGs?
I’m using two add-ons which might block SVGs. When I view the page in Internet Explorer 11, the SVG images are visible. But in the latest Edge and Chrome, just the generator text is visible. (Add ons: Privacy Badger and DuckDuckGo Privacy Essentials)
Thanks for awesome post! Looking for next blog on secure DFU architecture.
This is such an awesome post, thanks!
Hi @francois, Regarding one .bin file generation for both app and bootloader, Everything worked fine till I start using external flash (which is basically memory mapped QSI externnal flash). Basically post compilation I get one hex file with internal and extern flash memory hex. I am using STM32 and use external loader to program it with STM programmer.
When I use below command to get .bin file, I am getting error “arm-none-eabi-objcopy:App.bin[ExtFlashSection]: No space left on device”.
arm-none-eabi-objcopy “${BuildArtifactFileBaseName}.elf” App.bin -O binary
Should I go for 2 .bin file ? One for boot-app and second for external flash. Or there is any other way.
Access my linker script using below link.
Great post, lots of ideas I shall try to use. One bit confused me a little. When Updater and Application share slot 2, so only one of them can occupy it at any one time, where is the other image supposed to be stored? External SD card perhaps?
Second point. While the text above talks of there being four programs, I see only three under the fwup-architecture file tree: boot.c, app.c and loader.c. I expected an ‘updater’ program to exist also??
Welcome to interrupt @tobermory, and sorry I missed your previous questionn.
In order to update the Loader, you first have to update the application to replace it with the Updater. This is a standard software update which replaces the Application in slot 2. So the Updater does not have to be stored anywhere, it gets pushed via OTA. Do you understand?
You’re right, there’s only a Bootloader, and App Loader, and an Application in the example code. I did not implement the Updater (which updates the App Loader).
The Updater is simple: it gets loaded by the Loader, and waits for an OTA image. It writes that image in Slot 1, marks signals via shared memory that the loader should go into DFU mode for the next boot, and reboots the device.