Issue with 2 centrals and single peripheral

[prodey]

I am using the UART central, integrated with peer manager and UART peripheral application from the SDK 15.3 on our custom hardware.
I have 2 centrals running exactly same firmware and one peripheral device that sends periodic data. In our system, both centrals are powered on together. We want only one (any one) central to get paired with the peripheral so that the other central is available for other devices.
In my application, on the central, in the event BLE_GAP_EVT_ADV_REPORT, when I get a expected device name match in ble_advdata_search(), I stop scanning and on peripheral, when I get BLE_GAP_EVT_CONNECTED, I stop advertising. This is what we want according to the design. This works well most of the times.
However, sometimes, when the 2 centrals are powered on together, I get a device name match on both centrals. One of them gets paired and starts receiving the periodic data from peripheral through event BLE_NUS_C_EVT_NUS_TX_EVT. But the other central gets 'stuck'. Through debugging, I found that on this other central device, it gets a match on device name but after that, no BLE events are triggered (no calls to ble_nus_c_evt_handler or ble_evt_handler). This is probably because the peripheral has already established connection with the other central device and stopped advertising. I can bring this stuck central out of this condition only by either rebooting the peripheral device or by rebooting the central.
Please suggest on the best way to get the central out of this condition.

[Mttrinh]

Hi,

Sorry for the late response.

Do you get any error codes when the device is stuck?

If both get centrals are getting a match, the one central that doesn't establish a connection with the peripheral should get a timeout. After the supervision timeout has passed, you should get a BLE_GAP_EVT_DISCONNECTED event. What is your supervision timeout set to?

[prodey]

I do not get any error codes on the central device. I tried to probe all the timeout events and BLE_GAP_EVT_DISCONNECTED event through LED indicators on our hardware, but none of these are hit once the device gets a match. In this condition, if I restart the peripheral, the central gets out of this condition and periodically starts getting the BLE_NUS_C_EVT_NUS_TX_EVT event. It seems, when there is a device name match, the central waits forever till it receives BLE packets from the exact same peripheral device that caused the match without ever getting into a timeout.

My constant NRF_BLE_SCAN_SUPERVISION_TIMEOUT is set to 1000 which I guess is 10 sec timeout. I tried to change this value but it does not affect this behavior. Our periodic messages from peripheral are being sent at 10 ms.

I can handle this on the application side. I start a timer set for 1 sec on device name match and check for a global variable that increments in ble_nus_c_evt_handler(). If it has not incremented for 1 sec, I reset the device trough sd_nvic_SystemReset(). With that, the central starts normal scan again and is ready to pair with any other peripheral. 

However, I believe there is a better way to handle this than such frequent resets to the device.

Please suggest.

[prodey]

Just to clarify above reply : "In this condition, if I restart the peripheral, the central gets out of this condition and periodically starts getting the BLE_NUS_C_EVT_NUS_TX_EVT event". In this condition, the other central gets into a normal scanning mode.

[Mttrinh]

It is weird that it isn't timing out after some time. Which event do you get when you get a match? Is this event triggered NRF_BLE_SCAN_EVT_CONNECTED? 

Could you try changing this value NRF_BLE_SCAN_SCAN_DURATION?