Hello everyone,
I am using an nrf52840 development board with the NUS UART Central example from the SDKv15.3.0 packet as the code basis. I am also using the s140 softdevice. I have a custom service which is exactly the same as the ble_nuc_c service but with custom uuids which connect to our specific peripheral. All of the handles for the custom service are the same as the nus service, including the tx_cccd handle and rx handle. For our task, after we have connected to the peripheral and enabled notifications, a data string is sent from the central to our peripheral, which then responds with it's own data string. When I first begin the debug, I am able to connect to the peripheral,enable notifications, send the data string and receive a notification with the response string. The problem seems to be that I can only do this with the first connection to the peripheral.
When the peripheral disconnects and reconnects I no longer receive notifications or data from the peripheral. I believe that I am still able to enable notifications after the reconnect since the tx cccd and rx handles are re-assigned correctly. The ble_nus_c_tx_notif_enable() also returns NRF_SUCCESS and triggers a BLE_GATTC_EVT_WRITE_RSP. But when I send the data string, I don't receive a notification for the response string as expected. The only way I am able to receive notifications again is by resetting the development board and restarting the debug.
Here are my questions:
1. Is there a way to know for sure that the notifications are being enabled in the peripheral after the reconnect? I have only seen answers for the nrf52840 board acting as a server, not as a client.
2. Is there a way to get the board back to a state that mimics its state before the first connection? My original solution was to use sd_nvic_SystemReset() after the peripheral disconnected since we could exchange data with the peripheral only when we connected to it for the first time. When the peripheral disconnected, the development board would be reset and if we tried reconnecting the peripheral, it was like it was connecting for the first time. Unfortunately, this solution doesn't work on our custom central boards since the sd_nvic_SystemReset() causes our custom board to crash.
3. Is there a proper way to handle the peripheral disconnecting? I assume that the NUS UART central already handles disconnect events properly but would like to be sure. The example does trigger the on_disconnect_evt() function which contains the link_init() function that is used to reset the connection parameters. However, since it seems I can only connect once to a peripheral and any subsequent connections don't work as expected, I am wondering if I might be missing additional steps that the example wasn't focused on and therefore didn't include.
