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]

The updated test program has some very encouraging results, but with one remaining mystery.   The important recent change (as requested), after a read/write request, it checks for BLE_GAP_EVT_DISCONNECTED in addition to BLE_GATTC_EVT_TIMEOUT and BLE_GATTC_EVT_READ_RSP/BLE_GATTC_EVT_WRITE_RSP. With this change, the GATTC_READ/WRITE problem is not reproducible. That’s great! That implies that since this support case was created (at which time I was checking only for BLE_GATTC_EVT_READ_RSP/BLE_GATTC_EVT_WRITE_RSP) that each failure was caused by receiving events BLE_GATTC_EVT_TIMEOUT or BLE_GAP_EVT_DISCONNECTED but not checking for them.   However, the one remaining mystery is that log I uploaded (2020-01-24-092119EST-ProductStoppedGettingEventsFromNordicDK) shows a SD_BLE_GATTC_READ and then none of those events afterward

 

The test program does often reproduce the problem "ERROR: never got BLE_GAP_EVT_CONNECTED or BLE_GAP_TIMEOUT_SRC_CONN after waiting 65000 milliseconds." For this issue, I want to make sure that after sd_ble_gap_connect returns NRF_SUCCESS, I should definitely get either BLE_GAP_EVT_CONNECTED  or BLE_GAP_EVT_TIMEOUT(with source BLE_GAP_TIMEOUT_SRC_CONN) – that there is no other event that I’m not checking that could signal the end of this operation.

[Paul Bradford]

Looks like the GATTC_WRITE problem is not gone after all. After about a day without the GATTC_WRITE error, I am seeing it multiple times over a short period of time "ERROR: never got BLE_GATTC_EVT_WRITE_RSP or BLE_GATTC_EVT_TIMEOUT or BLE_GAP_EVT_DISCONNECTED after waiting 65000 milliseconds." After that the test program tries to disconnect and fails "ERROR: never got BLE_GAP_EVT_DISCONNECTED after waiting 65000 milliseconds." I have the logging level set so I would see any disconnect event, and there was none.

[Jørgen Holmefjord]

Ok, that's too bad. Are you able to provide the logs for the run with the failing run on the latest application? I'm still not able to reproduce this.

I will try to look more into the missing CONNECTED event issue tomorrow, as this is simpler to reproduce.

[Paul Bradford]

I will work today on reproducing this with the Nordic DK with firmware logging enabled.

For the connection timeout issue, one thing that is very suspicious is that I have tracing to show if I ever receive BLE_GAP_EVT_TIMEOUT, and I don't think I've ever seen this, I would expect that over many hours of testing with thousands of connection attempts, I would see BLE_GAP_EVT_TIMEOUT fairly often, since connections don't always succeed.

[LeoChen]

Fanstel dongle doesn't mount 32K crystal.

The clock setting is internal RC.

Not sure if it makes any difference.

Attached the firmware that Paul is using.

USB840_Connect200120_3in1.hex