Hang in fstorage from assert handler

[kfinch]

SDK 16

nRF52840 with s140

Hello, 

I'm working on implementing an assert handler and would like to store the file/line hash in NVM. I currently have fstorage configured with the SD backend and in general have not any issues with writing to NVM except in this scenario.

The problem I am seeing is when an assert in FreeRTOS timer code occurs, that the _wait_for_flash_ready() call hangs. In my troubleshooting, I have found that replacing nrf_delay_ms() with vTaskDelay inside _wait_for_flash_ready() works fine. With other asserts from lower priority tasks, the nrf_delay_ms() works fine. I've seen lots of other posts where the issue ends up being a priorities. But since this is from the assert handler and will be called from many different priority levels, how can I ensure that fstorage will get the time it needs to execute?

Also, why is it that the task delay works when the nrf_delay does not?

Thanks!

[Einar Thorsrud]

Hi,

why is it that the task delay works when the nrf_delay does not?

There is a fundamental difference with these two approaches. With nrf_delay_ms() the task keeps executing, just doing some dummy calculations with known cycle times to keep the CPU busy for the specified amount of time. This will block any other tasks with (same or) lower priority. With vTaskDelay() the task does not run in the mean time, but effectively tells the FreeRTOS scheduler to do something else in the mean time, making it possible for other (lower priority tasks to run). 

how can I ensure that fstorage will get the time it needs to execute?

typically in an assert handler you just want to log something to flash (like I assume you do), or some cleanup or something else. Typically you don't care much about what happens after this. So whatever works should be OK if a reset is the nexts to follow. If you use the SoftDevice API to write to flash and need to get events back, then you cannot do this from an interrupt priority that is same or higher than the SoftDevice, and espessially not when busy waiting. That way the SoftDevice will code handling flash write events will not run. So you either need to always call from a different priority (other task), or if this is the last act before dying, perhaps disable the SoftDevice and write to flash directly in a high priority task could make sense.