Using Partition Manager created partitions for FatFS

I have an issue with using partitions created by PM in external flash. I can create a partition in my prj.conf file and use that and everything works. But I need to put some data into the external NOR memory. PM creates the partitions correctly as far as I can see. But I have not found a way to make the FatFS driver correctly find those partitions. Basically I have the exact same issue as in this ticket:  How to reference PM generated partitions from device tree? 

I need to create a disk like this for FatFS driver to find.

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

If I have the partition in internal memory I can at least make this compile (the partition is tiny so it won't work for my application)

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

		boot_partition: partition@0 {
			label = "mcuboot";
			reg = <0x0 0xc000>;
		};
		slot0_partition: partition@c000 {
			label = "image-0";
			reg = <0xc000 0x72000>;
		};
		slot1_partition: partition@7e000 {
			label = "image-1";
			reg = <0x7e000 0x72000>;
		};
		scratch_partition: partition@f0000 {
			label = "image-scratch";
			reg = <0xf0000 0xa000>;
		};
		storage_partition: partition@fa000 {
			label = "storage";
			reg = <0xfa000 0x5f00>;
		};
		external_flash: partition@fff00 {
			label = "external_flash";
			reg = <0xfff00 0x100>;
		};
	};
};

The external memory itself is fine and I can read/write it with flash_area_read() and flash_area_write() functions. 

Is there a way to reference the PM created partitions from within the devicetree file of my main application?

  • UPDATE: Got a reply quicker than anticipated. For the time being, it's not possible to define the partition in the overlay/DTS file while partitions are managed by the PM, but our developers are aware of this, and are trying to address it. However, it's not yet resolved as it takes some time to get to the bottom of and find a sufficient solution. In short what's happening here is that the disk access uses PM (replacing the Flash API) macros to access the fixed partition areas by DTS ID, ending up with an API <-> ID mismatch.

    If you'd like I can keep you updated on any progress or resolution of this issue.

    Best regards,

    Simon

  • I would like to be kept updated on this, thank you. For the time being I will just try to keep using the weird solution I have and make sure to keep everything in sync manually.

    Thank you for your help.

    Tiit

  • Hi Tiit

    I've got an update for you, although it doesn't come from the developers. It seems like another DevZone user was able to do FatFS on an external flash while keeping the partition manager active here. This has not been confirmed to work by tech support or the developers yet, but you're welcome to try it out:  RE: Mass Example with External Flash not working with CONFIG_BOOTLOADER_MCUBOOT=y 

    Best regards,

    Simon

  • Hi Simon,

    Any updates on this?

    I looked at the solution you linked but unfortunately I could not get that to work for me. My goal is to get the MX25R64 device partitioned for slot2 for mcyboot AND also work as the storage area for FAT used by USB MSD. I can make this all work in the internal memory. Actually I can even get it kind of working when the slot2 is in the external flash. But I have not been able to get USB MSD to work from external flash when the bootloader is enabled. The solution you linked was to put settings/nvs partitions into external flash and while I did try that that is not what I want to do. I want to keep the settings partition in internal memory and only move the FAT partition used by the MSD USB to the external memory.

    We now have something working that we should start shipping next week. But we need to be able to upgrade these shipped devices to Matter later. This means we need to have slot2 of the bootloader in external flash. I think that is working now but doing that broke the USB MSD part. Now we could ship with that part broken and later update things to a working state. But I'm worried that something in the partitions may need to change and since the same partitions are also used to compile the bootloader (and we can't update that) we might be stuck with whatever partition thing we ship with now. This has been causing so much frustration already that I've been seriously considering just switching to a Silabs solution.

    Can someone please give and estimate for when this issue might get some attention from your engineers? I see I'm not the only one struggling with this. And from reading all the replies this seems like it is cause by the Nordic Partition Manager. That seems to be your custom solution and the documentation for that has been of very little help.

    [00:00:00.026,580] <dbg> blindy_files: fa_cb: 0 0 flash-controller@4001e000 0x0 0x7000
    [00:00:00.027,252] <dbg> blindy_files: fa_cb: 1 0 mx25r6435f@0 0x0 0xf4000
    [00:00:00.027,893] <dbg> blindy_files: fa_cb: 2 0 flash-controller@4001e000 0x7000 0x200
    [00:00:00.028,533] <dbg> blindy_files: fa_cb: 3 0 flash-controller@4001e000 0x7000 0xf4000
    [00:00:00.029,205] <dbg> blindy_files: fa_cb: 4 0 flash-controller@4001e000 0x7200 0xf3e00
    [00:00:00.029,876] <dbg> blindy_files: fa_cb: 5 0 flash-controller@4001e000 0x7200 0xf3e00
    [00:00:00.030,517] <dbg> blindy_files: fa_cb: 6 0 mx25r6435f@0 0xf4000 0x70c000
    [00:00:00.036,163] <dbg> blindy_files: fa_cb: 7 0 flash-controller@4001e000 0xfb000 0x1000
    [00:00:00.036,834] <dbg> blindy_files: fa_cb: 8 0 flash-controller@4001e000 0xfc000 0x4000
    [00:00:00.037,506] <inf> blindy_files: setup_flash: Area 6 at 0xf4000 on mx25r6435f@0 for 7389184 bytes

    [00:00:00.038,116] <dbg> disk: disk_access_init: Disk access init NAND, dev:flash-controller@4001e000
    [00:00:00.038,665] <dbg> flashdisk: disk_flash_access_init: Init flashdisk with device: flash-controller@4001e000
    [00:00:00.039,245] <inf> flashdisk: flashdisk_init_runtime: Initialize device NAND
    [00:00:00.039,733] <inf> flashdisk: flashdisk_init_runtime: offset f4000, sector size 512, page size 4096, volume size 7389184
    [00:00:00.040,435] <err> flashdisk: flashdisk_init_runtime: Error -22 while getting page info
    [00:00:00.040,954] <err> fs: fs_mount: fs mount error (-5)

    I have tried to find out where things go wrong but so far I can't figure out where the wrong backend gets selected. It looks ot me that flash_area gets set up correctly. The partition table printed out from the actual running system also seems to match the one that Partition Manager should create. And even the device behind each partition seems to be correct. But still for some reason flashdisk wants to use internal flash memory api to access the partition. It actually seems to know the offset and size of the partition - only the underlying device driver seems to be selected incorrectly. Everythign then fails because using internal memory api functions to read addresses beyond the 1 MB capacity fails.

    I will keep trying to figure out where the flash api for flashdisk gets selected but it is a very tedious process. Please provide any help possible. Our whole project is really hurting because of this issue.

    Tiit

  • Hi

    There haven't been any updates in the internal ticket I'm afraid. I pinged the devs for an update now, but I can't guarantee anything, and I do not have an estimate of when this can be fixed. If you need/want to escalate this, you will need to go via the Nordic regional sales manager of your area. Let me know if you don't have their contact information and I'll help you get in touch.

    I've asked the developers on your thoughts to ship with a broken MSD/MSC part. We can't guarantee that this will be a patchable issue on shipped products, so if this is a necessary feature we can't recommend that you ship it with a broken USB MSD/C...

    Very sorry about the inconvenience and frustration this issue has caused.

    Best regards,

    Simon

Related