nRF5340DK External Flash FatFs with Sysbuild

RE: nRF5340DK External Flash FatFs with Sysbuild

Michael Wagner — Thu, 23 Apr 2026 16:20:20 GMT

Really appreciate the update and heads up! I don't have time to look into making this change right now, but I will definitely follow up if I run into any issues or this resolves the complaints I had.

While this does seem to stop short of implementing system device tree it does seem hopeful that it is moving in that direction.

RE: nRF5340DK External Flash FatFs with Sysbuild

Vidar Berg — Thu, 23 Apr 2026 15:02:13 GMT

The solution we ended up with was using static DT partitions and the partition manager has now been deprecated (in SDK v.3.3.0). For more information, please see the migration guide https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/releases_and_maturity/migration/migration_partitions.html#migration-partitions

RE: nRF5340DK External Flash FatFs with Sysbuild

Vidar Berg — Mon, 03 Mar 2025 15:27:54 GMT

I will try to update the ticket here when I know more.

RE: nRF5340DK External Flash FatFs with Sysbuild

Michael Wagner — Fri, 28 Feb 2025 19:48:55 GMT

Thanks for your reply again. Please keep me updated if there is any progress for the issues with multi-image support between nRF and zephyr.

RE: nRF5340DK External Flash FatFs with Sysbuild

Vidar Berg — Wed, 26 Feb 2025 12:31:13 GMT

Hi,

Unfortunately, there is no public issue to track this yet, and I'm not aware of any concrete plans I can share. I just know that we are currently exploring alternative solutions. I previously thought we were waiting for system device tree support (github issue), but after asking about it internally I found out that we are actually not dependent on it.

[quote user="Michael Wagner"]Also do you have any input about what the correct way to configure the device tree overlay is, as per question 2 above?[/quote]

I had to do the same in the example I posted in order to get DT_HAS_ZEPHYR_FLASH_DISK_ENABLED selected in Kconfig:

/* 
 * NOTE: Actual partition placement and size is controlled
 * by the partition manager. DT entries below is to enable
 * flash disk support.
 * 
 * https://docs.nordicsemi.com/bundle/ncs-2.9.0/page/nrf/app_dev/bootloaders_dfu/mcuboot_nsib/bootloader_partitioning.html 
 */

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

		external_partition: partition@0 {
			reg = <0x00000000 0x00020000>;
		};
	};
};

/ {
	msc_disk0 {
		status="okay";
		compatible = "zephyr,flash-disk";
		partition = <&external_partition>;
		disk-name = "SD";
		/* cache-size == page erase size */
		cache-size = <4096>;
	};
};

[quote user="Michael Wagner"]I'm aware the default sector size for FatFS is 512 Bytes but the samples and the data sheet for the MX25R6435F made it seem like the default was 4096 bytes. I would be fine using 512 Byte sector size. However, it's not clear what config value controls this. The sample does set the FatFS sector size to 512 Bytes but then attempts to read a 4096 Byte sector into it.[/quote]

Got some comments to this ticket from one of the developers who has been working on this code:

Depends on what they want. If they want to be able to mount this partition, via USB for example, to Windows/Linux it is advised to use 512 byte, mostly by urban legend that FS drivers are not that well written and usually work best with 512 byte sectors... leftover from floppy disk times. But, if they do not want to mount this thing externally, then 4kiB sector would be preferred, because sector writes would be then aligned with size of erase-page (or secotr) of a device. Note though, that FAT requires 128 sectors to function, so if you choose 512 byte sector, that means you have 128kiB minimal partition, if you choose 4096, then 512KiB. The cache, as mentioned in the user post, is used to avoid multiple erases into one sector.
Normally to write to any NOR device, the place to write has to be erased; the erase can only happen at specific size, here 4096bytes.
It does not mean that you have to erase the 4096 bytes every time you want to write within it, because write alignment is something like 4 bytes, which means that you can write any 4 bytes at any time - as long as it has not been already written after last erase.
FAT writes data in sector size chunks, 512 by default; so you can probably see that it can do 8 of such writes to 4096, independently, keeping alignment to 512 sector size.
But FAT is done for floppies and it is used to just write anywhere it wants and how many times it wants, for example it will write FAT table any time it needs to update it, that is it will write some one sector every time you update file.
If it does updates in 512 byte sectors then, device that is hampered by 4096 erase sectors size, needs to erase that 4096, put back all the data and write it back with that new 512 byte sector replacing the one that has been on 4096 prior to erase. Without cache, consecutive writes to one page, like you are trying to write 8 * 512 byte sectors, would means 8 erases, because disk access does not really know when the sector was last erased. With chache, it does writes to cache first and does not erase next page untill all write operations leave cache

RE: nRF5340DK External Flash FatFs with Sysbuild

Michael Wagner — Mon, 24 Feb 2025 15:00:00 GMT

Hi, thank you for your quick response.

[quote userid="4240" url="~/f/nordic-q-a/119214/nrf5340dk-external-flash-fatfs-with-sysbuild/524362"]It is unfortunate that the sample does not work out of the box in our SDK. Until we have a common solution with upstream for managing the memory layout for multi-image, I'm afraid it is difficult to completely avoid situations like these. [/quote]

This makes a lot of sense, are there currently plans for a common solution between nRF and zephyr? If so, is there an issue tracker or something where progress towards this is being tracked?

Also do you have any input about what the correct way to configure the device tree overlay is, as per question 2 above?

I'm aware the default sector size for FatFS is 512 Bytes but the samples and the data sheet for the MX25R6435F made it seem like the default was 4096 bytes. I would be fine using 512 Byte sector size. However, it's not clear what config value controls this. The sample does set the FatFS sector size to 512 Bytes but then attempts to read a 4096 Byte sector into it.

MX25R6435F, Wide Range, 64Mb, v1.6.pdf

RE: nRF5340DK External Flash FatFs with Sysbuild

Vidar Berg — Mon, 24 Feb 2025 13:59:57 GMT

Hi,

It is unfortunate that the sample does not work out of the box in our SDK. Until we have a common solution with upstream for managing the memory layout for multi-image, I'm afraid it is difficult to completely avoid situations like these.

[quote user=""] I would have assumed that setting `cache-size = <4096>;` in the device tree or `disk_sector_size: 4096` in the partition manager would correctly update this value in the FatFs config. However, this does not seem to be the case, and it seems necessary to set `CONFIG_FS_FATFS_MAX_SS=4096` in the prj.conf.[/quote]

I think it is reasonable to expect the disk sector size from the partitioning file to be applied. I will report this internally. I recently did something similar for the nRF52840 DK and its external flash in the demo I posted here: RE: Using the Mass example on my custom board, but first getting it running on the nRF52840dk QSPI flash . But I didn't encounter any buffer overruns as I was using the default 512 sector size.

Best regards,

Vidar