Hard fault when using NVS with Zephyr on nRF52

[NathanML]

I'm attempting to write to flash memory on our custom board using the nRF52840 using the NVS library in Zephyr 1.5.0. I've ported over the example code from samples/subsys/nvs and nvs successfully initializes:

[00:00:01.011,199] <inf> fs_nvs: 3 Sectors of 4096 bytes
[00:00:01.011,535] <inf> fs_nvs: alloc wra: 0, f40
[00:00:01.011,901] <inf> fs_nvs: data wra: 0, 133

The storage file system structure is initialized identically to the example code.

But, when I go to actually save data, I get a hard fault, specifically MPU Fault:

[00:00:04.200,897] <err> os: ***** HARD FAULT *****
[00:00:04.201,416] <err> os:   Fault escalation (see below)
[00:00:04.201,934] <err> os: ***** MPU FAULT *****
[00:00:04.202,423] <err> os:   Data Access Violation
[00:00:04.202,911] <err> os:   MMFAR Address: 0xf8130
[00:00:04.203,460] <err> os: r0/a1:  0x4001e400  r1/a2:  0x00000000  r2/a3:  0x4001e504
[00:00:04.204,223] <err> os: r3/a4:  0x01ffffff r12/ip:  0x20000aa4 r14/lr:  0x000053f3
[00:00:04.205,017] <err> os:  xpsr:  0x81000018
[00:00:04.205,535] <err> os: Faulting instruction address (r15/pc): 0x000054d4
[00:00:04.206,176] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0
[00:00:04.206,848] <err> os: Fault during interrupt handling

[00:00:04.207,397] <err> os: Current thread: 0x20001b60 (unknown)
[00:00:04.223,052] <err> fatal_error: Resetting system

My prj.conf file includes the same lines from the example, specifically CONFIG_MPU_ALLOW_FLASH_WRITE=y which I saw was mentioned as a fix on some git tickets.

This is all on a custom board, with the devicetree based on the nRF52840DK and successfully working with our board specific peripherals. Nothing in the flash memory section has been changed.

Also strange is that when running the default nvs code on the dev kit, I get this error: <err> flash_nrf: not word-aligned, followed by the memory address, for every attempted write. 

Thanks in advance for your help!

[Simon]

Regarding "error: <err> flash_nrf: not word-aligned", check out this PR: https://github.com/zephyrproject-rtos/zephyr/pull/34592. You should also set CONFIG_MPU_ALLOW_FLASH_WRITE=n.

NathanML said:

. I'm guessing that I didn't erase the flash prior to migrating from my previous FDS

FDS and NVS ar completely different, so there won't be any compatibility between these.

Best regards,

Simon

[NathanML]

Hi Simon,

That's good to know, thanks!

What is the purpose of setting CONFIG_MPU_ALLOW_FLASH_WRITE to n instead of y?

[DaWaN]

I am suffering from the same issue, getting Hard Faults on the MPU when using NVS.
I am using an NRF52DK board with nRF52832. I am using the nRF Connect SDK V1.8.0
When I build the NVS samples they work when using the nRF52DK board config, but they do not work with my own board config.
The issue occurs within the function nvs_write when it starts requesting the MPSL timeslot. The program counter also matches the MPSL library when checking the map file. So the issue seems MPSL related.
I have been digging through the config files, comparing the different board configs and almost everything seems identical. I noticed only one warning and I think it is related to the issue. The warning I am seeing is this: # CONFIG_TEMP_NRF5_MPSL is not set

This is the logging I get when the issue gets triggered:

<err> os: ***** HARD FAULT *****
[00:00:01.050,384] <err> os:   Fault escalation (see below)
[00:00:01.050,415] <err> os: ***** MPU FAULT *****
[00:00:01.050,415] <err> os:   Data Access Violation
[00:00:01.050,415] <err> os:   MMFAR Address: 0x20005bd4
[00:00:01.050,415] <err> os: r0/a1:  0x00008672  r1/a2:  0x0000003b  r2/a3:  0x00000000
[00:00:01.050,415] <err> os: r3/a4:  0x00000036 r12/ip:  0x000086ad r14/lr:  0x00000000
[00:00:01.050,445] <err> os:  xpsr:  0x61000000
[00:00:01.050,445] <err> os: Faulting instruction address (r15/pc): 0x00000b6a
[00:00:01.050,445] <err> os: >>> ZEPHYR FATAL ERROR 0: CPU exception on CPU 0

Would be nice if someone with more knowledge about the MPSL library can shed some light on this, as I would like to have this problem solved.

[DaWaN]

I further checked my MPU fault and the MMFAR address was pointing at the stack and remarkable close to the edge of it.
Changed my main stack size to 2048 (CONFIG_MAIN_STACK_SIZE=2048) and this fixed the issue for my board config.
Not sure what inside my board config lead to the higher stack usage, but this solved my problem.

[Simon]

Could you open a new case and explain your problem there? Then it will get a assigned to an engineer that will take care of it

Best regards,

Simon