Using wait_for_flash_ready() causes firmware to restart after exception

[crl]

Hi,

this is kind of continuation of my previous ticket. After solving it the last time I thought that I don't need wait_for_flash_ready() function as it caused some problems and the code was working good enough without it. Right now I face the problem once again, but this time I know nrf_fstorage_write is not reliable in terms of saving just in time before reboot (I have to reboot and reload data to RAM after writing to flash, this was a way the previous developer solved an issue). I have to use wait_for_flash_ready() as it is the only way to make sure flash is saved properly which is what I have problem with. In my opinion just adding a wait for the flag is enough to ensure data is saved properly and then go with what the code does right now.

I am using copied parts of code from fstorage example. When the code calls wait_for_flash_ready() it reaches SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void)); in nrf_soc.h (sdk/components/softdevice/s132/headers) and there an exception occurs.

The main problem is that I receive some data (200 bytes) via Bluetooth, I have to write it to flash, reboot, read flash and throw the data into RAM, use it for calculations. Problem is that I am not sure the data is saved properly plus 3 of 200 bytes are always changed in comparison to what I received. For example I should receive 0x21 as the last byte but the code says it got 0xE4, after reading the flash it once again is 0x21. In another place I receive 0xB7 0x03 but after sending it to function as a pointer I know that it changed to 0x05 0x04. This is odd, so I'm trying to cover all deficiencies in code.

Extending or even removing scheduled reboot does not work. I can wait for a few minutes (without wait_for_flash_ready in code) but it looks like nothing changes.
In sdk_config I have FDS_BACKEND configured to use SD (FDS_BACKEND 2).

Small recap: I'm using SDK 17.0.2, my IDE is VSCodium (VSCode) under Linux with GCC as a compiler for nRF52832.

Any idea what goes wrong?

[Jared]

Hi,

I am using copied parts of code from fstorage example. When the code calls wait_for_flash_ready() it reaches SVCALL(SD_APP_EVT_WAIT, uint32_t, sd_app_evt_wait(void)); in nrf_soc.h (sdk/components/softdevice/s132/headers) and there an exception occurs.

What kind of error is thrown? Could you share a screenshot from debug view highlighting the error?

regards

Jared 

[crl]

There is no error during J-Link - terminal debugging but using Cortex Debug plugin in VSCode throws "Exception has occured" as a baloon and not much else. In terminal I can see that even if I let the program run without breakpoints it stops at specific points where flash is erased or written to.

[Jared]

Hi,

Could you share your code?

In sdk_config I have FDS_BACKEND configured to use SD (FDS_BACKEND 2).

This definition is relevant for the flash data storage(fds) module, not the flash storage(fstorage) module which is a lower-level module. 

regards

Jared

[crl]

Hi,

Unfortunately I cannot share my code explicitly, rewriting it to paste it here might not be useful as it will look like the one used in an example.

As my collegue found, the sdk_config.h used in this project is older than used sdk (copyright 2019 vs 2020). Might that or inproperly configured config file be the case?
I will include the newer one first, then include project-oriented config and check if it will help.

[EDIT]

I found out that sdk_config.h is oddly included, I will redo it. For previous testing I just added two includes into main but nothing changed, nrf_wait_for_flash_ready() still causes a restart.

I found out why previously I just used __WFE(). Function power_manage from fstorage example has a macro that depends on SD (if it is present) but the only difference is that with SD present it returns NRF_SUCCESS. If I put __WFE() into my wait_for_flash_ready function it will crash. __WFE is a macro defined in CMSIS, so it should be properly working. I will investigate how the CMSIS is used as that will probably be the source of all this hassle.
[I was wrong here. VSCode sent me to wrong file (nrf_soc_nosd). I should've looked at softdevice/s132/headers/nrf_soc.h and here sd_app_evt_wait is called by SVCALL which causes the fault. Anyway, __WFE used directly causes fault too, but it should not be used with SD.]

[Jared]

Hi,

Could you show the call stack from debug view? What context are you calling wait_for_flash_ready() from, and what interrupt priority do you have on the fstorage module? 

regards

Jared 

[crl]

In the attachement there is a screenshot of call stack from VSCode.

I'm calling wait_for_flash_ready() right after nrf_fstorage_write or nrf_fstorage_erase. I was looking through the code but I cannot find any interrupt priority modifications. In the code I have a comment by my predecessor:

NRF52 sdk is relatively high-level, no raw interrupt handling is done by us,
except for the hard fault handler.

So I think I can assume that fstorage has the standard priority, whatever it is. Is there any way to check it?

[Jared]

Hi,

The call stack shows that the wait_for_flash_ready() is called in interrupt context from a BLE event, which again calls the sd_app_evt_wait(). This is most likely causing the issue because the program is waiting for a lower priority event to complete from a higher priority event.

If you want to do a reset after the wait_for_flash_ready() has completed then I would first move wait_for_flash_ready() to the main loop so that it runs in the main context. Next, set a flag in the BLE interrupt routine that is checked in the main loop and signalizes that wait_for_flash_ready() can be called. After that I would use the power management module and call NRF_PWR_MGMT_CONFIG_AUTO_SHUTDOWN_RETRY instead of sd_app_wait() for the nRF to reset. See the power management example in the SDK for a reference on how the module is used.

regards

Jared