NVS write fails error -22 when building with sysbuild

[Nick_RA]

nRF54L15 - ncs 3.02 - toolchain 3.02

I changed my build settings from no sysbuild to sysbuild in order to use serial recovery and/or FOTA. I thought everything was OK until I tried saving settings to NVS where I now get error -22

(Before asking why I'm using NVS not ZMS I was advised to as ZMS is still buggy and it gives problems)

Do I need to manually change partitioning to make this work?

Here is the NVS write code:

	struct nvs_fs fs;
	struct flash_pages_info info;

	fs.flash_device = NVS_PARTITION_DEVICE;

	if (!device_is_ready(fs.flash_device)) {
		printk("Flash device %s is not ready\n", fs.flash_device->name);
		return 1;
	}

	fs.offset = NVS_PARTITION_OFFSET;
	rc = flash_get_page_info_by_offs(fs.flash_device, fs.offset, &info);
	if (rc) {
		printk("Unable to get page info, rc=%d\n", rc);
		return rc;
	}

	fs.sector_size = info.size;
	fs.sector_count = 3U;
	rc = nvs_mount(&fs);
	if (rc) {
		printk("Flash Init failed, rc=%d\n", rc);
		return rc;
	}

	rc = nvs_write(&fs, NVS_SETTINGS_ADDR, &mybuff, sizeof(mybuf));

	return rc;

[Simonr]

Hi

Can you show me what parameters are being entered to the nvs_write() function on your end, or potentially upload your project here (with instructions for how to build it on my end) so we can take a closer look at our end?

Best regards,

Simon

[Nick_RA]

So... I've stripped everything including BLE out of my project apart from one build (nRF54L15DK) and the NVS routine. Make sure the build has sysbuild enabled - it seems to revert if I make a copy of the folder.

Every time I make a change I clean the build configuration, run a pristine build and erase the target before flashing.

• The NV write fails if I have CONFIG_BT_DIS_SETTINGS=y in my prj.conf
• If I comment it out it works
• If I change the build configuration to "No sysbuild" it works

Zip attached...DFUtest.zip

[Simonr]

Hi Nick

If you stripped out BLE from your project, why would you also have configs for Bluetooth settings like CONFIG_BT_DIS_SETTINGS. I think the selection of the settings subsystem which this config sets is what causes it to fail on your end. Probably because the NVS tries accessing addresses expected to be used by CONFIG_SETTINGS.

Have you used the NVS sample for reference to see how the NVS subsystem should be used. I'd try to get that up and running with sysbuild before incorporating the Bluetooth controller.

Best regards,

Simon

[Nick_RA]

I think you might be missing or maybe evading the point here...

Yes the sample runs correctly, I actually ran the zms not nvs, but I'm sure both will work. As will Blinky and the rest of the samples - but that's completely irrelevant to my actual problem!

I haven't stripped BLE from my project. I spent half a day stripping out code section by section until I ended up with the simplest bit of code that will reproduce my problem and that is what I have uploaded. I can't upload the project itself as it contains a lot of proprietary IP including custom protocols, PSK etc. In this project I use a lot of subsystems including crypto, uart, i2c, gpio ppi, timers, GAP/GATT, DIS, wdt so you can appreciate it's a bit of a headache trying to isolate conflicts.

Simonr said:

Probably because the NVS tries accessing addresses expected to be used by CONFIG_SETTINGS.

Is this speculation or something you know to be so? Sounds like a bug to me if two subsystems are trying to use the same memory especially considering it is all macro driven. If true, then surely all I have to do is adjust my NVS partition offset if there is a way to reliably do that at compile time or run time (I do NOT want to just choose some arbitrary value). Currently the offset is defined by macro:

#define NVS_PARTITION			storage_partition
#define NVS_PARTITION_DEVICE	FIXED_PARTITION_DEVICE(NVS_PARTITION)

Alternatively is there another way I can store 100 bytes or so non volatile? In hindsight I wish I had added an external EEPROM to my board but it's too late for that now.

[Simonr]

Hi Nick

I can confirm I've recreated this on the DFUTest sample you uploaded now. The error seems to come from the nvs_prev_ate() in nvs.c. The settings use one sector, the app can't use three sectors of the storage_partition when using settungs, If you want/need to use the settings here, max sector_count can only be 2U with the following:

   fs.sector_size = info.size;

   fs.sector_count = 2U;

If you change this, the error will be resolved. Moving over to sysbuild and adding the BT DIS settings is what toppled the application here. You can get a better overview of your systems storage and partitions in the memory report which is part of the nRF Connect extension in VS Code.

Best regards,

Simon