Writing to and reading from flash on nRF5340

[Learner]

Hello,

I am trying to use part of the code from this example https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/subsys/nvs

to write to and read from flash on nRF5340 SoC. However, I am getting the following linking error when building the project in Segger.

I am using Segger v5.34a, NCS v1.5.0-rc1 and Zephyr v2.4.99-ncs1-rc1.

I am including the following header files

#include <zephyr.h>
#include <power/reboot.h>
#include <device.h>
#include <string.h>
#include <drivers/flash.h>
#include <storage/flash_map.h>
#include <fs/nvs.h>

Can you please help ?

1> Linking ‘zephyr_prebuilt.elf’
1> C:\Zypher\v1.5.0-rc1\toolchain\opt/bin/arm-none-eabi-gcc zephyr/CMakeFiles/zephyr_prebuilt.dir/misc/empty_file.c.obj -Wl,-T zephyr/linker.cmd -Wl,-Map=C:/Sandbox/PID4-Firmware/app_core/build_nrf5340pdk_nrf5340_cpuapp_flash/zephyr/zephyr_prebuilt.map -Wl,--whole-archive app/libapp.a zephyr/libzephyr.a zephyr/arch/common/libarch__common.a zephyr/arch/arch/arm/core/aarch32/libarch__arm__core__aarch32.a zephyr/arch/arch/arm/core/aarch32/cortex_m/libarch__arm__core__aarch32__cortex_m.a zephyr/arch/arch/arm/core/aarch32/cortex_m/mpu/libarch__arm__core__aarch32__cortex_m__mpu.a zephyr/arch/arch/arm/core/aarch32/cortex_m/cmse/libarch__arm__core__aarch32__cortex_m__cmse.a zephyr/lib/libc/newlib/liblib__libc__newlib.a zephyr/lib/posix/liblib__posix.a zephyr/soc/arm/common/cortex_m/libsoc__arm__common__cortex_m.a zephyr/boards/boards/arm/nrf5340pdk_nrf5340_cpuapp/libboards__arm__nrf5340dk_nrf5340.a zephyr/drivers/adc/libdrivers__adc.a zephyr/drivers/gpio/libdrivers__gpio.a zephyr/drivers/ipm/libdrivers__ipm.a zephyr/drivers/spi/libdrivers__spi.a modules/nrf/lib/fatal_error/lib..__nrf__lib__fatal_error.a modules/nrf/drivers/hw_cc310/lib..__nrf__drivers__hw_cc310.a modules/hal_nordic/libmodules__hal_nordic.a -Wl,--no-whole-archive zephyr/kernel/libkernel.a zephyr/CMakeFiles/offsets.dir/./arch/arm/core/offsets/offsets.c.obj -Lc:/zypher/v1.5.0-rc1/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/thumb/v8-m.main/nofp -LC:/Sandbox/PID4-Firmware/app_core/build_nrf5340pdk_nrf5340_cpuapp_flash/zephyr -lgcc -Wl,--print-memory-usage zephyr/arch/common/libisr_tables.a C:/Zypher/v1.5.0-rc1/nrfxlib/crypto/nrf_cc312_platform/lib/cortex-m33/soft-float/no-interrupts/libnrf_cc312_platform_0.9.7.a -mcpu=cortex-m33 -mthumb -mabi=aapcs -Wl,--gc-sections -Wl,--build-id=none -Wl,--sort-common=descending -Wl,--sort-section=alignment -Wl,-u,_OffsetAbsSyms -Wl,-u,_ConfigAbsSyms -nostdlib -static -no-pie -Wl,-X -Wl,-N -Wl,--orphan-handling=warn -lm -Wl,-lc -LC:/Zypher/v1.5.0-rc1/toolchain/opt/arm-none-eabi/lib/thumb/v8-m.main/nofp -u_printf_float -Wl,-lgcc -lc -specs=nano.specs -o zephyr\zephyr_prebuilt.elf
1> Memory region Used Size Region Size %age Used
1> FLASH: 73512 B 1 MB 7.01%
1> SRAM: 28680 B 448 KB 6.25%
1> c:/zypher/v1.5.0-rc1/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: app/libapp.a(pid4_flash.c.obj): in function `flash_get_page_info_by_offs':
1> C:\Sandbox\PID4-Firmware\app_core\build_nrf5340pdk_nrf5340_cpuapp_flash/zephyr/include/generated/syscalls/flash.h:85: undefined reference to `z_impl_flash_get_page_info_by_offs'
1> c:/zypher/v1.5.0-rc1/toolchain/opt/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: app/libapp.a(pid4_flash.c.obj): in function `flash_init':
1> C:\Sandbox\PID4-Firmware\app_core\build_nrf5340pdk_nrf5340_cpuapp_flash/../src/flash/pid4_flash.c:45: undefined reference to `nvs_init'
1> collect2.exe: error: ld returned 1 exit status
1> IDT_LIST: 104 B 2 KB 5.08%
Build failed

Kind regards

Mohamed

[Learner]

Hello,

I have just realised what the problem was. I needed to add this to my prj.conf file

CONFIG_FLASH=y
CONFIG_NVS=y

I have also noticed the existence of other APIs flash_read() and flash_write(). 

What is the difference between flash_read() and nvs_read() and the corresponding write APIs?

Kind regards

Mohamed

[Carl Richard]

Hi!

Great that you managed to fix the issue. The flash API is a more low level API used for interacting directly with the flash peripheral. The NVS API uses the flash API for easier organization and usage of storage. What you chose depends on your application, but NVS is commonly used for storing BLE bonding data for example.

Best regards,
Carl Richard

[Learner]

Hi Carl,

Thank you for your support.

Could you also please answer my other questions in my previous post? I edited it late last night.

With NVS, the user does not even know which flash location is being written to or read from because this is abstracted away from him/her. Maybe this is what I am not comfortable with. 

"Elements, represented as id-data pairs, are stored in flash using a FIFO-managed circular buffer. Each element is stored in flash as metadata (8 byte) and data. The metadata is written in a table starting from the end of a nvs sector, the data is written one after the other from the start of the sector. The metadata consists of: id, data offset in sector, data length, part (unused) and a crc...."

If I understood the above description right, each sector in flash will contain metadata starting from the end of the sector and data written at the start of the sector.

Is the size of the metadata always 8 bytes irrespective of whether I am writing 1 byte or 1 MB of data to flash?

Or does it grow as the data size grows?

Diagrams would have been very helpful to explain how NVS stores and retrieves data from flash.

Kind regards

Mohamed

[Learner]

Hi Carl,

I am trying to get familiar with NVS using the same example  https://github.com/zephyrproject-rtos/zephyr/blob/master/samples/subsys/nvs

So, I did three successive writes to flash changing the string address each time, with a reboot between each write. Note, each write is 12 (11 + 1) bytes long.

Why are we adding +1 to the length?

strcpy( buf, "192.168.1.1" );
printk( "No address found, adding %s at id %d\n", buf, ADDRESS_ID );
(void)nvs_write( &fs, ADDRESS_ID, &buf, strlen( buf )+1 );

*** reboot ***

strcpy( buf, "193.168.1.1" );
printk( "No address found, adding %s at id %d\n", buf, ADDRESS_ID );
(void)nvs_write( &fs, ADDRESS_ID, &buf, strlen( buf )+1 );

*** reboot ***

strcpy( buf, "194.168.1.1" );
printk( "No address found, adding %s at id %d\n", buf, ADDRESS_ID );
(void)nvs_write( &fs, ADDRESS_ID, &buf, strlen( buf )+1 );

*** reboot ***

After the third write/reboot sequence,

fs.offset = 0x000fa000

fs.ate_wra = 0x00000fd8

fs.data_wra = 0x00000024

This suggests I end up with all 3 addresses 192.168.1.1 193.168.1.1 194.168.1.1 stored in flash under the same ID ADDRESS_ID.

However, nvs_read( &fs, ADDRESS_ID, &buf, sizeof( buf ) ) reads only 194.168.1.1 i.e. the last address written despite the fact that fs.ate_wra = 0x00000fd8 and fs.data_wra = 0x00000024. Please can you explain why this is the case.

Thank you.

Kind regards

Mohamed

[Carl Richard]

Hi again!

I will see if I can provide some kind of explanation on the memory layout when using NVS tomorrow. In addition I see that earlier versions of Zephyr imposed a max size on the elements in NVS, but that's not present anymore. I will check if there are any limitations. 

Just want to note that this is a Zephyr provided API so you're free to report your suggestions through their support channels as well.

---

The "+1" when writing is reserved for the metadata I guess, but I'll double check this. From my understanding the NVS fs stores previously written data to some extent, which can be read out using nvs_read_hist(...). They demonstrate this in the NVS sample aswell.

Best regards,
Carl Richard

[Learner]

Thank you Carl,

I am looking forward to your answers.

Carl Richard said:

In addition I see that earlier versions of Zephyr imposed a max size on the elements in NVS, but that's not present anymore.

Which max size are you referring to?

Carl Richard said:

The "+1" when writing is reserved for the metadata I guess, but I'll double check this.

I think the +1 is for the extra NULL  ('\0') string terminator which is not included in the length returned by strlen().

Kind regards

Mohamed

[Carl Richard]

Hi again!

Did some research. The ate_wra is the "Allocation table entry write address", meaning that it's the location where the information about allocated data is stored. These are stored at the end of the sector, and you will see the offset decrease with new data being written. The fact that the offset in this case is "FF0" is given by the maximum size of a single write in NVS, which is sector_size - 3*ate_size. Based on the following comment from nvs.c:

/* The maximum data size is sector size - 3 ate
 * where: 1 ate for data, 1 ate for sector close
 * and 1 ate to always allow a delete.
 */

For the nRF52840 for example the ate_size is 8 and with a sector size of 4096 this gives us a ate_wra of 4096-16=4080=0x0FF0, with two ate's reserved for sector close and delete. I've visualized this in the attached image:


I think this answers both the question of metadata size and flash layout.

Best regards,
Carl Richard

[Carl Richard]

Hi!

It's my pleasure. 

Learner said:

I think you meant nRF5340 because this is the SoC I am using.

I did mean the nRF52840, as that was the SoC I was testing with. Evidently, it seems like the same values apply to the nRF5340 aswell.

---

Most of the questions below are answered in the sample description and NVS documentation, so please read those carefully. Here is a short summary:

Learner said:

Q1/ Where are the historical values for reboot_counter stored?

The historical values are stored in the same sector as the original data. Or rather, the historical values stay, while the new data is written to a new location in the sector.

Learner said:

Q2/ Why would we want to keep old values if we are overwriting with newer ones?

Historical data can be valuable in some applications. For example, NVS is commonly used for storing BT bonding data and it can be beneficial to have access to earlier stored bond information.

Learner said:

Q4/ Isn't this inefficient way of using flash? Instead of using 4 bytes we end up using Nx4 bytes of flash?

I'm not sure what you mean here? Each written piece of data is bundled with 8 bytes metadata. There is no other overhead except for the initial two pieces of metadata reserved for delete and sector close.

Learner said:

Q5/ Can history be disabled?

 No, it cannot.

---

To me it sounds like you want more control over your flash, in which case I suggest either using the flash API directly. If you have further inquires about the NVS implementation I'm sure the Zephyr team will be able to provide you with more detailed answers in their channels.

Best regards,
Carl Richard