BLE_GATTC_EVT_TIMEOUT - Holding up Scan

[Mia]

I am trying to test out the whitelist that I have created for the nrf52832 client. I have edited the whitelist so it will only allow one device to be bonded and added to the whitelist. I also have a scanning filter added which filters based off the Nordic UART UUID. I have an android bonded with the Rigado and added to that one slot in the whitelist.

I programmed a second nrf52832 with the Nordic UART example for a peripheral device to see if that device will be able to be added to the whitelist since it would pass the scanning filter (has same UUID). I imagined not, and while I believe this is true from the testing I'm doing, after the device starts advertising (Android not advertising itself) for about 10 seconds, a BLE event occurs. The event is registered as a BLE_GATTC_EVT_TIMEOUT. I think I understand this as the connection attempt between the nrf52832 peripheral and client timed out, however, afterwards I start advertising on the smartphone, and no connection or even Bluetooth event occurs. Somewhere along the line, something is getting hung up after the connection timeout between the two nrf52832s, but when I run the debugger on the client, there is no error occurring. On the other hand, when I start advertising both devices from the start the smartphone will connect right away and continue on with normal business.

So long story, short, my questions are, what happens after a BLE connection attempt timeout? Should scanning continue or does it need to be restarted? if scanning is supposed to continue, why would things be getting hung up? Lastly, should there even be a BLE connection attempt if the device isn't in the whitelist?

Thanks!

[bjorn-spockeli]

Hi Mia, 

the BLE_GATTC_EVT_TIMEOUT is issued when a GATT procedure, i.e. writing or reading an Attribute times out, see GATTC Timeout.  Its not related to the connection timing out which will be signaled with a BLE_GAP_EVT_TIMEOUT event. Hence, you need to look at the peripheral you're communicating with as it is not responding to the ATT packet sent by your central. 

Yes, scanning must be restarted as it is stopped when you call sd_ble_gap_connect(), so you should restart scanning when you get the BLE_GAP_EVT_TIMEOUT event. 

If the whitelist is set up correctly then you should only get BLE_GAP_EVT_ADV_REPORT events from devices that are in the whitelist. Advertisment packets from Non- whitelisted devices are ignored at the Link layer.   

Best regards

Bjørn 

[Mia]

I'm sorry. I highlighted the wrong event to copy over. It is BLE_GAP_EVT_TIMEOUT that is issued.

I am not sure what I would be missing in my whitelist set up. I have my scanner set up as inactive, for reasons that I dont want the device sending scan requests to all devices. Would this have an effect possibly?

[bjorn-spockeli]

I cant think of any reason for not sending scan requests to devices should lead to the SoftDevice locking up. 
Could you capture a trace of the on air packets using the nRF Sniffer v2 ? It would make it easier to debug the issue. 

[Mia]

Let me see what I can do. My only issue is I would need a 3rd controller to build that sniffer as I am currently using the two that I have, one as the client and one to spoof the UUID.

Any suggestions on apps that can achieve the same goal?

[Mia]

I wanted to add that adding int he scan_start after the BLE_GAP_EVT_TIMEOUT event is seen solved my issue for allowing the phone connect again. However, I'm still not sure why the BLE_GAP_EVT_TIMEOUT event is happening in the first place.