MCUBoot runtime error: "Cannot upgrade: not a compatible amount of sectors" with external flash on nrf9160

Hi,

I am using NCS 2.1.2 with the [email protected] (but I have tested with 2.2.0-rc1 and it doesn't change anything). I have attached a simple example which should just place the MCUBoot secondary partition in the external flash with pm_static.yml. I am using the firmware here: https://github.com/simon-iversen/sdk-nrf/tree/d1a11f2c39e3b8fb0af7652e7e720626f0e1298e/samples/nrf9160/http_update/application_update to connect the NOR flash to the nrf91.

This appears to compile fine, but, on bootup I get the following errors printed by the bootloader:

W: Failed reading sectors; BOOT_MAX_IMG_SECTORS=256 - too small?
W: Cannot upgrade: not a compatible amount of sectors

On stepping through the code, it appears that the flash_area_get_sectors function is returning -22 (EINVAL) for the secondary partition on the external flash because flash_area_open is failing with -19 (ENODEV). However, I know that the flash is working fine because (in the second example attached) littlefs on the external flash formats and mounts correctly.

I found in another thread this fix for a similar problem: https://github.com/nrfconnect/sdk-nrf/pull/9169/files# (I unfortunately cannot find the thread again) but I have applied this patch and it does not seem to change anything.

Could you please help me understand what the problem is here?

Thanks,

Jeremy

8156.nrf9160dk_extflash_mcuboot.zip

Parents
  • Hi Jeremy,

    Of course, I can build with the new board name.

    I have not been able to fix your error yet.
    However, as I see the same as you:

    flash_area_open is failing with -19 (ENODEV).

    This function fails at:

    if (!area->fa_dev || !device_is_ready(area->fa_dev)) {
    		return -ENODEV;
    	}

    And area->fa_dev exist, which means that the device is not ready.

    So I am thinking, could this be due to initialization order?
    Maybe the NOR SPI flash is not initialized before the bootloader runs, and therefore the device is not ready yet?

    We use external flash for example in our nRF5340 bootloader samples, so I will ask our developers if they had to handle initialization when implementing that.

    Let me know if you find something in the meantime.

    Oh, and also: I can not download the littlefs sample you uploaded. Can you upload it again?

    Regards,
    Sigurd Hellesvik

Reply
  • Hi Jeremy,

    Of course, I can build with the new board name.

    I have not been able to fix your error yet.
    However, as I see the same as you:

    flash_area_open is failing with -19 (ENODEV).

    This function fails at:

    if (!area->fa_dev || !device_is_ready(area->fa_dev)) {
    		return -ENODEV;
    	}

    And area->fa_dev exist, which means that the device is not ready.

    So I am thinking, could this be due to initialization order?
    Maybe the NOR SPI flash is not initialized before the bootloader runs, and therefore the device is not ready yet?

    We use external flash for example in our nRF5340 bootloader samples, so I will ask our developers if they had to handle initialization when implementing that.

    Let me know if you find something in the meantime.

    Oh, and also: I can not download the littlefs sample you uploaded. Can you upload it again?

    Regards,
    Sigurd Hellesvik

Children
No Data
Related