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

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

Parents
  • I have used the nRF52840 Development Kit and loaded firmware with logging enabled. I was able to run my product on this, and reproduced the problem (events not received after read/write/disconnect). I can attach the trace I viewed in RTT, but I don't know how.  For now I'll just summarize what I see. Early on, there are multiple reads that succeed, and the logging shows an SD_BLE_GATTC_READ, several lines about transmitting and receiving, then the "event:BLE_GATTC_EVT_READ_RSP". But when the problem occurs, these are the final lines of logging (no event received to confirm the read):

    00> <debug> ser_conn: [SD_CALL]:SD_BLE_GATTC_READ

    00> <info> ser_conn_dec: Command process start

    00> <info> ser_conn_dec: Tx buffer allocated

    00> <debug> sphy_hci: TX request (6 bytes)

    00> <debug> sphy_hci: Started TX packet (payload 6).

    00> <debug> sphy_hci: EVT:Tx packet sent.

    00> <debug> sphy_hci: EVT:RX ACK packet (length:4)

    I have several questions:

    Is the sample logging I've shown the level of detail that you expect from the firmware with debug logging enabled?

    It would be helpful if the J-Link RTT Viewer would show timestamps for each line. Possible?

    I don't see how to add an attachment to this case, can you let me know?

    I would prefer to make this case Public, is there any reason not to?

Reply
  • I have used the nRF52840 Development Kit and loaded firmware with logging enabled. I was able to run my product on this, and reproduced the problem (events not received after read/write/disconnect). I can attach the trace I viewed in RTT, but I don't know how.  For now I'll just summarize what I see. Early on, there are multiple reads that succeed, and the logging shows an SD_BLE_GATTC_READ, several lines about transmitting and receiving, then the "event:BLE_GATTC_EVT_READ_RSP". But when the problem occurs, these are the final lines of logging (no event received to confirm the read):

    00> <debug> ser_conn: [SD_CALL]:SD_BLE_GATTC_READ

    00> <info> ser_conn_dec: Command process start

    00> <info> ser_conn_dec: Tx buffer allocated

    00> <debug> sphy_hci: TX request (6 bytes)

    00> <debug> sphy_hci: Started TX packet (payload 6).

    00> <debug> sphy_hci: EVT:Tx packet sent.

    00> <debug> sphy_hci: EVT:RX ACK packet (length:4)

    I have several questions:

    Is the sample logging I've shown the level of detail that you expect from the firmware with debug logging enabled?

    It would be helpful if the J-Link RTT Viewer would show timestamps for each line. Possible?

    I don't see how to add an attachment to this case, can you let me know?

    I would prefer to make this case Public, is there any reason not to?

Children
No Data
Related