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

Notifying the nRF52840 when Bluetooth connection shall be terminated

Hi,

I am trying to disconnect an Android smartphone from the nRF52840. After trying for some time we found out that the BLE stack of Android does not reliably closes a Bluetooth connection (also according to some forums). Now we plan to implement a workaround, so that the nRF52840 initiates the closing of the connection. It seems to me that I need to use the sd_ble_gap_disconnect function on the nRF52840 to disconnect from the Android smartphone. My code is based on the ble_proximity example so I already have implemented the ble_evt_handler in which I could use the sd_ble_gap_disconnect function.

However we need a solution, where the smartphone can notify the nRF52840 that it wants to discontinue the connection, after which the nRF52840 calls the sd_ble_gap_disconnect function. 

A first idea was to reuse a BLE GAP event that we do not use otherwise. We would trigger such an event on the smartphone, which would be the indicator for the nRF52840 that the connection can be closed. But this idea seems to be a little bit unprofessional. One reason why we developed this idea is, that I cannot really close the connection outside of the ble_evt_handler function, because "p_ble_evt->evt.gatts_evt.conn_handle" is only known in this function. Or do I have another option to access connection handles outside the event handler function?

Here is the relevant code (ble_evt_handler).

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    ret_code_t err_code = NRF_SUCCESS;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_DISCONNECTED:
            //advertising_start(false);
            NRF_LOG_INFO("Disconnected.");
            printf("BLE disconnected\r\n");
            // LED indication will be changed when advertising starts.
            break;

        case BLE_GAP_EVT_CONNECTED:
        {
            NRF_LOG_INFO("Connected.");
            printf("BLE connected\r\n");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);

            // Assign connection handle to the Queued Write module.
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, p_ble_evt->evt.gap_evt.conn_handle);
            APP_ERROR_CHECK(err_code);

            // Discover peer's services.
            err_code = ble_db_discovery_start(&m_ble_db_discovery,
                                              p_ble_evt->evt.gap_evt.conn_handle);
            APP_ERROR_CHECK(err_code);
        } break;

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;

        case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.
            NRF_LOG_DEBUG("GATT Client Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GATTS_EVT_TIMEOUT:
            // Disconnect on GATT Server timeout event.
            NRF_LOG_DEBUG("GATT Server Timeout.");
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;
            
        default:
            // No implementation needed.
            break;
    }
}

Are there any good workarounds to this problem?

SW/HW ver:

  • SDK 17.0.2
  • nRF52840 DK (PCA10056, 2.0.1)
  • SEGGER Embedded Studio, ver 4.50

Thank you in advance.

Parents Reply Children
No Data
Related