• State Verified Answer
  • Locked Locked
  • Replies 63 replies
  • Subscribers 25 subscribers
  • Views 1224 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

user3586

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 Dani, 
    Could you explain why you want to test with 2 central devices here ? 
    If you only test with one single central would the issue appear ? 

    The sniffer is not designed to store bond information for 2 different central. 

    I think it's the best to train you to use our sniffer and would know when the connection is decrypted properly by the sniffer or not. 
    I attached here the sniffer trace that I used my phone to test with the gls example. 
    It's the stock example from SDK v17.1 the only modification I made was to change 

    #define SEC_PARAM_LESC                  0 

    So what it does is Legacy pairing with passkey. 

    Next I use my phone to connect and pair, I have to enter the passkey printed on UART (please test using a DK) to the sniffer and the phone. 

    After that I can see the initial bonding happen in the sniffer and can see all packets (check the time and packet number): 

    Then I disconnect then connect again:

     

    You can see that after the START_ENC_RSP I don't have the "encrypted packet decrypted incorrectly". This means the reconnection and re-encrypt can be decrypted by the sniffer. 

    Before testing please make sure you unplug and plug the dongle and reset wireshark before testing. 

    Also you may want to use this filter: !(btle.data_header.length == 0) to filter out empty packets. 

    Please test using only one single central. 

  • 0 in reply to Hung Bui

    Hi again,

    As I told you, the problem with Xiaomi Mi8 seems to appear when I connect to it (bonding already done) after having been connected to an other device: now, I have bonded to Mi8 and I have connected and disconnected (manually) so many times, and it has been impossible to get disconnected after 30".

    But then, I have done the same test with the Galaxy Tab A tablet: first time (when bonding) there are no problems with connection. But when trying to connect a second time, GATT_CONN_TIMEOUT is received in the nRF tool log --> Please, find attached this trace.

    Regards.

    Dani

  • 0 in reply to user3586

    HI again,

    I have reproduced again the disconnection with the Xiaomi Mi8. I have the code in the same way it was last specified: with SLAVE_LATENCY set to 15. But I have set (for sniffer purposes) SEC_PARAM_LESC=0.

    I have proceeded in the same way: equipment desinchronized from my central (Xiaomi Mi8), and then (with Wireshark ready) I have bonded peripheral to my Xiaomi, and I have manually disconnected it several times unless last time: in this last time, it has been disconnected alone after about 30".

    Please, find attached this trace. Please, let me know any finding.

    Furthermore, in what regards BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST event, which is the right implementation. Could it affect in this behavior?

  • 0 in reply to user3586

    Hi Daniel, 
    This might be the missing sniffer trace that we have been looking for. 

    There are a few potential issue that I can find here: 

    1. I can see a security request was sent right after the connection has been established. Did you call pm_conn_secure() inside BLE_GAP_EVT_CONNECTED event ? 


    If you did please remove it. Also please check if you have PM_HANDLER_SEC_DELAY_MS set to something in sdk_config.h ? Please try set it to 1000 , by default it's 400ms. It's for interoperability as mentioned in the description. 

    2. I can see service changed indication that's sent by the slave:

    Did you change the attribute table ? And did you have something in your code to send the service changed indication ? 

    3. The central send a confirmation 30 seconds into the connection: 

    I'm not so sure what the confirmation for, for which indication, but it's most likely for the service changed indication. But it came too late and the softdevice disconnected due to BLE_GATTS_EVT_TIMEOUT . The slave terminate the connection right after that. 

    Please try to check the points I listed here and also try to capture another sniffer trace if it has the same pattern we may be able to pin point the problem. 

  • 0 in reply to Hung Bui

    Hi Hung,

    I really appreciate your support: it is very important for us...

    In what regards your questions: 

    1.- pm_conn_secure() is not called.

          PM_HANDLER_SEC_DELAY_MS is set to o --> I'll set it to 1000

    2.- I never use 'sd_ble_gatts_service_changed'. Using nRF tool, I have seen that the Generic Attribute with UUID 0x1801 is set as INDICATE. How can I change this? All my other services are sending notifications. Please, find a screenshot showing the Generic Attribute and my first service (all of them have same setup).

    Moreover, I'm using the DFU service defined as shown in the second screenshot. As far as I know, the NRF_SDH_BLE_SERVICE_CHANGED has to be set to 1 for the DFU to work, right?

    And what about BLE_GAP_EVT_DATA_LENGTH_UPDATE_REQUEST? Which is the suitable implementation?

    Dani

  • 0 in reply to user3586

    Hi Hung,

    Now, by having set PM_HANDLER_SEC_DELAY_MS to 1000, even the TAB A is working!!!!!!

    Please, let me know information I was asking in my previous answer.

    And what about SLAVE_LATENCY? Do you recommend to set it back to 0?

    Dani.

  • 0 in reply to user3586

    Good morning Hung,

    What's your opinion about last findings?

    Best regards,

    Dani

Reply Children
No Data
Related
Terms of service