disconnecting while operations are in progress never gives BLE_GAP_EVT_DISCONNECTED event

[Paul Bradford]

2020-01-24-092119EST-ProductStoppedGettingEventsFromNordicDK.txtImprivataTestNordicEventsNotReceived.zipCalls_to_pc_ble_driver.cpp0285.2020-02-24-TestProgramUploadedToNordicSupport.zipFeb25TestProgramUploadedToNordicSupport.zipImprivata_bgTestApp.zipbgSDKTestAppMay4.zip2020-05-05-035347-NordicDK_USB840M_200505_ClockInternal_2in1.hex.txt.txtbgSDKTestAppMay6.zipI’m developing an application based on pc-ble-driver to talk to an nRF52840-based dongle (from Fanstel).

I’m having trouble disconnecting cleanly when a connection has operations in progress.  For example, I call ‘sd_ble_gattc_write’, which returns NRF_SUCCESS, but I don’t receive event BLE_GATTC_EVT_WRITE_RSP (after waiting 60 seconds), so I decide to disconnect. When this happens, sd_ble_gap_disconnect returns NRF_SUCCESS, but I do not receive BLE_GAP_EVT_DISCONNECTED even after waiting 30 seconds. The connection supervision timeout is 4 seconds.  What could cause the disconnect to not generate any BLE_GAP_EVT_DISCONNECTED event?

What I’m trying to accomplish here: if a connection is not responsive, I want to end that connection, without disturbing other connections I have open.

Thanks,

Paul Bradford

[Paul Bradford]

I’d like to try to keep this support case somewhat limited.  Although the trace I sent shows that the GATTC write did receive a response from the phone, and that the response apparently was not seen by the nRF52840 dongle on my PC, let’s leave that for a separate support case.  For this case, let’s deal with the problem that I never get the BLE_GATTC_EVT_WRITE_RSP or BLE_GAP_EVT_DISCONNECTED events.

 

In response to your questions:

1. I don't have a project I can send. I see this behavior in the product I'm working on, and extracting this into a standalone project is a very large amount of work.
2. I initiate a connection from a Windows 7 PC using pc-ble-driver-based code talking to a Fanstel USB840M dongle, which has the nRF52840 chipset. The device I'm talking to is an Android phone.   I have to talk to a wide variety of phones, so even if this non-response problem didn't appear with a different phone, it wouldn't help me.
3. The dongle remains responsive. For example, if I issue a reset with sd_rpc_conn_reset, the dongle does reset.
4. I'm using pc-ble-driver 4.1.1 with NRF_SD_BLE_API=6. The firmware is SoftDevice S140 with Connectivity firmware v4.1.1.  

 

Regarding your response to my questions:

1. Is the GATTC timeout hardcoded to 30 seconds, or is there some setting I can use to tweak it? Note from my original post that BLE_GATTC_EVT_WRITE_RSP doesn't appear even when I wait 60 seconds.
2. If the BLE_GAP_EVT_DISCONNECTED event should come after the supervision timeout at the latest, then there is some problem here, because the supervision timeout is 4 seconds but the BLE_GAP_EVT_DISCONNECTED event doesn't appear even after 30 seconds.

[Jørgen Holmefjord]

It is hard to give any good advice without being able to reproduce the issue. If it only happens in your application and with only a specific device, it is hard to reproduce and debug on our end. This is why I asked the questions.

1. 30 seconds are hardcoded and given by spec (see Vol 3, Part F. - 3.3.3 of Bluetooth Core v5.0 specifications). Just to be sure, you are not receiving the BLE_GATTC_EVT_TIMEOUT event either?
2. Do you have any debug capabilities on the dongle? It would help if you could be able to debug the connectivity firmware, to see if the events are reported from the softdevice or not. If they are reported from the softdevice, there must be some issue/bug causing the events to not being passed along to the pc-ble-driver application. I have never encountered a situation where these events are not delivered from the softdevice.

[Paul Bradford]

The 30-second timeout was in reference to sd_ble_gattc_write. My reference for how pc-ble-driver calls work is the header files, in this case pc-ble-driver\include\sd_api_v6\ble_gattc.h (is there any other documentation of pc-ble-driver calls that is more authoritative?)

That header does not show that sd_ble_gattc_write can emit event BLE_GATTC_EVT_TIMEOUT. Can it?  The sample programs that I start with only show two causes of emitting BLE_GATTC_EVT_TIMEOUT: a connection attempt, and when scanning stops (only if scanning was started with a time limit)

I don't have any debug capability on the dongle. I talked to the device vendor (Fanstel) and they also can't proceed without a test program that reproduces the problem.

[Jørgen Holmefjord]

I think you may be mixing the two events BLE_GAP_EVT_TIMEOUT and BLE_GATTC_EVT_TIMEOUT. GAP is most likely the event that is handled in your sample application and is valid for connection requests and scan timeouts (also advertising timeouts in peripheral applications).

I received confirmation from our softdevice team that the GATTC timeout can be generated in case of no response to sd_ble_gattc_write call.

I will convert this case to a private on request from David Martin. If you are able to reproduce the issue on the nRF52840 Dongle, we can help you to enable logging or debugging capabilities. I'm assuming you are using the USB transport for the connectivity firmware, which means that logging may need to be done over UART with a USB to UART bridge since the USB interface is "occupied" by serialization library. 

[Paul Bradford]

This is very helpful information. I was indeed mixing up BLE_GATTC_EVT_TIMEOUT and BLE_GAP_EVT_TIMEOUT when responding to your prior messages.  My code does not handle event BLE_GATTS_EVT_TIMEOUT, because the pc-ble-driver header files don't say that sd_ble_gattc_write can generate that event.    Is there some other documentation source I should be reading that would tell me that?

I will add a handler for BLE_GATTC_EVT_TIMEOUT.  If sd_ble_gattc_write does cause that event to be generated, that would solve half my problem.   The remaining problem is that sd_ble_gap_disconnect is not generating BLE_GAP_EVT_DISCONNECTED. There is no other event that might be generated instead, is there?