nRF5340 - Setting Feature with Custom Partition

[skim]

1. nRF Connect SDK: v2.3

2. Problem Description / Question

I'm currently working on implementing a settings feature using either NVS or a file system (NVS preferred), alongside existing Bluetooth (BT) and littleFS functionality in my project. 

Here's a bit more context on my situation:

1. NVS for Settings vs. Bluetooth: I've been testing the default sample program, settings, and it works perfectly with either NVS or FS. However, when I try to merge this sample program into my existing project, which already utilizes Bluetooth, littleFS, and more, I encounter a fatal kernel error during the bt_enable(). My suspicion is that this issue might be related to a conflict between Setting's NVS settings.

2. Link Partition Defined in pm_static.yml to Overlay File: I found a POST, and an attached file in the post has a solution for addressing BT and NVS settings by creating a custom_nvs_storage partition in pm_static.yml. However, this project doesn't use settings handlers. In order to utilize settings handlers, my hypothesis is that I need to link the zephyr,settings-partition with the custom_nvs_storage defined in pm_static.yml. However, I haven't been able to find the exact procedure to do this. It seems like it should be a straightforward configuration, but I am struggling to make it work.

   /  {
       
       chosen {
           nordic,pm-ext-flash = &mx25r64;
           zephyr,settings-partition = custom_nvs_storage; // this throws an error saying cannot find custom_nvs_storage.
       };
   };
   

3. Create an Extra Partition for Settings in external_flash: I want to define an NVS partition in external_flash. Below is what I did, but it doesn't build.

   // in overlay, to define external_flash:
   /  {
       
       chosen {
           nordic,pm-ext-flash = &mx25r64;
       };
   };
   
   // -----------------------------
   //in pm_static.yml:
   
   custom_nvs_storage:
     address: 0x0
     end_address: 0x3fff
     region: external_flash
     size: 0x4000
   

If anyone has experience or knowledge related to these issues, I would greatly appreciate your guidance and insights. Any advice or pointers would be immensely helpful.

Thank you in advance for your assistance.

Best regards,

Skim.

[AHaug]

Hi,

For all three cases, can you also provide the following:

1. Can you provide the full build errors and/or device logs?
2. Can you provide the memory map, i.e use VS Code extensions tool or navigate to the build folder and report back what "ninja partition_manager_report' generates?
3. If you have a static_pm.yml for each of the cases, can you provide that as well?

Kind regards,
Andreas

[skim]

1. Here is a screenshot of a kernel fatal error. 

2. Here is a screenshot of a memory map

 

3. Here is a pm_static.yml file for each case

Fullscreen pm_static_ext_flash.txt Download

custom_nvs_storage:
  address: 0x0
  end_address: 0x3fff
  region: external_flash
  size: 0x4000

Fullscreen pm_static_flash_prim.txt Download

custom_nvs_storage:
  address: 0x0
  end_address: 0x3fff
  region: flash_primary
  size: 0x4000

Hope this helps.

Sincerely,

Sungji Kim.

[AHaug]

skim said:

1. Here is a screenshot of a kernel fatal error. 

What is posted beneath here? What is posted above the line? I need the entire log to be able to cipher anything from it. Please upload it as a text or insert code 

skim said:

2. Here is a screenshot of a memory map

This image is also cut off, can you reupload a full picture including all numbers

Kind regards,
Andreas

[skim]

Hello, I apologize for the truncated image. Here is the textual representation of the kernel error:

ASSERTION FAIL [handler != ((void *)0)] @ WEST_TOPDIR/zephyr/kernel/work.c:667
[00:00:00.807,373] <err> os: esf_dump: r0/a1:  0x00000004  r1/a2:  0x0000029b  r2/a3:  0x00000024
[00:00:00.807,403] <err> os: esf_dump: r3/a4:  0x0000029b r12/ip:  0xb6a93df4 r14/lr:  0x000351a7
[00:00:00.807,434] <err> os: esf_dump:  xpsr:  0x61100000
[00:00:00.807,495] <err> os: esf_dump: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
[00:00:00.807,525] <err> os: esf_dump: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000000
[00:00:00.807,556] <err> os: esf_dump: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
[00:00:00.252,716] <dbg> nrf5340dk_nrf5340_cpuapp: remoteproc_mgr_boot: Network MCU released.
[00:00:00.807,617] <err> os: esf_dump: s[12]:  0x00000000  s[13]:  0x00000000  s[14]:  0x00000000  s[15]:  0x00000000
[00:00:00.807,647] <err> os: esf_dump: fpscr:  0x00000000
[00:00:00.807,678] <err> os: esf_dump: Faulting instruction address (r15/pc): 0x0003cce8
[00:00os: z_fatal_error: >>> ZEPHYR FATAL ERROR 4: Kernel panic on CPU 0
[00:00:00.807,769] <err> os: z_fatal_error: Current thread: 0x20001ed8 (unknown)
[00:00:00.975,769] <err> os: k_sys_fatal_error_handler: Halting system

During my investigation into the issue, I managed to find a way to run the project without encountering the kernel error. This involved disabling the CONFIG_BT_SETTINGS. The documentation regarding this config value states, 

"When selected, the Bluetooth stack will take care of storing (and restoring) the Bluetooth state (e.g. pairing keys) and configuration persistently in flash"

Here is my question:

If I disable it, will the BT_SETTINGS feature be entirely deactivated? Would I then be responsible for handing the storage and restoration of BT state (including pairing keys)? If so, how should I proceed?

Another unresolved issue is that I want to

a) Define a partition in the 'external_flash' area using pm_static.yml (Currently, it is defined in the 'primary_flash' area as a name of custom_nvs_storage)

b) Utilize it as the backend for Settings in the overlay using 'zephyr, settings-partition'. 

c) Ensure that the memory area used by BT_SETTING is separated from the memory area used by regular Settings. 

Here I am attaching the project that I combines a project from the devzone and Settings sample. This project shouldn't build because I added a line in the overlay file to link settings' NVS and a custom_nvs_storage, and the system cannot find the custom partition. 

bt_setting_sample_from_devzone.zip

Feel free to let me know if you'd like further clarification or edits.

Thank you,

Sincerely,

Skim. 

[AHaug]

Hi,

Apologies for the delayed response, I had to check up on some things

1. In general we don't recommend you to remove the settings_partition that Bluetooth and/or Matter uses as this is a persistent part of the memory
2. After some input from the creator of the sample you refer to from  Setting and using NVS and BT Settings with Static Partition Manager :
   Adding another settings partition should be relatively straight forward, and can be done by
   1. Adding a new partition in pm_static.yml
   2. Change this line: https://github.com/nrfconnect/sdk-zephyr/blob/32a51d982e0b7eba7e458678a8246440b25c3916/samples/subsys/settings/src/main.c#L20 

skim said:

If I disable it, will the BT_SETTINGS feature be entirely deactivated? Would I then be responsible for handing the storage and restoration of BT state (including pairing keys)? If so, how should I proceed?

As the other case you refer to states, this is possible and the sample that Sigurd has provided showcases how to do this. Item number 1 in my previous list explains why you should not disable bt_settings and thus remove the persistant storage for the wireless protocols that use it. 

skim said:

a) Define a partition in the 'external_flash' area using pm_static.yml (Currently, it is defined in the 'primary_flash' area as a name of custom_nvs_storage)

developer.nordicsemi.com/.../partition_manager.htmlhttps://github.com/nrfconnect/sdk-zephyr/blob/32a51d982e0b7eba7e458678a8246440b25c3916/samples/subsys/settings/src/main.c#L20 and the Note in that section should explain how to do this

Regarding b) and c) I also believe that this should be handled by the sample Sigurd created. I will look closer into the sample at the end of this week, but in the meanwhile I hope this is enough to keep you going

Kind regards,
Andreas