I’m quite new to AWS and aFreeRTOS, so any help would be appreciated.
Basically, I would like to better understand the mechanism for OTA updates. My end goal is to have an STM32 based device that can be upgraded OTA.
So, I assumed that a bootloader would be required for this… there is a reference bootloader provided by Amazon that can be ported.
I’m just a little confused about the responsibility of the bootloader vs the application when doing OTA updates. Normally I would have said that it is the responsibility of the bootloader to allow reprogramming, but maybe the idea is we can first store the updated binary at runtime and attempt to load it next time we reset.
My question is, is it intended that the code in the OTA demo should be located in the"Application" space of the device, or the bootloader space? I haven’t yet understood what should happen when an OTA job is set up… should the device be reset and put into bootloader mode, or handle the firmware download, then trigger a reset and let the bootloader handle the switch over?
I understand that the STM32 is not yet fully supported, so would need a bootloader and OTA port.
Apologies if this sounds a little confused, I am! but that’s OK
Thanks for taking the time to reply, your answer has cleared up a few things I was unsure about.
I’m glad that you suggested looking at the visual studio based simulator, because that is what I ended up starting on, once I have worked my way through that a bit more I can move on to the bootloader side.
In terms of the bootloader, I will need to understand how the STM32 dual bank flash works, it looks a little different to the Microchip part in that there is not a re-programmable “boot flash”… only a fixed bootloader (no good), but that is a different problem for a different day.
The OTA library for Amazon FreeRTOS is designed to be able to share a single network socket handle with the application. That approach isn’t mandatory, but based on the likely scenario that app data as well as OTA job data are both coming from the AWS IoT MQTT broker, exchanging both using a single context handle reduces our minimum RAM footprint (potentially by a lot).
Once the device OTA library receives notification of a new update, it subscribes to a new MQTT topic and begins downloading the image. Once all “chunks” of the image have been received, the OTA library validates the digital signature of the new image. If the signature checks out, a callback to the app is triggered so that a reboot can be scheduled. There is a portable layer for the OTA library, which you will have to modify, that is responsible for writing image chunks to storage, as well as for performing the signature check. For reference, check out the one for our Visual Studio based simulator, https://github.com/aws/amazon-freertos/blob/master/lib/ota/portable/pc/windows/aws_ota_pal.c.
I’ve been trying to implement OTA update task just as you do.
As you might already know, following links might be helpful to understand usage of dual bank flash structure of STM32.
This contains example source code of “In application proggraming”. https://www.st.com/en/embedded-software/x-cube-dbfu.html
