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,

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