MCUboot can't find the correct flash area while adding NSIB

[yang.hu]

Hi,

I am using NCS 2.2.0, nRF5240.

Recently, i add NSIB to my project, but MCUboot, application(app core and netcore)can not upgrade.

I read some MCUboot code, and find some puzzling questions.

In sysflash.h file, it has the follow code snippet, PATH:${NCS_DIR}/bootloader/mcuboot/boot/zephyr/include/sysflash/sysflash.h

#if (MCUBOOT_IMAGE_NUMBER == 1)

#define FLASH_AREA_IMAGE_PRIMARY(x)    PM_MCUBOOT_PRIMARY_ID
#define FLASH_AREA_IMAGE_SECONDARY(x)  PM_MCUBOOT_SECONDARY_ID

#elif (MCUBOOT_IMAGE_NUMBER == 2)

/* If B0 is present then two bootloaders are present, and we must use
 * a single secondary slot for both primary slots.
 */
#ifdef PM_B0_ADDRESS

extern uint32_t _image_1_primary_slot_id[];

#define FLASH_AREA_IMAGE_PRIMARY(x)            \
        ((x == 0) ?                            \
           PM_MCUBOOT_PRIMARY_ID :             \
         (x == 1) ?                            \
          (uint32_t)_image_1_primary_slot_id : \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
            PM_MCUBOOT_SECONDARY_ID:  \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_ID:   \
           255 )
#else

#define FLASH_AREA_IMAGE_PRIMARY(x)          \
        ((x == 0) ?                          \
           PM_MCUBOOT_PRIMARY_ID :           \
         (x == 1) ?                          \
           PM_MCUBOOT_PRIMARY_1_ID :         \
           255 )

#define FLASH_AREA_IMAGE_SECONDARY(x) \
        ((x == 0) ?                   \
           PM_MCUBOOT_SECONDARY_ID:   \
        (x == 1) ?                    \
           PM_MCUBOOT_SECONDARY_1_ID: \
           255 )

#endif /* PM_B0_ADDRESS */

#endif

It works ok on single core MCU.

xxx_IMAGE_PRIMARY is the application flash area and xxx_IMAGE_SECONDARY  is upgrading flash area.

Also, on double core MCU, if not define the PM_B0_ADDRESS, in other words, not add NSIB in my project, it works ok. 

FLASH_AREA_IMAGE_PRIMARY(0) is appcore's application and FLASH_AREA_IMAGE_PRIMARY(1) is netcore's application, so does FLASH_AREA_IMAGE_SECONDARY(x).

But, if i add NSIB to my project, FLASH_AREA_IMAGE_PRIMARY(0) is appcore's application flash area, and FLASH_AREA_IMAGE_PRIMARY(1) is MCUboot. The netcore application is unable to identify. 

It looks like we can't upgrade MCUboot and netcore together.

[Hieu]

Hi Yang Hu,

I will have to check with our internal team regarding this. I will follow up with you latest by the end of Fri Jan 13.

Is this related to your other question about creating a custom image management solution to upgrade MCUboot in a two-stage bootloader setup?

Hieu

[yang.hu]

Hi Hieu,

I don't think it matters much.

This looks like a compatibility issue.

MCUboot design for Multiple image boot is as follow:

Every image has two flash area, one named primary and the other named secondary flash area.

But, nordic design for multiple image boot is:

For single mcu, all images has there own primary flash area, but shared the same secondary flash area.

I think this is the root cause of the problem.

The MCUBOOT_IMAGE_NUMBER == 2 confuse me, i want to uograde three images actually.

By the way, other relevant link: mcuboot-get-a-wrong-image-header-when-using-ext-flash . It seems to belong to the same issure.

Best regards,

Yang Hu

[Hieu]

Hi Yang Hu,

As mentioned in  How to erase flash area s0 and s1 when using NSIB?, some other Nordic engineers and I looked into and discussed yours and some other customers' findings today on the setup of "NSIB + MCUboot + External Flash + nRF5340 (2 cores)" doesn't work.

We believe that there is a problem here. We also found issues at the same place that you discussed in your ticket with Einar ( MCUboot get a wrong image header when using ext flash ). Our exploration has not brought us to what you reported here, but I think it is likely you are right, and these codes are a part of the problem.

As said in How to erase flash area s0 and s1 when using NSIB? , we will continue to investigate this internally; and I will update you when there is significant progress. There will be a small progress update on Jan 19 if things are not concluded by then. 

Best regards,

Hieu