This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Mismatch between connection handles in ble_nus?

I'm using the nus_c service with multiple central connections. Obviously, I need the connection handle in my event handler - ble_nus_c_evt_handler(ble_nus_c_t* p_ble_nus_c, const ble_nus_c_evt_t* p_ble_nus_evt).

I've noticed that when BLE_NUS_C_EVT_NUS_RX_EVT is raised, the connection handle in the NUS context object and the event object are different: p_ble_nus_c->conn_handle == 1, as expected, while p_ble_nus_evt->conn_handle == 0.

I've traced it down to on_hvx() in ble_nus_c.c, not setting the connection handle from the GATTC event to the ble_nus_c_evt_t structure it dispatches.

Is this by design or a bug?

Parents
  • Hello,

    I just tested with SDK 15.3 and 16.0 and the problem is still there. The solution still works well.

    I added ble_nus_c_evt.conn_handle = p_ble_nus_c->conn_handle; in function on_hvx

    **@brief     Function for handling Handle Value Notification received from the SoftDevice.
     *
     * @details   This function will uses the Handle Value Notification received from the SoftDevice
     *            and checks if it is a notification of the NUS TX characteristic from the peer. If
     *            it is, this function will decode the data and send it to the
     *            application.
     *
     * @param[in] p_ble_nus_c Pointer to the NUS Client structure.
     * @param[in] p_ble_evt   Pointer to the BLE event received.
     */
    static void on_hvx(ble_nus_c_t * p_ble_nus_c, ble_evt_t const * p_ble_evt)
    {
        // HVX can only occur from client sending.
        if (   (p_ble_nus_c->handles.nus_tx_handle != BLE_GATT_HANDLE_INVALID)
            && (p_ble_evt->evt.gattc_evt.params.hvx.handle == p_ble_nus_c->handles.nus_tx_handle)
            && (p_ble_nus_c->evt_handler != NULL))
        {
            ble_nus_c_evt_t ble_nus_c_evt;
    
            ble_nus_c_evt.evt_type = BLE_NUS_C_EVT_NUS_TX_EVT;
            ble_nus_c_evt.p_data   = (uint8_t *)p_ble_evt->evt.gattc_evt.params.hvx.data;
            ble_nus_c_evt.data_len = p_ble_evt->evt.gattc_evt.params.hvx.len;
            
            /* Modifed here to solve the problem conn_handle update */
            ble_nus_c_evt.conn_handle = p_ble_nus_c->conn_handle;
    
            p_ble_nus_c->evt_handler(p_ble_nus_c, &ble_nus_c_evt);
            NRF_LOG_DEBUG("Client sending data.");
        }
    }

    Best regards,

         Duy

Reply
  • Hello,

    I just tested with SDK 15.3 and 16.0 and the problem is still there. The solution still works well.

    I added ble_nus_c_evt.conn_handle = p_ble_nus_c->conn_handle; in function on_hvx

    **@brief     Function for handling Handle Value Notification received from the SoftDevice.
     *
     * @details   This function will uses the Handle Value Notification received from the SoftDevice
     *            and checks if it is a notification of the NUS TX characteristic from the peer. If
     *            it is, this function will decode the data and send it to the
     *            application.
     *
     * @param[in] p_ble_nus_c Pointer to the NUS Client structure.
     * @param[in] p_ble_evt   Pointer to the BLE event received.
     */
    static void on_hvx(ble_nus_c_t * p_ble_nus_c, ble_evt_t const * p_ble_evt)
    {
        // HVX can only occur from client sending.
        if (   (p_ble_nus_c->handles.nus_tx_handle != BLE_GATT_HANDLE_INVALID)
            && (p_ble_evt->evt.gattc_evt.params.hvx.handle == p_ble_nus_c->handles.nus_tx_handle)
            && (p_ble_nus_c->evt_handler != NULL))
        {
            ble_nus_c_evt_t ble_nus_c_evt;
    
            ble_nus_c_evt.evt_type = BLE_NUS_C_EVT_NUS_TX_EVT;
            ble_nus_c_evt.p_data   = (uint8_t *)p_ble_evt->evt.gattc_evt.params.hvx.data;
            ble_nus_c_evt.data_len = p_ble_evt->evt.gattc_evt.params.hvx.len;
            
            /* Modifed here to solve the problem conn_handle update */
            ble_nus_c_evt.conn_handle = p_ble_nus_c->conn_handle;
    
            p_ble_nus_c->evt_handler(p_ble_nus_c, &ble_nus_c_evt);
            NRF_LOG_DEBUG("Client sending data.");
        }
    }

    Best regards,

         Duy

Children
No Data
Related