I have always understood it to be dangerous to invoke a call in a callback. It is not clear to me what the callback model is in SoftDevice so I would like to know when it is safe to invoke sd_* calls when handling BLE events. In the pc-ble-driver example code I see this case in the BLE event handler:
case BLE_GATTS_EVT_EXCHANGE_MTU_REQUEST:
err_code = sd_ble_gatts_exchange_mtu_reply(adapter, m_connection_handle, GATT_MTU_SIZE_DEFAULT);
which suggests that it IS okay to invoke sd_* calls in callbacks.
However, I am having terrible issues when trying to invoke this reply in another case in the BLE event handler:
case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
{
ble_gap_sec_params_t sec_params = p_ble_evt->evt.gap_evt.params.sec_params_request.peer_params;
....
uint32_t result = sd_ble_gap_sec_params_reply(adapter, p_ble_evt->evt.gap_evt.conn_handle, BLE_GAP_SEC_STATUS_SUCCESS,
own_sec_params, keys);
I am wondering if it is the attempt to invoke the call on the 'receive' thread that is causing the problem or something else. The input parameters are all fine according to the documentation, and just to make sure I printed them out before the call.
Is the appropriate way to handle nFR5280 operations to run from a endlessly cycling while loop in main, only invoking methods at most once per cycle? In other words, in the callback just set some global state variable and return, and then handle that state in the while loop. This is the typical approach used on an OS-less embedded platform. But I do not see any indication of that approach in the ble heart rate example.
