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

nrf51822 ble UART Random disconnection

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

Parents
  • 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.

Reply
  • 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.

Children
No Data
Related