Using sd_flash_write in FreeRTOS

[CktDesigner]

I'm using the nRF52832 with FreeRTOS and nRF5_SDK_17.0.2 on a custom board.

I am using a peripheral from a third party that uses Flash storage for certain parameters.   

When I use the driver using "bare-metal" techniques (no OS, just interrupt driven) everything works fine (including writing to the flash).

I'm trying to integrate this driver into FreeRTOS.   I have all of the major functions working in FreeRTOS except for writing Flash via "sd_flash_write".   I can set a breakpoint, step through and see that the call to this function (in the SD) never returns.

My FreeRTOS setup has a task for BLE (as provided in the Nordic port) and "normal" BLE functions work as expected (including reading the Flash).

If I comment out the write to Flash in the third party driver, all the other functionality of the third party driver work as expected (as integrated into FreeRTOS).

But if I enable the call to write the Flash, that call never returns and the system hangs.

I can't post the code, but am hoping that you may have some ideas what is happening.    Is there some other "hook" needed to allow the SD write flash work with FreeRTOS?

Thanks!

[CktDesigner]

Hi Hung,

Yes.   I added "flash_test()"  (and the associated event handler) to my code and called it from the logger thread (before it enters the task loop) as shown in the example you provided.   

The write call from the logger thread performs the write, and logs that it has written to flash.   

But later in the code, where my call initiates a write to the flash via fds, the write hangs/crashes.

My calls worked in a "bare-metal" environment, but now fail after porting the application to FreeRTOS.

I have approximately 16 FreeRTOS tasks running at various priority levels.   None of them consume much CPU power, so the CPU is idle most of the time (by design).     BLE is advertising as expected and scanning for other BLE devices, so the BLE/SoftDevice appears to be working as expected.

Any insight is appreciated!

Thanks!

[Hung Bui]

Hi Ed,

We would need to have more data about the crash to find what could be the issue. It would be easier for us if you can provide a minimum example that can reproduce the issue so that we can test here. Could you try to implement the fds write in the HRS FreeRTOS example and check if you get the same error. 

Or you can try removing other features in your application to make it as similar to the HRS FreeRTOS as possible and still showing the error. 

[CktDesigner]

Hi Hung,

I got the Flash writes to work by reducing the priority of all FreeRTOS tasks to "tskIDLE_PRIORITY" (which is level 0, or the lowest priority), but leaving the priority of the BLE task at the hard-coded level 2 as shown in the example.

This raises some questions about the needs of the soft device task, etc.    Does it simply have to be the highest priority task?

Can you shed any light on the requirements of this task?

Thanks!

[Susheel Nuguru]

Hi Ed,

CktDesigner said:

I got the Flash writes to work by reducing the priority of all FreeRTOS tasks to "tskIDLE_PRIORITY" (which is level 0, or the lowest priority), but leaving the priority of the BLE task at the hard-coded level 2 as shown in the example.

If reducing the priorities your application freertos tasks to be lower than the BLE task works for you, then it means that before your change, your tasks are not yielding properly to give a chance for the softdevice task to pull the events. Seems like the application tasks are waiting indefinitely for the flash event to happen without yielding or timeout and the flash event cannot come since the task is not yielding the cpu for the ble event task to pull the softdevice events eventually.

CktDesigner said:

This raises some questions about the needs of the soft device task, etc.    Does it simply have to be the highest priority task?

It does not need to be high priority task as long as other higher priority tasks are behaving and yielding to let the softdevice task pull events.

CktDesigner said:

Can you shed any light on the requirements of this task?

This task is pretty simple. When SD_EVT_IRQHandler is triggered, hinting that there are SD events waiting to be pulled, this softdevice task then just pulls events from the softdevice and call the appropriate event handlers.