Mass storage initialization error with nsib and mcuboot

Board: nRF52840Dk

ncs: v2.3.0.

Hi, I am working on a project in which i need to update bootloader itself and application from the external flash. I also need to make partition where i can store my files using FatFs file system.

My project configuration and overlay setting are below:

CONFIG_STDOUT_CONSOLE=y

#USB related configs
CONFIG_USB_DEVICE_STACK=y
CONFIG_USB_DEVICE_PRODUCT="Zephyr MSC sample"
CONFIG_LOG=y
CONFIG_USB_DRIVER_LOG_LEVEL_ERR=y
CONFIG_USB_MASS_STORAGE=y
CONFIG_USB_DEVICE_LOG_LEVEL_ERR=y
CONFIG_USB_MASS_STORAGE_LOG_LEVEL_ERR=y

CONFIG_MAIN_STACK_SIZE=4096


#CONFIG_APP_MSC_STORAGE_FLASH_LITTLEFS=y
CONFIG_USB_DEVICE_INITIALIZE_AT_BOOT=n
CONFIG_APP_MSC_STORAGE_FLASH_FATFS=y
CONFIG_FS_FATFS_LFN=y

# External partitions
#CONFIG_PM_PARTITION_REGION_LITTLEFS_EXTERNAL=y
#CONFIG_PM_PARTITION_REGION_SETTINGS_STORAGE_EXTERNAL=y
#CONFIG_PM_PARTITION_REGION_NVS_STORAGE_EXTERNAL=y

CONFIG_BOOTLOADER_MCUBOOT=y
CONFIG_PM_EXTERNAL_FLASH_MCUBOOT_SECONDARY=y

#memory related configs
CONFIG_NVS=y
CONFIG_FLASH=y
CONFIG_FLASH_MAP=y
CONFIG_STREAM_FLASH=y
CONFIG_REBOOT=y
CONFIG_HWINFO=y
CONFIG_IMG_MANAGER=y
CONFIG_IMG_ERASE_PROGRESSIVELY=y

#immutable boot
CONFIG_SECURE_BOOT=y
CONFIG_SB_SIGNING_KEY_FILE="nsib_priv.pem"
CONFIG_BUILD_S1_VARIANT=y
# Need to lower the number of counter slots to be able to update several times. Do not know the best number yet.
CONFIG_SB_NUM_VER_COUNTER_SLOTS=120

CONFIG_FW_INFO_FIRMWARE_VERSION=1
CONFIG_MCUBOOT_IMAGE_VERSION="1.1.1"

/delete-node/ &boot_partition;
/delete-node/ &slot0_partition;
/delete-node/ &slot1_partition;

&flash0 {
	partitions {
		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x000000000 0x00010000>;
		};
		slot0_partition: partition@10000 {
			label = "image-0";
			reg = <0x000010000 0x0000e8000>;
		};
	};
};

&mx25r64 {
	partitions {
		compatible = "fixed-partitions";
		#address-cells = <1>;
		#size-cells = <1>;

		slot1_partition: partition@0 {
			label = "image-1";
			reg = <0x000000000 0x0000e8000>;
		};
		external_flash: partition@e8000 {
			label = "external flash";
			reg = <0x0000e8000 0x000718000>;
		};
	};
};

/ {
	chosen {
		nordic,pm-ext-flash = &mx25r64;
	};
	msc_disk0 {
		compatible = "zephyr,flash-disk";
		partition = <&external_flash>;
		disk-name = "NAND";
		cache-size = <4096>;
	};
};

When i am running the code then getting error of msc init:

Attempting to boot slot 0.
Attempting to boot from address 0x9200.
Verifying signature against key 0.
Hash: 0x8f...3b
Firmware signature verified.
Firmware version 5
Setting monotonic counter (version: 5, slot: 0)
*** Booting Zephyr OS build v3.2.99-ncs2-3159-g1e1697d881a9 ***
[00:00:00.376,220] <inf> mcuboot: Starting bootloader
[00:00:00.376,983] <inf> mcuboot: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.377,349] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.377,349] <inf> mcuboot: Boot source: none
[00:00:00.377,838] <inf> mcuboot: Swap type: none
[00:00:00.378,295] <inf> mcuboot: Primary image: magic=bad, swap_type=0x1, copy_done=0x2, image_ok=0x2
[00:00:00.378,662] <inf> mcuboot: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
[00:00:00.378,692] <inf> mcuboot: Boot source: none
[00:00:00.379,150] <inf> mcuboot: Swap type: none
*** Booting Zephyr OS build v3.2.99-ncs2-3159-g1e1697d881a9 ***
[00:00:00.000,396] <inf> flashdisk: Initialize device NAND
[00:00:00.000,427] <inf> flashdisk: offset e8000, sector size 512, page size 4096, volume size 7438336
[00:00:00.000,488] <err> flashdisk: Error -22 getting page info at offset 100000
[00:00:00.000,488] <err> usb_msc: Storage init ERROR !!!! - Aborting USB init
[00:00:00.000,518] <wrn> main: Image build time: Jul 10 2023 09:44:53
[00:00:00.000,579] <inf> main: Image is confirmed OK

Please help me, what I am doing wrong.

Thanks.

Parents
  • Hi Mithi,

    Currently FAT FS does not work with the Partition Manager enabled. Meanwhile, the Partition Manager is automatically involved when MCUboot, or NSIB, or any other child images are used. Reference:  How to use FATFS with partition manager?  

    Thus, what you are trying to achieve is currently not possible.

    If this is of great importance to your company and product, could you please drop a note with your local Nordic Regional Sales Manager?

    Hieu

    P.s: Please note that it is the summer holiday season here. We are thus understaffed and there would be delay in responses. Our apologies for the inconveniences.

  • By decreasing the size of external flash, I am able to run mass storage device:

            external_flash: partition@e8000 {
                label = "external flash";
                //reg = <0x0000e8000 0x000718000>;
                reg = <0x0000e8000 0x00018000>;
            };
    But I want to consume full size of  external flash memory.
  • You cannot just write the zip file to Flash, unfortunately, as MCUBoot does not support this. Also, MCUBoot has no system to receive both updates in the secondary slot and select the correct one.

    I think you have misinterpreted the documentation:

    >This file can be used by FOTA servers (for example, nRF Cloud) to serve both s0 and s1 to the device. The device can then select the firmware file for the slot that is currently not in use.

    This tries to explain that the device needs to request either S0 or S1 from the server, depending on which slot is active. So you cannot just provide it with both (in Flash), and it will select the correct one. Your FOTA solution could provide both files and then the device could select the correct one based on the active slot.

    As an example, the nRF Cloud server uses the manifest.json file to provide the device with the correct file according to what it requests.


  • Thank you for the clarification.

    For the mcuboot update we need an extra reboot the device, how can we know that we need to reboot the device again  to change the slot for mcuboot?

  • Hi Mithi,

    I must remind you that if the question is not directly related to the main topic of this case (FAT FS with Partition Manager in NCS v2.3.0), you should have opened a new question. I will give a quick answer, but please open a new post for follow-up, if it is unrelated to the main topic.

    When the bootloader is updated:

    • During the first reboot, the "new MCUboot" is still in the secondary slot, where it was downloaded. Then the "old MCUboot" swap the "new MCUboot" to the correct slot.
    • During the second reboot, the "new MCUboot" is in the correct slot, and NSIB boots it.

    When the application is updated, MCUboot can swap the application into the correct slot, and boot it right away.

    By the way, what stage is your project at? NCS v2.5.0 has been released, where the two-stage bootloader support for nRF5340 is completed. You can use it and don't have to worry about any cherry picking.

  • Hi Sigvartmh/Hieu,

    The project is in its final development stage.

    I downloaded the NCS v2.5.0, but it requires at least one cherry-pick:

    https://github.com/sigvartmh/fw-nrfconnect-nrf-1/pull/38/.

    I also need to change swap_misc.c:

    Can I expect these two changes in the upcoming NCS release?

  • Hi Mithi,

    If the project is in its final development stage, then I cannot recommend changing SDK. Your project will need to weigh the cost and benefits.

    The pull request you linked seems internal to Sigvartmh's repository. The support for flash disk API should have been completed in NCS v2.5.0.

    Where did you get that change in swap_misc.c from, and why do you think you need to apply it to NCS v2.5.0?

    I see that the change to swap_misc.c was provided by Sigvartmh below. I believe Sigvartmh is investigating whether the change has to be made permanently or not, so we cannot confirm whether it will be merged in NCS yet.

    Also, as Priyanka has said earlier, on DevZone, we also cannot comment on which NCS release will contain which change.

Reply
  • Hi Mithi,

    If the project is in its final development stage, then I cannot recommend changing SDK. Your project will need to weigh the cost and benefits.

    The pull request you linked seems internal to Sigvartmh's repository. The support for flash disk API should have been completed in NCS v2.5.0.

    Where did you get that change in swap_misc.c from, and why do you think you need to apply it to NCS v2.5.0?

    I see that the change to swap_misc.c was provided by Sigvartmh below. I believe Sigvartmh is investigating whether the change has to be made permanently or not, so we cannot confirm whether it will be merged in NCS yet.

    Also, as Priyanka has said earlier, on DevZone, we also cannot comment on which NCS release will contain which change.

Children
  • Okay.

    The pull request you linked seems internal to Sigvartmh's repository. The support for flash disk API should have been completed in NCS v2.5.0.

    Without this patch, I am getting code build error.

    I see that the change to swap_misc.c was provided by Sigvartmh below. I believe Sigvartmh is investigating whether the change has to be made permanently or not, so we cannot confirm whether it will be merged in NCS yet.

    Please let me know, if you get any solution for the same.

  • With things like this, I think it is reasonable for you to move forward with a cherry-picking version of NCS v2.3.0. To sync up, are there any issues left with that setup? 


    Next, just for the purpose of providing information, and not suggesting a different direction, I want to explain about the support of FAT FS with Partition Manager in NCS v2.5.0.

    Sigvartmh's own PR 38 contains experimental support to automatically create a FAT FS partition. In NCS v2.5.0, without that patch, you will still be able to setup a FAT FS partition manually using a static Partition Manager configuration YML.

    While the sample code in PR 11802 doesn't work. I can get FAT FS working with Partition Manager just fine using a slightly different pm_static.yml file like this:
    (note the affiliation attribute of the storage partition)

    app:
      address: 0x00000000
      end_address: 0x000f0000
      region: flash_primary
      size: 0x000f0000
    storage:
      address: 0x000f0000
      end_address: 0x00100000
      region: flash_primary
      size: 0x00010000
      
      affiliation: 
        - disk
      extra_params: {
        disk_name: "SD",
        disk_cache_size: 4096,
        disk_sector_size: 512,
        disk_read_only: 0
      }

    I have checked with the author, and the issue is registered and in investigation. However, right now, the feature works as above.

Related