Due to the system design of our products, I am going to need to sideload any firmware update binaries. That is, my application code will handle receiving the update through its own protocol and channels.
In my experiments, I have found that if I simply flash the app_update.bin file into the mcuboot_secondary slot, the update will not get programmed (log below). If Instead, I program app_moved_test_update.hex, the update loads successfully. Extracting hex file bits and comparing the binary variants of the two files, it's clear the footers are different along with some metadata appended at the very end. Is this documented anywhere?
Or, put more directly, what would it take for my application to install the app_update.bin flashed into the secondary slot?
D: lfclk: Clock started *** Booting Zephyr OS build v3.3.99-ncs1 *** I: Starting bootloader I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3 I: Boot source: none I: Swap type: none I: Bootloader chainload address offset: 0xc000 D: stack 0x20001280 for thread 0x20000150: obj_size=1088 buf_start=0x200012c0 buf_size 1024 stack_ptr=0x200016c0 D: stack 0x20001100 for thread 0x200000d0: obj_size=384 buf_start=0x20001140 buf_size 320 stack_ptr=0x20001280 D: Configure MPU region at index 0x2 D: Program MPU region at index 0x2 D: [2] 0x20001280 0x150b000a D: lfclk: Clock started D: stack 0x200016c0 for thread 0x200001f0: obj_size=2112 buf_start=0x20001700 buf_size 2048 stack_ptr=0x20001f00 D: Configure MPU region at index 0x2 D: Program MPU region at index 0x2 D: [2] 0x200016c0 0x150b000a D: Configure MPU region at index 0x2 D: Program MPU region at index 0x2 D: [2] 0x20001280 0x150b000a *** Booting Zephyr OS build v3.3.99-ncs1 *** D: scheduler unlocked (0x20000150:0) D: Configure MPU region at index 0x2 D: Program MPU region at index 0x2 D: [2] 0x20001280 0x150b000a .... Main program starts here ....
