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

[Albrecht Markus Schellenberger]

Hello Nicolas,

does the MCUBoot on the failing device originate from the same version of the nrf-sdk? What kind of boot swap are you using?

Regards,

Markus

[n.marty]

Hi Markus

The problem occurs after i flash the board with "west flash --erase ..." (nrfjprog). So MCUBoot and application image should originate from the same nrf-sdk.

I don't know which swap type config I am using to be honest. I let it at default configuration. After an upgrade I am required to call boot_write_img_confirmed() in order to keep it booting from the upgraded image. I want to keep that mechanism to perform some selftests before confirming.

This is my kconfig about OTA:
CONFIG_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y
CONFIG_REBOOT=y
CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_FOTA_DOWNLOAD=y
CONFIG_DOWNLOAD_CLIENT=y
CONFIG_DOWNLOAD_CLIENT_STACK_SIZE=4096
CONFIG_DFU_TARGET=y
CONFIG_DFU_TARGET_MCUBOOT=y

Looking at autoconf.h after the build is finished I can't find any of these boot type definitions.

best regards

[Albrecht Markus Schellenberger]

Thanks for the feedback, Nicolas!

Are you using an external flash with your device/board?

Regards,

Markus

[n.marty]

Hi Markus

I am currently working on the nrf9160dk board and not using external flash. The device tree was not modified apart from some uart pin and spi configuration.

I read a little bit more about the MCUBoot upgrade strategies and tried different configurations just to see if anything works. Attached below the mcuboot config parameters which I add to the build.

CONFIG_BOOT_SIGNATURE_KEY_FILE="key_fw_sign.pem" # has to be a relative path
CONFIG_BOOT_SIGNATURE_TYPE_RSA=y
CONFIG_BOOT_SIGNATURE_TYPE_RSA_LEN=2048
CONFIG_BOOT_UPGRADE_ONLY=n # overwrite only is not what we want
CONFIG_BOOT_SWAP_USING_SCRATCH=n # not what we want as it requires reserved memory space "scratch area"
CONFIG_BOOT_SWAP_USING_MOVE=y # would be good as this does not require scratch memory area
CONFIG_BOOT_DIRECT_XIP=n # would be an alternative for us, supported by nrf91? leads to FLASH area overflow when enabled
#CONFIG_SINGLE_APPLICATION_SLOT=y Not what we want, not compatible with dfu

I tried to enable each UPGRADE_ONLY, SWAP_USINGE_SCRATCH, SWAP_USING_MOVE and DIRECT_XIP to find a mode which makes the application boot. The build was successful for the first three, the last one DIRECT_XIP didn't build because of a FLASH overflow.
None of the images resulted from the first three configurations were able to boot.

My configuration is based on this sample https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/samples/nrf9160/http_update/application_update/README.html#http-application-update-sample

When I try to build and run the sample with sdk v1.6.0 it works. It seems to be a problem within my application/configuration.

I am stuck on this. Any idea?

best regards

[Albrecht Markus Schellenberger]

Hello Nicolas,

could you please provide me with the partitions.yml of the failing application? The file is located in the root of your build folder. I will have to check this with our development team.

Thanks and regards,

Markus