RE: Timeslot bluetooth TX causes freeze when not in data handler

bjorn-spockeli — Thu, 12 Dec 2019 14:15:49 GMT

HI Jonathan,

[quote user=""]I use Softdevice S110 on the NRF52832 and SDK12.3.0_d7731ad.[/quote]

I assume that S110 is a typo since the S110 is not supported on the nRF52832 ,see SDKs and SoftDevices.

[quote user=""]Whenever the function unit_event_tx is being called, the unit freeze. And when the function is called outside of here, like on button push, nothing happens.[/quote]

You are trying to call ble_nus_string_send, which triggers a Bluetooth Handle Value Notification using sd_ble_gatts_hvx() , see the definition of ble_nus_string_send below:

uint32_t ble_nus_string_send(ble_nus_t * p_nus, uint8_t * p_string, uint16_t length)
{
    ble_gatts_hvx_params_t hvx_params;

    VERIFY_PARAM_NOT_NULL(p_nus);

    if ((p_nus->conn_handle == BLE_CONN_HANDLE_INVALID) || (!p_nus->is_notification_enabled))
    {
        return NRF_ERROR_INVALID_STATE;
    }

    if (length > BLE_NUS_MAX_DATA_LEN)
    {
        return NRF_ERROR_INVALID_PARAM;
    }

    memset(&hvx_params, 0, sizeof(hvx_params));

    hvx_params.handle = p_nus->rx_handles.value_handle;
    hvx_params.p_data = p_string;
    hvx_params.p_len  = &length;
    hvx_params.type   = BLE_GATT_HVX_NOTIFICATION;

    return sd_ble_gatts_hvx(p_nus->conn_handle, &hvx_params);
}

In a RADIO timeslot, the SoftDevice is temporarily disabled so that the RADIO can be freely used for another purpose, in your case ESB. So while the timeslot is open, you cannot call any functions from the SoftDevice API and sd_ble_gatts_hvx() is one of them, as it has the sd_-prefix.

However, calling ble_nus_string_send() outside the timeslot and outside the nus_data_handler should work just fine. Can you run your code in a debug session and check the return value of sd_ble_gatts_hvx() inside ble_nus_string_send() when you call it outside a timeslot and outside the nus_data_handler?

Alternatively, you can set a breakpoint in app_error_handler_bare() and/or app_error_handler ( if you have DEBUG set in your Preprocessor Definitions). If you enter this error handler it means that a APP_ERROR_CHECK() macro has caught a non-zero return code from a function. Looking at the call stack should point you to which function that is the culprit.

Best regards

Bjørn