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

  • 0 in reply to user3586

    Hi Dani, 

    It's the same issue as earlier, LL_PING_RSP sent without a LL_PING_REQ before that. 
    I have checked internally and found other reports about this issue dated back to 2019. It usually happens with Qualcomm Bluetooth/Wifi chip . I don't know which exact version of your Tab A is but you can check. 

    We don't really have a workaround for that as it's the issue of the Central device. However, there were a workaround for another issue related to this I think it worth to try. Could you try to add the following code to your ble_evt_handler in main.c ? 

                opt.gap_opt.auth_payload_timeout.conn_handle= m_conn_handle;
            opt.gap_opt.auth_payload_timeout.auth_payload_timeout= 3000;
            err_code = sd_ble_opt_set(BLE_GAP_OPT_AUTH_PAYLOAD_TIMEOUT, &opt);
            APP_ERROR_CHECK(err_code);

  • 0 in reply to Hung Bui

    Hi Hung,

    Already implemented and tested without success.

    I have proceeded in the same way as before with the TabA (Galaxy Tab A 2016, SM-T580):

    • Desinchrnozed Peripheral from TabA
    • Bonding and Connection with Peripheral: it connects perfectly
    • Manual Disconnection
    • Connection again with the already bonded peripheral: impossible to connect again

    Please, find attached the trace.

    Furthermore, in the code you have just sent to me, you call 'pm_conn_secure'. I do not use this call in my code. Is it required? (I think I already sent my implementation to you)

    Regards,

    Dani.

  • 0 in reply to user3586

    Hi Daniel, 

    No pm_conn_secure() is not needed. It's used when the peripheral want to trigger bonding process. Usually the peripheral should let the central start the bonding process. 

    If you test by turn off and on bluetooth on the TabA, would you be able to use the TabA to connect ? 

    I think it's an issue with the TabA and not has anything to do with our chip/stack. 

  • 0 in reply to Hung Bui

    Hi Hung,

    I had already tested this: no way, I have tested it again by switching off bluetooth and even reseting the TabA.

    I would assume this is related with this tablet model.

    The most important thing is the problem I had with Xiaomi Mi8 and other models, that now seems to be solved --> definetely it seems related with slave latency!!! Does it has sens?? Now, I will need to check the same with other models (Huawey P20 Pro, Oppo A74,...) and be sure this problem is not happening again.

    Dani.

  • 0 in reply to user3586

    Hi Hung,

    An other question: up to now, I'm working with SEC_PARAM_LESC=1 (except when connecting the sniffer). In production mode, what do you recommend? SEC_PARAM_LESC to 0 or to 1? Which is the main difference?

    Dani 

Related
Terms of service