MCUboot clash with USB Mass Device Littlefs Partition

Hi everyone,

I am trying to run a Zephyr application (NRF52833 device) which has external flash accessed via SPI. On the external flash, there is a second image (MCUboot) and a Littlefs partition.

The Zephyr application is configured to be a USB Mass storage device where the littlefs partition can be accessed either via LittleFS explorer (Windows) or Littlefs_fuse (Linux).

If I have MCUboot disabled, the application works fine and I can access/read/write to the littlefs partition fine in both Windows and Linux. If I enable MCUboot – I cannot access the littlefs partition via USB (see littlefs_fuse screenshot).

I have attached the relevant the .conf files and the .dts file for the nrf52833 board.

MCUBoot.conf

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CONFIG_MAIN_STACK_SIZE=10240
CONFIG_DEBUG_OPTIMIZATIONS=y
# Enable flash operations
CONFIG_FLASH=y
# This must be increased to accommodate the bigger images.
CONFIG_BOOT_MAX_IMG_SECTORS=4096
CONFIG_PM_PARTITION_SIZE_MCUBOOT=0x20000
# Disable UART Console and enable the RTT console
CONFIG_UART_CONSOLE=n
CONFIG_RTT_CONSOLE=y
CONFIG_USE_SEGGER_RTT=y
# Config logger
CONFIG_LOG_BACKEND_RTT=y
CONFIG_LOG_BACKEND_UART=n
CONFIG_LOG_MODE_MINIMAL=y
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Proj.conf

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
CONFIG_CPLUSPLUS=y
CONFIG_NEWLIB_LIBC=y
CONFIG_LIB_CPLUSPLUS=y
CONFIG_SOC_SERIES_NRF52X=y
CONFIG_SOC_NRF52833_QIAA=y
CONFIG_DEBUG_OPTIMIZATIONS=y
CONFIG_RESET_ON_FATAL_ERROR=n
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_MAIN_STACK_SIZE=2048
# Enable MPU
CONFIG_ARM_MPU=y
# Enable hardware stack protection
CONFIG_HW_STACK_PROTECTION=y
# Enable RTT
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Custom_Board.dts

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
/dts-v1/;
#include <nordic/nrf52833_qiaa.dtsi>
#include <zephyr/dt-bindings/adc/adc.h>
#include <zephyr/dt-bindings/adc/nrf-adc.h>
#include <zephyr/dt-bindings/led/led.h>
#include "custom-pinctrl.dtsi"
/ {
model = "Custom Rig";
compatible = "company,custom";
zephyr,user {
io-channels = <&adc 0>, <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>, <&adc 6>;
};
chosen {
zephyr,console = &uart1;
zephyr,shell-uart = &cdc_acm_uart0;
zephyr,uart-mcumgr = &uart1;
zephyr,bt-mon-uart = &uart1;
zephyr,bt-c2h-uart = &uart1;
zephyr,sram = &sram0;
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I have also attached the compiled partition.yaml which seems to show all partitions are in the right place.

Partitions.yaml

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
app:
address: 0x20200
end_address: 0x80000
region: flash_primary
size: 0x5fe00
external_flash:
address: 0x260000
end_address: 0x800000
region: external_flash
size: 0x5a0000
littlefs_storage:
address: 0x60000
device: DT_CHOSEN(nordic_pm_ext_flash)
end_address: 0x260000
placement:
before:
- tfm_storage
- end
region: external_flash
size: 0x200000
mcuboot:
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I must be missing something however I am not sure what direction to proceed in.

I have read that enabling mcuboot ignores the board.dts and uses the partition manager however the partition.yaml suggests this is okay? (maybe not..)

Has anyone come across this before?

Thanks,

David

  • Hi,

     

    Could you share the serial log output of a working and a non-working scenario? 

    It looks like the external_flash area ranges up to 0x80_0000 (8MByte), while the SPI_NOR flash is 32 Mbit. Is there a typo here?

     

    On a separate note:

    You should select "compatible = "nordic,nrf-spim";" to utilize DMA capabilities of the NRF_SPIM peripheral.

     

    Kind regards,

    Håkon

  • Hi Håkon, 

    Thank you for responding, I have looked at the logs and frustratingly they look similar between working and non-working. I have created a NRF52833DK littlefs example project which demonstrate this issue (littlefs is in internal flash instead of external flash) - if have attached this project with this post. If you comment out CONFIG_BOOTLOADER_MCUBOOT the issue disappears. I will collate the logs in the meantime.

    Thanks, 

    Davidmass-nrf52833-mcuboot.zip

  • Hi David,

     

    Here's with MCUBoot enabled:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    21
    *** Booting Zephyr OS build v3.2.99-ncs2 ***
    I: Starting bootloader
    I: Primary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    I: Secondary image: magic=unset, swap_type=0x1, copy_done=0x3, image_ok=0x3
    I: Boot source: none
    I: Swap type: none
    I: Bootloader chainload address offset: 0xc000
    *** Booting Zephyr OS build v3.2.99-ncs2 ***
    [00:00:00.000,183] <inf> flashdisk: Initialize device NAND
    [00:00:00.000,213] <inf> flashdisk: offset 46000, sector size 512, page size 4096, volume size 237568
    Area 6 at 0x7a000 on flash-controller@4001e000 for 24576 bytes
    [00:00:00.000,549] <inf> littlefs: LittleFS version 2.5, disk version 2.0
    [00:00:00.000,671] <inf> littlefs: FS at flash-controller@4001e000:0x7a000 is 6 0x1000-byte blocks with 512 cycle
    [00:00:00.000,671] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
    [00:00:00.000,793] <err> littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1234: Corrupted dir pair at {0x0, 0x1}
    [00:00:00.000,823] <wrn> littlefs: can't mount (LFS -84); formatting
    [00:00:00.175,415] <inf> littlefs: /lfs mounted
    Mount /lfs: 0
    /lfs: bsize = 16 ; frsize = 4096 ; blocks = 6 ; bfree = 4
    /lfs opendir: 0
    End of files
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    And here's with it disabled:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    *** Booting Zephyr OS build v3.2.99-ncs2 ***
    [00:00:00.345,581] <inf> flashdisk: Initialize device NAND
    [00:00:00.345,581] <inf> flashdisk: offset 46000, sector size 512, page size 4096, volume size 237568
    Area 0 at 0x46000 on flash-controller@4001e000 for 237568 bytes
    [00:00:00.345,916] <inf> littlefs: LittleFS version 2.5, disk version 2.0
    [00:00:00.346,069] <inf> littlefs: FS at flash-controller@4001e000:0x46000 is 58 0x1000-byte blocks with 512 cycle
    [00:00:00.346,069] <inf> littlefs: sizes: rd 16 ; pr 16 ; ca 64 ; la 32
    [00:00:00.346,191] <err> littlefs: WEST_TOPDIR/modules/fs/littlefs/lfs.c:1234: Corrupted dir pair at {0x0, 0x1}
    [00:00:00.346,221] <wrn> littlefs: can't mount (LFS -84); formatting
    [00:00:00.520,935] <inf> littlefs: /lfs mounted
    Mount /lfs: 0
    /lfs: bsize = 16 ; frsize = 4096 ; blocks = 58 ; bfree = 56
    /lfs opendir: 0
    End of files
    [00:00:00.571,899] <inf> main: The device is put in USB mass storage mode.
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    The difference is that they pick different areas to use for the disk:

    Fullscreen
    1
    [00:00:00.346,069] <inf> littlefs: FS at flash-controller@4001e000:0x46000 is 58 0x1000-byte blocks with 512 cycle
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    vs:

    Fullscreen
    1
    [00:00:00.000,671] <inf> littlefs: FS at flash-controller@4001e000:0x7a000 is 6 0x1000-byte blocks with 512 cycle
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    If you have a single-image build, then partition manager is not invoked and the DTS "storage_partition" is used:

    Fullscreen
    1
    2
    3
    4
    5
    storage_partition: partition@46000 {
    label = "storage";
    reg = < 0x46000 0x3a000 >;
    phandle = < 0x17 >;
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If you have a multi-image build (ie. with mcuboot), then partition manager is invoked and pm_static.yml is used:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    littlefs_storage:
    address: 0x7a000
    end_address: 0x80000
    placement:
    align:
    start: 0x1000
    before:
    - end
    region: flash_primary
    size: 0x6000
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

     

    Kind regards,

    Håkon

  • Hi Håkon,

    Thanks for your response, as you have mentioned - it has become clear to me that you will need a pm_static.yml if partition manager is used. For my original setup where the second mcuboot image and littlefs fs are placed on an external flash device, I have copied the compilation of partitions.tml and made it into a pm_static.yml file.

    One thing I don't understand: is the external flash entry in the pm_static.yml a duplication?

    When I run 

    Fullscreen
    1
    west build -t partition_manager_report
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I get the following map:
    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
    19
    20
    external_flash (0x4000000 - 65536kB):
    +-----------------------------------------------------+
    | 0x0: mcuboot_secondary (0x60000 - 384kB) |
    | 0x60000: littlefs_storage (0x3fa0000 - 65152kB) |
    | 0x4000000: external_flash (-0x3800000 - -58720256B) |
    +-----------------------------------------------------+
    flash_primary (0x80000 - 512kB):
    +--------------------------------------------------+
    | 0x0: mcuboot (0x20000 - 128kB) |
    +---0x20000: mcuboot_primary (0x60000 - 384kB)-----+
    | 0x20000: mcuboot_pad (0x200 - 512B) |
    +---0x20200: mcuboot_primary_app (0x5fe00 - 383kB)-+
    | 0x20200: app (0x5fe00 - 383kB) |
    +--------------------------------------------------+
    sram_primary (0x20000 - 128kB):
    +--------------------------------------------+
    | 0x20000000: sram_primary (0x20000 - 128kB) |
    +--------------------------------------------+
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
    I don't understand why 0x4000000: external_flash (-0x3800000 - -58720256B)
    is generated.
    Do you know why this is?
    How would you modify the partitions.yml (or pm_static.yml) file?
    Thanks, 
    David 
  • Hi Håkon, 

    I have had a go at replicating my project with a NRF52840DK board (with MCUBoot second image and littlefs on the external flash), and I am able to replicate my error. 

    MCUboot off -> littlefs_fuse (or windows LittleFS-Explorer-for-Windows) - works fine

    MCUboot on-> littlefs_fuse (or windows LittleFS-Explorer-for-Windows) - unable to connect (partition looks corrupted?).

    I have also added a pm_static.yml file to see if that resolves the issue - but unfortunately it does not.

    I have attached the zip project if you could please have a look and point me in the right direction.

    Thanks,

    Davidmass-nrf52840-mcuboot.zip

1 2