FDS and fds_register/fds_evt_handler: parallelism of event handler and other tasks?

[MarieMaurer]

Hello,

I am using FDS successfully with SDK 17.0.2, secure bootloader and softdevice. Bluetooth (BLE) environment, if it does matter.

I can read and write data. But following question occurs:

Assume I have code which calls

fds_record_write

After this call my code does other things, e.g. multiple times NRF_LOG_INFO. I name this "code 1".

Now the write actions is done and calls the FDS event handler to signal

FDS_EVT_WRITE

Inide this "code 2" is executed.

Is it correct that while "code 1", I get sometimes interrupted and "code 2" is executed?

If "code 1" as well as "code 2" uses NRF_LOG_INFO, can it interfer? I am using LOG_DEFERRED.

Could it be I run in a deadlock or unwanted behaviour due to race conditions?

I tried flush, but found that debugging with serial UART seems to use this:

static void nrf_log_backend_uart_flush(nrf_log_backend_t const * p_backend)
{
    
}

So is it just a NOP? Or doing something somewhere else?

Log output is only one side, what other thing are not allowed to be called from fds_evt_handler?

Or are allowed things very limited, so perhaps only setting some variables and almost immediately return?

Is there some documentation or hint, what to consider?

Many thanks!

Best regards,

Marie

[Jørgen Holmefjord]

Hi,

Is it correct that while "code 1", I get sometimes interrupted and "code 2" is executed?

Yes, if code 2 runs at a higher interrupt priority than code 1, it will preempt the execution of the lower priority code in order to handle its own tasks first. 

If "code 1" as well as "code 2" uses NRF_LOG_INFO, can it interfer? I am using LOG_DEFERRED.

Log buffers are allocated before logs are stored through buf_prealloc function. This function uses CRITICAL_REGION macros to prevent other application tasks from preempting it during buffer allocation. Once the buffer is allocated, the logger frontend will use this buffer for storing the logs. If code 2 preempts code 1 before the log buffer is allocated, it will insert its log before code 1.

Could it be I run in a deadlock or unwanted behaviour due to race conditions?

If you wait for something inside a higher priority interrupt handler that is supposed to be handled in a lower priority (or same) priority handler, you may cause a deadlock.

I tried flush, but found that debugging with serial UART seems to use this:

static void nrf_log_backend_uart_flush(nrf_log_backend_t const * p_backend)
{
    
}

So is it just a NOP? Or doing something somewhere else?

NRF_LOG_FLUSH() calls NRF_LOG_INTERNAL_FLUSH(), which calls NRF_LOG_INTERNAL_PROCESS() and finally nrf_log_frontend_dequeue().

Log output is only one side, what other thing are not allowed to be called from fds_evt_handler?

Or are allowed things very limited, so perhaps only setting some variables and almost immediately return?

Is there some documentation or hint, what to consider?

The same goes as described above regarding interrupt priorities. One example is that softdevice APIs cannot be run in a handler running at priority higher than 4, as the SD APIs itself runs at priority 4. In general it is good to return from handlers as fast as possible, it it is not handling a timing critical task. You can use app_scheduler or flags to handle lower priority tasks during idle time in main-loop.

Best regards,
Jørgen