nrf51822 ble UART Random disconnection

RE: nrf51822 ble UART Random disconnection

Stefan Birnir Sverrisson — Thu, 15 Sep 2016 06:42:04 GMT

Are you perhaps calling the ble_nus_buffer_send function from an interrupt context? If that is the case, it will block any softdevice callbacks, including the BLE_GAP_EVT_DISCONNECTED. The solution is to execute the ble_nus_buffer_send in main context, which enables any BLE callback to interrupt the wait in the ble_nus_buffer_send function. See the priority scheme here

RE: nrf51822 ble UART Random disconnection

Francois — Tue, 13 Sep 2016 22:09:47 GMT

Indeed, it could be the case. We are getting closer to a solution :-)

However when the connection is "brutal" and a TX is happening, "BLE_GAP_EVT_DISCONNECTED" is never reached... I could put "BtDataTxComplete == 1" there and exit the loop...

Would "BLE_GAP_EVT_TIMEOUT" happen in case of brutal disconnection?

See

switch (p_ble_evt->header.evt_id)
   {
    case BLE_GAP_EVT_CONNECTED:
        //err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
        //APP_ERROR_CHECK(err_code);
        LED_On();
        m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
        break;
        
    case BLE_GAP_EVT_DISCONNECTED:
        //err_code = bsp_indication_set(BSP_INDICATE_IDLE);
        //APP_ERROR_CHECK(err_code);
        LED_Off();
        isInPushMode = 0;
        m_conn_handle = BLE_CONN_HANDLE_INVALID;
        BtCommandWasReceived = COMMAND_EMPTY;
        break;

   case BLE_GAP_EVT_TIMEOUT:
 ...

Thanks again!

RE: nrf51822 ble UART Random disconnection

Stefan Birnir Sverrisson — Tue, 13 Sep 2016 16:05:01 GMT

Hi Francois

Correct me if I am wrong, but does your BtDataTxComplete flag check for the BLE_EVT_TX_COMPLETE event flag? If so, I can see this as normal behavior that your code waits in the while(BtDataTxComplete == 0) {}; loop if you have sent the BLE packet to the softdevice with ble_nus_string_send and have not received a BLE_EVT_TX_COMPLETE from the softdevice, which means that the packet has been sent. Then the packet is just waiting in a softdevice buffer and waiting to be sent. When you connect again with your phone, the packet is sent, which triggers a BLE_EVT_TX_COMPLETE event and the code continues execution.

RE: nrf51822 ble UART Random disconnection

RichieJH — Mon, 12 Sep 2016 22:18:47 GMT

We often see selecting disconnect in an Android app doesn't guarantee the Android will actually disconnect. So the nRF will think it is still in a connection. In Wireshark the stream of bits that keep the connection alive are originating from the Android phone so it appears to be a problem on the Android side. We now ensure disconnection from nRF side if this happens.