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

Failed to disconnect from iOS device after several times

Hello. I am developing a project on nRF52832 using SDK 13, in which I need to transfer up to 300 bytes of data from iOS device via my dedicated app (in the background) to nRF in 10 second cycles. Project is based on ble_peripheral_uart example, so I am writing data into one characteristic.

Because data transfer lasts less than a second, it would be energy efficient to disconnect as soon as all data is sent, but here came the problems. Even if I disconnect from my iOS app, because of the system policy the connection still lasts about 7-10 seconds (known iOS issue).

So, I tried to send special "disconnect packet" to my peripheral, so as soon as it receive packet beginning with "11" it run:

err_code = sd_ble_gap_disconnect(m_conn_handle, BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);

And the disconnection in iOS occurs immediately. However, the cycle seem to work only a few times. Sometimes 2, sometimes 13 - no rules. Then it returns 0x08 error code, and nRF will not start advertising again (BLE_GAP_EVT_DISCONNECTED is not received, but my iPhone shows it's disconnected). I also tried starting additional 1.5s timer on BLE_GAP_EVT_CONNECTED and executing disconnection in timer handler, but the result is the same.

Is there any way to ensure continuous work of my device?

  • Interesting, I use exactly same procedure (sd_ble_gap_disconnect to invoke LL_TERMINATE packet over the radio) to bypass this iOS limitation and I've never encountered any issue. Do you have RF trace from some sniffer to understand better what is happening? E.g. are you sure that always m_conn_handle is valid (= link was not already disconnected) and that err_code is NRF_SUCCESS? Because 0x08 means /* @retval ::NRF_ERROR_INVALID_STATE Invalid state to perform operation (disconnection is already in progress). */

  • I started development with SEGGER Embedded Studio, where I manually set SRAM_START=0x20002600 for testing and device is working flawless for last 12 hours. In Keil I had 0x20002168 which I guess was not enough after expanding the UART Example.

Related