MCUBoot "reading sectors failed" problem with nrf-sdk v1.6.0

[n.marty]

Hi all

We are switching to nrf-sdk v1.6.0 in our project and encountered a problem with MCUBoot.

The image builds successfully and can be flashed successfully as well. MCUBoot loads but is then unable to find a bootable image. There's a message which says:

W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=128 - too small?

I tried increasing BOOT_MAX_IMG_SECTORS up to 91216. But there's still the same error message. I can't increase it more otherwise it overlaps SRAM region. I think the problem is somewhere else but I don't know where. Can someone give me a hint where to look for the problem?

I read that BOOT_MAX_IMG_SECTORS configuration is important for swapping the image in the secondary slot to the primary slot after an update.
I thought as a workaround I could configure MCUBoot to work in XIP Mode "execute in place", which does not need swapping and thus my initial problems disappears. Does anyone have a recommendation if it is a good idea to use XIP?

best regards

[n.marty]

Hi all

I found a hotfix for the problem which was actually a problem with the build configuration.

When applying my own mcuboot.conf to the mcuboot project (via cmake) like this
list(APPEND mcuboot_OVERLAY_CONFIG ${MY_MCUBOOT_CONF_FILE})

it is dropping the partition manager configuration "partition_manager_enabled.conf" for some reason which in my eyes is a bug.

My hotfix for the moment is to manually append the partition_manager config in addition to my "usual" mcuboot.conf. I do it now like this:
list(APPEND mcuboot_OVERLAY_CONFIG ${MY_MCUBOOT_CONF_FILE})
list(APPEND mcuboot_OVERLAY_CONFIG "/opt/zephyrproject/nrf/subsys/partition_manager/partition_manager_enabled.conf")

and it builds a working bootloader.

I would rather not deal with such a static, absolute path in my project because this is gonna break sooner or later again.

What is the best practice to build MCUBoot with own configuration flags?

best regards

[Albrecht Markus Schellenberger]

Thanks a lot for your feedback, Nicolas. It is really appreciated.

n.marty said:

it is dropping the partition manager configuration "partition_manager_enabled.conf" for some reason which in my eyes is a bug.

 I’m not quite sure if this is a bug, really. 

n.marty said:

What is the best practice to build MCUBoot with own configuration flags?

 Could you please follow this guideline and check if that would work for you? The child_image directory configuration mechanism is what we normally recommend to do.

Regards,

Markus

[n.marty]

Hi Markus

The MCUBoot child_image is added automatically when I set CONFIG_BOOTLOADER_MCUBOOT=y in my prj.conf. If I manually add a child_image within my project's CMakeLists.txt I get a "duplicated child image error".

The solution for me was to use add_overlay_config() instead of add_child_image() in my project's CMakeLists.txt.
add_overlay_config() is part of sdk-nrf/cmake/extensions.cmake

In the beginning, I manually modified the variable mcuboot_OVERLAY_CONFIG which created a mess (and the problem I initially observed). When using add_overlay_config() the variable gets updated correctly. Unfortunately, the guideline does not mention the usage of add_overlay_config() in order to inject kconfig overlay to a child image.

best regards

[Albrecht Markus Schellenberger]

Thanks for your feedback, Nicolas!

I will be on vacation for the next couple of weeks. If you need more support concerning this issue, I recommend you creating a new case referring to this one. One of my colleagues will help you then.

Thanks and regards,

Markus