nrf51822 ble UART Random disconnection

[Francois]

Hello all!

Sorry for what might seems an obvious question, my skills are what they are :-). We have a small circuit based on nrf51822 chip.

Our software is currently working fine but we are doing several tests to make sure some unprobable events will not have strong negative impact.

The goal of our circuit is to monitor 4 inputs and, if some conditions are met, save on an external memory and then send information over ble UART protocol.

to send data over ble UART, we use this function: ble_nus_buffer_send(Message, sizeof(Message))

In details:

U8 ble_nus_buffer_send(uint8_t * abuffer, uint32_t alength)
{

uint32_t sublength, err_code;

if(m_conn_handle == BLE_CONN_HANDLE_INVALID) return 0;

LED_Off();

while(alength)
{
if(alength > BLE_NUS_MAX_DATA_LEN)
  sublength = BLE_NUS_MAX_DATA_LEN;
else
  sublength = alength;

BtDataTxComplete = 0;
err_code = ble_nus_string_send(&m_nus, abuffer, sublength);

if(err_code != NRF_SUCCESS) return 0;
while(BtDataTxComplete == 0) {}; //nrf_delay_ms(1);
            
abuffer += sublength;
alength -= sublength;
}

LED_On();

return 1;
}

Some of you might recognize the nrf_UART code here.

What we have found is that, we we are sending many strings in a loop using this function and we randomly abruptly disconnect (by pressing disconnect button) from the receiver side (nrfUART android app. for ex.), the code stay stuck on the function (ble_nus_buffer_send) until next ble connection happens. During this time, the module is not doing what it is suppose to do (monitor IO and record events for example)

It's hard to look for similar issue in this forum so maybe some of you could help us make sure that when a brutal disconnection happens, the code don't wait for that function (exit the message transmission loop).

Thank you

Francois

[Stefan Birnir Sverrisson]

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.

[Francois]

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!