• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 100 replies
  • Subscribers 71 subscribers
  • Views 22757 views
  • Users 0 members are here
Attachments (20) Download All
Nordic Case Info
  • Case ID: 240418
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

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

  • 0

    I checked with our softdevice team, and they confirmed that the BLE_GAP_EVT_DISCONNECTED event should always be generated. If the peer device does not ack the LL_TERMINATE_IND, the event will be generated later, but it should still always be generated.

    If this is not the case in your application, I suspect that there is some issue with the event not being forwarded from the connectivity firmware to your pc-ble-driver application. We then need to debug the connectivity firmware to find out why this happens.

    I will be out-of-office until January 6., but I will make sure someone follows up on this issue if you are able to set up the application with our nRF52840 Dongle.

  • 0

    I'm getting back to this issue after a break.   I confirmed that BLE_GATTC_EVT_TIMEOUT is never received by my application, even though I wait 60 seconds. (If it happens, it should be after 30 seconds). Another bit of information: the exact same problem occurs with the nRF52840 dev-dongle (PCA10059) in addition to the Fanstel nRF52840.

  • 0

    Are you using a precompiled version of the connectivity firmware, or did you compile it yourself? It would be helpful if you can enable logging on the dongle, to see if the events are received from the softdevice.

    If you have compiled the connectivity firmware yourself, you can enable debug level logging by setting the following defines in the sdk_config.h file:

    #define NRF_LOG_BACKEND_RTT_ENABLED 1
#define NRF_LOG_ENABLED 1
#define NRF_LOG_DEFAULT_LEVEL 4

    With this set, you can connect a J-Link debugger to the SWD interface of the dongle, and read out the logs using J-Link RTT Viewer.

    It is also possible to enable logging over UART if you have a UART to USB cable. You then need to set the following defines:

    #define NRF_LOG_BACKEND_UART_ENABLED 1
#define NRF_LOG_BACKEND_UART_TX_PIN 31 // Or some other available GPIO on the dongle

    And connect the UART to USB cable to the UART_TX_PIN config.

    If you have not compiled the connectivity firmware yourself, I will try to create an example project that can be used for debugging. Please let me know.

  • 0

    I'm been concentrating on a standalone test program to reproduce these related problems: not receiving BLE_GATTC_EVT_WRITE_RSP then not receiving BLE_GAP_EVT_DISCONNECTED. I think I'm getting close to having a program I could share.

    After that I'll look at enabling debug logging. So far I've been using precompiled connectivity firmware. I will have to go through a learning curve to build my own firmware and hook up to the dev-dongle (and learn what the J-Link debugger is).

  • 0

    So far I have not reproduced the problem in my test program, but I'm learning more:
    1. Before the problem occurs, I receive expected events for the connection including BLE_GAP_EVT_RSSI_CHANGED and BLE_GAP_EVT_ADV_REPORT.
    2. The failure to receive events always occurs after I have received notifications for a characteristic. I enable notifications for a characteristic (by calling sd_ble_gattc_write), then receive 14 BLE_GATTC_EVT_HVX events, which is the number I'm expecting.
    3. Interspersed with those 14 events, I also receive other expected events, including BLE_GAP_EVT_RSSI_CHANGED.
    4. After the 14th event, I never receive another event for that connection, as shown by USB capture.
    5. I added a delay after getting the 14th event before doing another operation, so I can be sure the events stopped immediately after the 14 event. They did - no events were received (shown by USB capture) during that delay, or after.
    6. After that delay, I can sd_ble_gattc_read or sd_ble_gattc_write call and USB capture shows the command and (successful) response, but no other traffic, specifically no events, for over 30 seconds, or afterwards
    7. To summarize: after I finish receiving BLE_GATTC_EVT_HVX events, the nRF52840 ceases sending any events for the connection.

Related