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 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 Daniel, 

Regarding the issue with Galaxy Tab A. I think it's because of a violation from the master (Tab A) you can see here: 

The PING response was sent without a Ping request from the slave. The sniffer also notice this violation. By spec our stack will immediately disconnect result in the timeout you found. 
I don't know why the TAB A acted that way but it's a wrong implementation. I would assume this does happen on all devices ? 

Regarding the issue with Xiaomi , I think you may want to double check how the bond information is stored and if there is any chance that the delete_bonds function actually delete the bond of the previous central after a new central connected to it. 
Before your test please do a chip erase just to be sure all the bond information has been deleted. 

I assume that when you test using our example (gls for example) you don't have the same issue ? 

Good morning Hung,

If I delete bonds all the time (before a new central connect), then will I be requested to enter pin code all the times if a different central has connected?

Now, I'm using this 'delete_bonds' function:

static void delete_bonds(void)
{
    ret_code_t err_code;   
	
		if(pm_peer_count()>8)
		{
			pm_peer_id_t peer_id_to_delete;
			err_code = pm_peer_ranks_get(NULL,NULL,&peer_id_to_delete,NULL); //Older bond
			APP_ERROR_CHECK(err_code);
			err_code = pm_peer_delete(peer_id_to_delete);
			APP_ERROR_CHECK(err_code);
		}
}

And it is called in:

- At the beginning of main (After all initialization)

- At the 'BLE_GAP_EVT_DISCONNECTED' event

If number of bond is higher than 8, then bond information is deleted.

With examples, I have no problems.

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