using NVS on NET CPU

[anthony32086]

Hello,

I am trying to get the nvs driver working on the NET cpu and am having trouble getting the initialization working. The code below is what I am currently working with to give some context.

static struct nvs_fs fs;

...

int ret;
struct flash_pages_info info;

fs.offset = FLASH_AREA_OFFSET(storage);

ret = flash_get_page_info_by_offs(
	device_get_binding(DT_CHOSEN_ZEPHYR_FLASH_CONTROLLER_LABEL),
	fs.offset, &info);
	
if (ret) {
	LOG_ERR("Unable to get page info");
	return ret;
}

I have traced the issue down to the macro FLASH_AREA_OFFSET(storage) which on the net CPU inserts the value pulled from the device tree which is 0x0003a000 (default storage partition on nrf5340-dk cpunet).

On the APP cpu this works fine since the storage offset (0xfa000) is smaller than the total flash size (0x100000). However because I am working in the net domain, the flash partition starts at 0x01000000 per the datasheet so in actuality the value that is returned by the macro during compilation is 0x0103a000. This causes an error when trying to get the page info since the offset is larger than the end address 0x40000 (256KiB) of the net flash partition calculated in flash_page_layout.c.

When I tried to modify the end calculation to include the base start address in the end address is_regular_addr_valid returns false since due to the initial flash offset 0x01000000 any address is larger than flash_size (0x40000).

When a flash read/write is performed on the NET cpu flash, is the offset implicitly included in all accesses? ie: writing to 0x0003a002 actually physically writes to 0x0103a002. Then if that's the case would I simply need to remove 0x01000000 from fs.offset?

[anthony32086]

Solved it, I ran some tests with the code changed to,

fs.offset = FLASH_AREA_OFFSET(storage) - DT_REG_ADDR(DT_CHOSEN(zephyr_flash));

then flashed with --recover to wipe all flash. Memory inspector on the NET core show both 0x0003a00 and 0x0103a00  addresses with 0xFFFFFFFF. Then after a nvs_write to id 1 memory inspector shows  memory @ 0x0003a00 contains 0xFFFFFFFF however 0x0103a00  does show new data that was written.

It seems the nRF5340 does implicitly translate writes to flash on the net core to include the base address.

Interesting that FLASH_AREA_OFFSET(storage) returns the correct offset address (0x0003a00) from devicetree_unfixed.h since a BUILD_ASSERT( FLASH_AREA_OFFSET(storage) == 0x0003a00) on the net core does not fail compilation.

However when the value is printed to the console, 0x0103a00 is returned so something else under the hood is happening to give the absolute address rather than a relative address, perhaps a linker config issue.