I noticed another issue. You wrote this:

However, due to the way the FlashIAP block device currently works while erasing, the header_size should be configured to be the size of an erase sector (4kB in the case of an nRF52840). Erasing using the FlashIAPBlockDevice only works if the given address is erase-sector aligned!

I didn't get what it has to do with erasing and looked into it a bit. I found out that the erase sector is not a limit (at least on the STM32, but I can't imagine why it would be target specific). Important is the combination of target.mbed_app_start and --header-size option of imgtool sign. With --header-size and --pad-header, imgtool prepends the image with the given size. The start address of the resulting "signed" image must be at the beginning of a flash sector. However you cannot set the header size as low as possible (32 bytes is the lower limit set by Mcuboot) due to the vector table alignment. According to ARM:

The Vector table must be naturally aligned to a power of two whose alignment value is greater than or equal to (Number of Exceptions supported x 4), with a minimum alignment of 128 bytes.

This differs from target to target. One must check the interrupt table and round it up to the nearest factor of two. E.g. for STM32F42xxx, the interrupt table size is 0x1A8, so it must be aligned to 0x200 (512 bytes). Indeed, it works when I set mbed_app_start to 0x8020200 and --header-size to 512.

Please correct me if I got something wrong.

Firstly I would like to thank again for the writeup, it was one of the best guides to get started with Mcuboot.

Thanks! 😄

I noticed a minor misinformation though. The --pad flag is not actually needed when preparing the primary application. It works fine without the option, furthermore it reduces the image size, which in turn reduces the amount of sectors to be copied when swapping.

Also in the imgtool docs it says:

The optional --pad argument will place a trailer on the image that indicates that the image should be considered an upgrade. Writing this image in the secondary slot will then cause the bootloader to upgrade to it.

It does not seem to be a prerequisite for the primary image. What was the reason you added this option?

When I originally started working with mcuboot, the documentation was (and probably still is) a bit light. Most of what I understand about mcuboot is from working wit/reading the code and trial-and-error.

It was my impression that the imgtool would only add the trailing TLV information if you specified the --pad option, but I could be wrong. I will have to test this...

Ultimately, I'd like to make some sort of tool that visualizes all the memory regions (either GUI or text-based in CLI) when using mcuboot + Mbed. There's a lot of configuration that can go wrong, especially when you start adding things like KVStore regions and stuff.

Additionally, as you've noticed, mcuboot integration has been added to the Mbed-OS roadmap. I'm planning to work with the Mbed team to move this up from Q4. So hopefully as that work progresses things will become better documented and much easier to use 😁

@boraozgen How would you change the README?

I'll see if I can come up with a PR for the readme this week. Do you also agree on the second issue?