Event driven nrf_ble_lesc_request_handler

[Ingo]

Dear community

I'm developing BLE secure firmware on an event-driven proprietary RTOS.

According to the documentation of nrf_ble_lesc_request_handler(), it is required to be called cyclically, e.g. in the main loop. Not having a main loop per se, I was wondering if it is ok to call this function in the BLE event handler (NRF_SDH_BLE_OBSERVER).

My first tests confirmed that it is working, but the question remains whether this is allowed in general or if it will fail in certain scenarios.

Anyone with experience or insight? Any inputs are greatly appreciated!

[Sigurd]

Hi,

I would not recommend it, as you are potentially blocking the processing of new BLE events, or other interrupts, while nrf_ble_lesc_request_handler() is calculating the DH key. Most RTOS’s have some kind of idle thread that puts the CPU in idle(WFE/WFI), I recommend adding the function nrf_ble_lesc_request_handler() to that thread.
E.g. for FreeRTOS it can be done like this:

/**@brief A function which is hooked to idle task.
 * @note Idle hook must be enabled in FreeRTOS configuration (configUSE_IDLE_HOOK).
 */
void vApplicationIdleHook( void )
{
#if NRF_LOG_ENABLED
     vTaskResume(m_logger_thread);
#endif
  nrf_ble_lesc_request_handler();
}

[Ingo]

Great input, thanks Sigurd.

The way we did it in the end is to run nrf_ble_lesc_request_handler() as a task on an OS event loop. The task is enqueued when the BLE_GAP_EVT_LESC_DHKEY_REQUEST is received.

That way nrf_ble_lesc_request_handler() is not blocking the processing of BLE events and also it is only called when needed.