nRF52840 random disconnection

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. 

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

Hi Dani, 

Yes if you delete bond all the time then new pairing process will be performed. However, if the phone still have the bond information (no delete on the phone) then the phone will try to re-encrypt with previously stored key. In that case the peripheral will reject the re-encrypt request and disconnect.
So when you delete bond, it should be deleted on both sides. 

Have you managed to add logging to your application ? With that you can check if the delete bond is entered and if the check for 8 bonds is hit or not. 

You can consider not calling that function and test. 

I also suspect that there could be a chance that the new bond actually overwriting the previous bond. But this should be handled properly with the peer manager library unless there is some modification of the module. 

Hi Hung,

I have logged bond info, and in my current device now is set to 3.

As you suggested, it seems as bond info was somehow corrupted (it should not): once I connect to a second central, when coming back to first central, it disconnects after around 30"....

How can I avoid this? Any workaround?

Dani

More info....

It seems that connection with a central depends on the connection of the prveious connected central.

This is the test I have done:

• Considerations:
  • Central #1 bonded: Xiaomi Mi8
  • Central #2 bonded: Galaxy Tab A
  • Central #3 bonded: Galaxy A13
• Test procedure sequence:
  • Central #1 connects correctly to equipment and we force then disconnection
  • Central #2: trying to connect but it is not possible (only possible the first time when bonding)
  • Central #1: trying to connect --> impossible to connect, or disconnection after about 30"
  • Central #3: connects perfectly and we force then disconnection
  • Central #1: trying again to connect --> It connects perfectly
  • Central #2: trying to connect but it is not possible (only possible the first time when bonding)
  • Central #3: connects perfectly and we force then disconnection
  • Central #1: trying again to connect --> It connects perfectly but disconnects after 30"
  • Central #3: Always correct

Very strange. For me, it seems clear is something related with bonding information

Hi Daniel, 

If you run an SDK example on your device and doesn't have any issue with bonding (and reconnect) with multiple centrals then it must have something to do with your implementation. 

If you can flash your application on a DK and can reproduce the issue on the DK, then you can send us that application and we can test here. 

Hi Hung,

I have a DK but I'm using it as a sniffer: I have ordered a new one to make these tests.

Meanwhile, I'm doing some more testing and I have just found something important with my Xiaomi Mi 8.

Up to now, I was working with the following parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       0                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(4000, UNIT_10_MS) 

Now, I have set these parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       15                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(5000, UNIT_10_MS) 

Considering this last setting, my Xiaomi Mi8 does not disconnect after around 30": I have tested the different scenarios detailed above, and now it seems to be working perfectly. (Even, I have tested the scenario in which I was connecting my device with the Galaxy Tab and then with the Mi8, and now the Mi8 is also working). How could you explain this??

In what regards the Galaxy Tab, it continues doing the same: perfect connection the first time (when bonding) but impossible to connect next times (already bonded): GATT CONN TIMEOUT always received.

Could you explain such improvement with the Mi8? I'm now lost with this behavior...

Do you think any other setting using these parameters would make the Galaxy Tab A to work?

Regards,

Dani

Hi Hung,

I have a DK but I'm using it as a sniffer: I have ordered a new one to make these tests.

Meanwhile, I'm doing some more testing and I have just found something important with my Xiaomi Mi 8.

Up to now, I was working with the following parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       0                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(4000, UNIT_10_MS) 

Now, I have set these parameters:

#define MIN_CONN_INTERVAL                   MSEC_TO_UNITS(7.5, UNIT_1_25_MS)
#define MAX_CONN_INTERVAL                   MSEC_TO_UNITS(100, UNIT_1_25_MS)
#define SLAVE_LATENCY                       15                              
#define CONN_SUP_TIMEOUT                    MSEC_TO_UNITS(5000, UNIT_10_MS) 

Considering this last setting, my Xiaomi Mi8 does not disconnect after around 30": I have tested the different scenarios detailed above, and now it seems to be working perfectly. (Even, I have tested the scenario in which I was connecting my device with the Galaxy Tab and then with the Mi8, and now the Mi8 is also working). How could you explain this??

In what regards the Galaxy Tab, it continues doing the same: perfect connection the first time (when bonding) but impossible to connect next times (already bonded): GATT CONN TIMEOUT always received.

Could you explain such improvement with the Mi8? I'm now lost with this behavior...

Do you think any other setting using these parameters would make the Galaxy Tab A to work?

Regards,

Dani

Hi Dani, 

Your change is mainly about the Slave latency and it usually wouldn't affect the connection except for slower communication. 
Could you try to only change one setting at a time. In your case you change both the Slave Latency and the Conn supervision Timeout. 

As explained in the last response the GATT CONN TIMEOUT issue happened because the tablet was violating the spec. Do you experience the same issue when you test the tablet with other example ? 
Btw, the log where you captured GATT_CONN_TIMEOUT was a very good attempt of capturing sniffer trace when the connection is encrypted and re-encrypted. There were no "decrypted incorrectly" packet. 

If you can do the same with the Xiaomi Mi 8 we maybe able to figure out what's the problem. (If you are going to do it with multiple central, try to stop the sniffer before bonding with the second central, then start again when you return to test the first central)

Hi Hung,

Ok, I will save this trace.

Nevertheless, now, with these changes I have made, if I connect first to Mi8, then to tablet, and then back again to Mi8, Mi8 is always working fine, without any disconnection.

Dani.

Hi Hung,

I have taken the Mi8 (with LESC=0) and TabA (with LESC=0) and I have proceeded in the same way.

• First, with the Mi8:
  • Desinchrnozed Peripheral from Mi8
  • Bonding and Connection with Peripheral
  • Manual Disconnection
  • Connection again with the already bonded peripheral
  • Manual Disconnection

            In this case, everything is running OK (I have kept Slave_Latency to 15)

• Second, with the TabA:
  • 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

            In this case, connection is only running OK the first time, when bonding. The second time, it is impossible to connect.

Please, find attached sniffer traces in both cases.

Dani

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);

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.