SDK v2.6.0 mcuboot overflows flash region

[Tiit]

Hi,

I have an issue moving my project from SDK v2.5.0 to v2.6.0. Using vscode and changing nothing but the toolchain and SDK version my project will fail to build for the newer SDK. Now I know that I could increase the partition size and it would most likely work. But I have a few thousand devices already out in users hands and this is making me worried that I will no longer be able to support them in the future. My bootloader is set up to have one of the app slots in external flash so that may be why it is a bit bigger than usual but it still fir in the default partition before. Should I be worried that my older versions will stop working? What changed in the mcuboot in the latest SDK that made it bigger? Is there an easy way to shrink the size by 66 bytes so that it would fit again? If I can't make it compile smaller in 2.6.0 can I somehow set up the build system to build the bootloader with the older SDK? Will a version mismatch between application and mcuboot cause issues in the future? Unfortunately I'm not sure if I can get the version of SDK used to build the binary in code and since the SDK versions used to build code seem to be something external to the code itself I don't even know which versions my customers are already running out there. So far I have just assumed the bootloader is compatible between all the versions and all my testing is done by just building the code with the latest SDK for different target board versions - I think I should start testing also for older SDK versions bow just to be sure.

Tiit

[Sigurd Hellesvik]

Hi,

First and foremost, make sure that you never change partitioning of the partitions "mcuboot", "mcuboot_primary" or "mcuboot_secondary"! See Static partition requirement for DFU.

For the record: Writing all in a block of text like that makes it quite hard to see the different questions you have. I might miss some, so let me know if I do.

Now I know that I could increase the partition size

Which partition? I assume MCUboot.

Should I be worried that my older versions will stop working?

I do not understand how building for v2.6.0 fails will impact v2.5.x devices?

What changed in the mcuboot in the latest SDK that made it bigger?

Maybe code, but more likely default configurations.
Start by comparing build/mcuboot/zephyr/.config between versions.

Is there an easy way to shrink the size by 66 bytes so that it would fit again?

CONFIG_CBPRINTF_NANO=y for MCUboot.

If I can't make it compile smaller in 2.6.0 can I somehow set up the build system to build the bootloader with the older SDK? Will a version mismatch between application and mcuboot cause issues in the future?

No, the bootloader can work with any version of the application, and it is normal to update the application but not the bootloader.
In fact, most often bootloaders remain the same for the entire lifecycle of a product.

Regards,
Sigurd Hellesvik

[Tiit]

Hi Sigurd,

Sorry about the block of text.

If the MCUboot application can't fit in the partition "mcuboot" and easy change is to increase the size of that partition. But like you say - that is not a good thing to do.

If I build a new version of firmware using the latest SDK (2.6.0) and release that to my customers they will want to update their devices. They may have bought their device last year and in that case they will have a bootloader built with SDK 2.5.0 for example. My question is about those customers running into issues due to their older bootloaders.

Sigurd Hellesvik said:

CONFIG_CBPRINTF_NANO=y for MCUboot.

This did not change anything. I actually think all logging is turned off for the bootloader in my case.

I rebuilt my project with both SDK versions and there are a lot of differences. I'm not sure I wan tto publicly share my config files here though.

I see things like CONFIG_ZEPHYR_TINYCRYPT_MODULE and CONFIG_CBPRINTF_CONVERT_CHECK_PTR and CONFIG_MEM_ATTR being set to "y" in the newer SDK but I'm not sure why or if they are now needed for some reason.

I know about bootloaders generally staying the same over a long time which is why this is worrying for me. We are planning on supporting Matter and Thread on this product in the near future so we are already a bit tight on memory and seeing the bootloader size grow is not a good surprise.

Tiit

[Sigurd Hellesvik]

Tiit said:

My question is about those customers running into issues due to their older bootloaders.

To be direct, I suspect you are a bit wrong on the assumption here.

If MCUboot is your only bootloader, it is an immutable bootloader. This means that MCUboot can not change. And since it can not change, it is unlikely that it suddenly stops working.

If the issues appear after you DFU(?), it is more likely that it is something wrong with the new application or its formatting for DFU.

Tiit said:

This did not change anything. I actually think all logging is turned off for the bootloader in my case.

Ah yes then that will not do much.
Generally, see prj_minimal.conf for some other tips.

Tiit said:

I see things like CONFIG_ZEPHYR_TINYCRYPT_MODULE and CONFIG_CBPRINTF_CONVERT_CHECK_PTR and CONFIG_MEM_ATTR being set to "y" in the newer SDK but I'm not sure why or if they are now needed for some reason.

Do you know how to use the "menuconfig" tool?
With that, you can check which configuration sets another config.

I use the command line, so this might look a bit confusing, but it shows how I check what sets CBPRINTF_CONVERT_CHECK_PTR. Then you just do this recursively until you find which config sets it. Then you can try to understand if the root Kconfig option is something you need. I can help with the understanding.

Tiit said:

.

I know about bootloaders generally staying the same over a long time which is why this is worrying for me. We are planning on supporting Matter and Thread on this product in the near future so we are already a bit tight on memory and seeing the bootloader size grow is not a good surprise.

Yes I agree that the bootloader should not grow too much.
What is the size of your bootloader partition?