• State Verified Answer
  • Locked Locked
  • Replies 63 replies
  • Subscribers 75 subscribers
  • Views 9885 views
  • Users 0 members are here
Attachments (14) Download All
Nordic Case Info
  • Case ID: 288957
Options
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

nRF52840 random disconnection

Dani

Good morning,

We have a new equipment based on the nRF52840 and s140.

                Just now, a new problem has appeared and it is very strange, as it seems to be a ‘random’ error:

 

                We have already assembled tens of equipment, and most of them are perfectly working with any smartphone (using both your ‘nRF Connect’ application or our own application).

                But, we have a few smartphones that show a strange behavior: they are able to perfectly connect to some of our nRF52840-based equipment, and in a few ones, they are able to connect but they get disconnected after a few seconds. Same equipment is connecting to other smartphones without problems (without disconnecting).

                This is (step by step) what it is happening a few times:

  • Equipment (nRF52840) is advertising.
  • Smartphone stablish connection with equipment using pin number
  • First time, the connection is perfectly working.
  • If smartphone is disconnected and connected back again with same equipment (Already bonded), then connection is stablished but smartphone disconnects after 30”, approximately. Same behavior is happening with both nRF connect application and our own application. Looking at log in nRF application we see: ‘Connection terminated by peer (status 19)’or ‘GATT_CONN_TIMEOUT’

 

Why is it happening?

Which is the reason?

How can we solve this?

 

 Could you help us? (For your information, we have set MIN_CONN_INTERVAL to 7.5m and MAX_CONN_INTERVAL to 100ms)

Thank you

Parents
  • 0

    Hi Daniel, 

    Having a delay before the slave request security is a good thing to do . So setting PM_HANDLER_SEC_DELAY_MS  to 1000 definitely something you should keep. 

    sd_ble_gatts_service_changed() is called inside gscm_local_database_has_changed(). That funciton, in turn, is called inside ble_dfu_buttonless_bootloader_start_prepare(). So you need to check if that function is called or not. Usually it's only used when the central trying to put the device to DFU mode. But this might be not the reason of the disconnection. I would suggest to try capture more sniffer traces if you still see the issue after changing the PM_HANDLER_SEC_DELAY_MS  to 1000ms. 

    BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST : shouldn't be the issue, at least from what I can see in the trace. 

    SLAVE_LATENCY: Shouldn't cause any issue, at least from what I can see in the trace. 

    Could you confirm now that after the PM_HANDLER_SEC_DELAY_MS   change everything works as it should ? If not please try to capture a new sniffer trace. 

Reply
  • 0

    Hi Daniel, 

    Having a delay before the slave request security is a good thing to do . So setting PM_HANDLER_SEC_DELAY_MS  to 1000 definitely something you should keep. 

    sd_ble_gatts_service_changed() is called inside gscm_local_database_has_changed(). That funciton, in turn, is called inside ble_dfu_buttonless_bootloader_start_prepare(). So you need to check if that function is called or not. Usually it's only used when the central trying to put the device to DFU mode. But this might be not the reason of the disconnection. I would suggest to try capture more sniffer traces if you still see the issue after changing the PM_HANDLER_SEC_DELAY_MS  to 1000ms. 

    BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST : shouldn't be the issue, at least from what I can see in the trace. 

    SLAVE_LATENCY: Shouldn't cause any issue, at least from what I can see in the trace. 

    Could you confirm now that after the PM_HANDLER_SEC_DELAY_MS   change everything works as it should ? If not please try to capture a new sniffer trace. 

Children
Related
Terms of service