How to host OTA Patch

[DoubleH]

Hello,

I’m looking to update the OTA demo to perform a host ota update. I’m following the blog post how-to-perform-secondary-processor-over-the-air-updates-with-freertos

I’m working with AFR 202107.00 which I think maybe part of the problem as it doesn’t have the function vRunOTAUpdateDemo() within it nor the aws_iot_ota_update_demo.c to patch, but the blog post says any AFR later than 201908.00 should work.

The blog post talks about patching in this file but I have no idea what that means. I’m hoping someone here can enlighten me on this Maybe someone has another blog/guide on how to do this or a gitlab repo with a working example?

I now see this has an open issues ticket too issues ticket

[DavidGC-FreeRTOS (David Chalco)]

Hi @DoubleH

I would recommend using the latest version of the OTA library if possible as the blog post is a few years old and there’s been various fixes and improvements to the libraries since.

With regards to latest OTA library, downloading firmware for a secondary processor should be doable through PAL changes alone. Before calling OTA_Init user must set the OTA agent interfaces. Among those user defined functions is pal.writeBlock for example. The function signature for this takes OtaFileContext_t as an argument, which you can use to extract OtaFileContext_t::fileType. This argument is seeded with the fileId that came with initial OTA job document.

One way to do this would be to assign some file type value that distinguishes “OTA for secondary” type jobs, then use that value from OtaFileContext_t throughout the PAL whenever you need different logic for the controller, such as writing to a different channel. There’s other PAL functions that may provide useful hooks for preparing the controller, such as pal.createFile and pal.closeFile for download.

[DoubleH]

@DavidGC-FreeRTOS

I would recommend using the latest version of the OTA library if possible as the blog post is a few years old and there’s been various fixes and improvements to the libraries since.

With regards to latest OTA library, downloading firmware for a secondary processor should be doable through PAL changes alone. Before calling OTA_Init user must set the OTA agent interfaces. Among those user defined functions is pal.writeBlock for example. The function signature for this takes OtaFileContext_t as an argument, which you can use to extract OtaFileContext_t::fileType. This argument is seeded with the fileId that came with initial OTA job document.

One way to do this would be to assign some file type value that distinguishes “OTA for secondary” type jobs, then use that value from OtaFileContext_t throughout the PAL whenever you need different logic for the controller, such as writing to a different channel. There’s other PAL functions that may provide useful hooks for preparing the controller, such as pal.createFile and pal.closeFile for download.

Nice, I’ll test this out in the coming weeks. Thank!