If we try to force terminate an ogoing BLE connection by invoking sd_ble_gap_disconnect, we don't receive the SD_BLE_GAP_DISCONNECT event in some cases even after the supervision timeout.It is not easily reproducible and we have not been able to capture sniffer logs for the same. We did defensively added an application side timeout logic which fires up after 20 seconds to cleanup the connection context in such cases. One of the key step as part of connection cleanup is to restart the BLE advertisement in Connectable mode (as we change it to NonConnectable mode after first connection to prevent more than one concurrent connections). But this step (invoking sd_ble_gap_adv_start) fails with NRF_ERROR_CONN_COUNT in such cases. It seems like softdevice still hasn't cleaned up the connection context for first connection and it rejects advertising again in connectable to prevent more than one concurrent connections. I have following specific questions:
1. What can cause softdevice to completely miss raising SD_BLE_GAP_DISCONNECT event in some cases? Can we configure any additional timeout (otherthan supervision timeout) in softdevice to generate an explicit timeout event in such cases?
2. Is there a way to force softdevice to cleanup the connection context in case of such failures.
