Disconnection after 30s on reconnection with custom service on phone

[Paul K]

Setup:

- nRF52832 , Softdevice s132, gcc

- iPhone is the peripheral. A custom service is implemented **on** the iPhone.

On the nRF:

- `#define NRF_SDH_BLE_VS_UUID_COUNT 1`

- The custom service 128bits ID is registered on the softdevice via  `sd_ble_uuid_vs_add()`.

- It discovers the service with `ble_db_discovery_evt_register()`.

On the first connection (peer erased on device, device "forgotten" on iPhone), this appears to work.

On reconnection, after 30 seconds, the iOS bails with "Peer failed to respond to ATT value indication", and the device bails with a disconnection event error "0x13", which is BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION.

I am not using whitelisting.

If, instead of using my custom service, I use the iPhone's CTS or BAS service, it works well.

[Hung Bui]

Hi Paul, 

I would suggest to capture a sniffer trace so we know exactly what happened. Note that if the devices are paired, you need to use the sniffer to capture the initial pairing so that the sniffer can catch the keys. 

From what you described, it's most likely that the application didn't send the confirmation back to the phone. Are you planning to do notification or indication ? For notification you don't need to confirm the message when with indication you need to confirm that you receive the message. Please have a look here.

[Paul K]

Understood. To use the sniffer I need an extra devkit. I'll use the sniffer once I receive it.

The custom service only uses 2 characteristics (one read,write, one read). No notifications or indications.

But, I do use nrf_ble_gatts_c. Which uses indications. I get the NRF_BLE_GATTS_C_EVT_SRV_CHANGED indication. But I can't see how this could fail to properly reply to gatts indication _only_ when I use `ble_db_discovery_evt_register(my_custom_service_uuid)`.

[Paul K]

The issue had to do with the way I was storing the cached characteristics of my custom service with `pm_peer_data_remote_db_store`. I was storing the characteristic handle as a cccd_handle.

This is solved.