Persistent storage

[Simon Feutrier]

Hello,

I have develop a solution that uses openThread with UDP. I want to keep in memory the UDP address of the last device that communicates with me. Thus in case of reset, my device will join again the network and send a sort of "ping" message to this UDP.

Sadly I have hard time storing this simple data. What is the simplest/best option ?

I have tried to use the nvmc of the nrfx library to write my data in the UICR register. But I have a problem: when doing an erase of the uicr register, firmware is crashing (in the z_arch... file so it gives me no hint).

Can you help on this ?

Thanks !

[Jørgen Holmefjord]

Hi,

UICR is not intended for writing data that will be frequently updated, as it is required to erase the full UICR page each time you write one register (it works like flash, where each bit can only be written from 1 to 0, 0 to 1 requires page erase). The flash have limited endurance of 10 000 write/erase cycles, which will wear out your UICR page quite quickly if you update the data every time communication from the last device changes.

If it is correct that you are using nRF Connect SDK (like your tags indicate), I would recommend that you look into Non-Volatile Storage (NVS) for storing data. This allows you to spread the writes over one or multiple pages, increasing the flash lifetime of your device. See the NVS: Non-Volatile Storage Sample for how to use the library.

Best regards,
Jørgen

[Jørgen Holmefjord]

Can you post the exact code you are using for writing UICR, and the exact crash error message you are seeing?

Accessing flash directly is not possible when the SoftDevice Controller is enabled, but I do not think OpenThread have similar limitations. Your code and error message should help indicate what is causing the crash.

[Simon Feutrier]

Hello,

Sorry for my late reply!

Problem happens when trying to erase with function "nrfx_nvmc_uicr_erase(...)"

00> I: Erasing page...
00> E: MPSL ASSERT: 112, 2784
00> E: ***** HARD FAULT *****
00> E:   Fault escalation (see below)
00> E: ARCH_EXCEPT with reason 3
00> 
00> E: r0/a1:  0x00000003  r1/a2:  0x200110b8  r2/a3:  0x200110b8
00> E: r3/a4:  0x00000001 r12/ip:  0x00000000 r14/lr:  0x0000f7f3
00> E:  xpsr:  0x4100001b
00> E: s[ 0]:  0x00000000  s[ 1]:  0x00000000  s[ 2]:  0x00000000  s[ 3]:  0x00000000
00> E: s[ 4]:  0x00000000  s[ 5]:  0x00000000  s[ 6]:  0x00000000  s[ 7]:  0x00000002
00> E: s[ 8]:  0x00000000  s[ 9]:  0x00000000  s[10]:  0x00000000  s[11]:  0x00000000
00> E: s[12]:  0x00000000  s[13]:  0x00000002  s[14]:  0x00000000  s[15]:  0x00000000
00> E: fpscr:  0x00000000
00> E: Faulting instruction address (r15/pc): 0x0000f7fe
00> E: >>> ZEPHYR FATAL ERROR 3: Kernel oops on CPU 0
00> E: Fault during interrupt handling
00> 
00> E: Current thread: 0x20002178 (unknown)
00> E: Resetting system

When doing "arm-none-eabi-addr2line -e .\build_840\zephyr\zephyr.elf 0x0000f7fe", it gives me the following:
...subsys/mpsl/init/mpsl_init.c:176 which is the "m_assert_handler" function.

[Jørgen Holmefjord]

Are you running a multiprotocol application with both Thread and BLE, or do you use Thread only?

If you are using BLE, the assert is definitely expected as you are not allowed to access the NVMC directly when the SoftDevice Controller is enabled. If you only use Thread, I need to check internally if MPSL itself will block access to NVMC.

The SoftDevice Controller provide APIs to safely perform flash write/erase operations, by scheduling the operations between other SoftDevice activity:

• sdc_soc_flash_write_async()
• sdc_soc_flash_page_erase_async()

The Zephyr flash drivers use these APIs when the SoftDevice Controller is enabled, to perform flash operations. Note that these APIs does not support UICR operations, as far as I know.

[Simon Feutrier]

My project is only with openThread. There is no Matter or BLE in my application. I use NFC for commissionning.

Thank you for checking, I wait your feedback then ;)

[Jørgen Holmefjord]

It is likely that the assert you are seeing from MPSL when directly calling nrfx_nvmc_uicr_erase is because the flash operation will halt the CPU, causing MPSL to be blocked from meeting its deadlines, leading to the assert.

The Zephyr flash driver interacts with MPSL through a sync API to schedule operations between radio operations, to prevent asserts. It seems that the Zephyr flash API also enables UICR operations through the Kconfig CONFIG_SOC_FLASH_NRF_UICR, however, I would highly recommend you to store your data in normal flash rather than UICR. The OpenThread stack already utilizes the settings subsystem to store network data, so using this for your own application data storage will not have a big impact on flash usage.

[Simon Feutrier]

Hi Jørgen Holmefjord ,

Thank your for this feedback. I guess the problem is the direct access to the UICR register. I am interested in the UICR register because it can be accessed easily from device and connected PC during production to know firmware version, device ID... Even if these data are modified dynamically. In this case, it seems that the Zephyr flash driver is the right thing to use.

But in the case of the udp address I guess the settings subsytem is the right approach.