I am preparing to make our first firmware release on our custom board, which is equipped with the nRF9160 SICA B1, modem fw version 1.3.4.
Our application is based on the Asset Tracker v2 and uses NCS v2.6.1, with AWS as the cloud provider.
The firmware is built with NSIB as the immutable first-stage bootloader, and MCUboot as the mutable second-stage bootloader.
I am successfully using my own signing keys to build with - one for NSIB, a different one for MCUboot.
For MCUboot:
For NSIB, added as part of build command:
I am running some final tests on FOTA upgrades.
I can successfully upgrade the application image using FOTA and AWS.
I can also successfully upgrade MCUboot using FOTA and AWS; I can confirm that the MCUboot firmware version changes.
I truncated the output for the MCUboot upgrade. Before the download, MCUboot's FW version was 2. You can see it finishes the download. The reboot is rescheduled, it reboots, and the FW version is still 2. I read this tip under Second-stage bootloader upgrades:
A device reset triggers the second-stage upgradable bootloader to copy the image from the update bank to the non-active slot. An additional reset is then required for the first-stage immutable bootloader to select and use the upgraded second-stage bootloader.
So I manually restart the device (by power-cycling) and see the MCUboot FW version increment to 3, as can be seen in the output.
Problem: when I define a different firmware signing key for MCUboot in CMakeLists.txt and update the firmware version, I can't figure out how to update MCUboot and the application image simultaneously.
Question: How do I update over-the-air MCUboot with a new signing key plus firmware version and also download a new application image signed by the new key?
I tried to first download the new bootloader, but that is logically flawed because it can't boot the old image since it doesn't have the correct signing key. NSIB appears to boot the older version of MCUboot. So I downloaded the newly signed application image, and that still doesn't accomplish anything.
This post about multiple MCUboot keys asks a similar question, and Nordic support responded with this:
Question: Won’t we need to do a multi-image OTA so that the new MCUboot and newly signed application are able to be installed consecutively. Otherwise, we could install a new MCUboot version with an old application which it can’t boot. I don’t quite understand how to do this with the two bootloaders.
Answer: Yes, if you change the MCUboot key used to validate the application, you will need to update both MCUboot and the application simultaniously. This should not be a problem though. Wiht an upgradable bootloader, you have a secondary slot for the bootloader, and you also have a separate secondary slot for the application. In order to simultaniously update, transver both the new MCUboot and the new application, which then reside in their separate secondary slots, and activate the new applicatio image. What happens then is that when the device is reset, the secure immutable bootloader which is the first stage bootloader will see that there is a newer MCUboot version, and boot that. This in turn will check the metadata on the secondary slot and see that there is a new image to be activated, and activate that.
Einar's response states it is necessary to update both simultaneously.
Question: How do I achieve this simultaneous upgrade? How should the AWS Job Document look? I read through the implementation for the aws_fota library; it doesn't even check for the other JSON attributes like "operation" or "size".
