nRF52840 random disconnection

RE: nRF52840 random disconnection

Hung Bui — Tue, 07 Jun 2022 10:17:22 GMT

Hi Dani,
It's good to hear. The sniffer trace really helped here :)

RE: nRF52840 random disconnection

Dani — Tue, 07 Jun 2022 07:54:00 GMT

Hi again,

Now, with PM_HANDLER_SEC_DELAY_MS set to 1000 all devices are working fine: even my Mi8 and the Galaxy Tab A.

So, it seems we have found the key!!!

Dani

RE: nRF52840 random disconnection

Hung Bui — Tue, 07 Jun 2022 07:24:48 GMT

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.

RE: nRF52840 random disconnection

Dani — Tue, 07 Jun 2022 06:38:35 GMT

Good morning Hung,

What's your opinion about last findings?

Best regards,

Dani

RE: nRF52840 random disconnection

Dani — Fri, 03 Jun 2022 14:16:50 GMT

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.

RE: nRF52840 random disconnection

Dani — Fri, 03 Jun 2022 13:17:17 GMT

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

RE: nRF52840 random disconnection

Hung Bui — Fri, 03 Jun 2022 12:29:13 GMT

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.

RE: nRF52840 random disconnection

Dani — Fri, 03 Jun 2022 07:59:40 GMT

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?devzone.nordicsemi.com/.../3_5F00_06_5F00_22_5F00_Android_5F00_Connection_5F00_Bonding_5F00_Connection_5F00_Mi8.pcapng

RE: nRF52840 random disconnection

Dani — Fri, 03 Jun 2022 07:50:26 GMT

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

RE: nRF52840 random disconnection

Dani — Thu, 02 Jun 2022 14:12:28 GMT

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.

RE: nRF52840 random disconnection

Hung Bui — Thu, 02 Jun 2022 13:43:19 GMT

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.

RE: nRF52840 random disconnection

Dani — Thu, 02 Jun 2022 09:07:37 GMT

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.devzone.nordicsemi.com/.../Android_5F00_Connection_5F00_Bonding_5F00_Connection_5F00_Galaxy_5F00_TabA_5F00_2_5F00_06_5F00_22.pcapng

RE: nRF52840 random disconnection

Hung Bui — Thu, 02 Jun 2022 07:58:48 GMT

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

RE: nRF52840 random disconnection

Dani — Wed, 01 Jun 2022 13:16:05 GMT

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.

Danidevzone.nordicsemi.com/.../Android_5F00_Connection_5F00_Bonding_5F00_Connection_5F00_Mi8.pcapng devzone.nordicsemi.com/.../Android_5F00_Connection_5F00_Bonding_5F00_Connection_5F00_Galaxy_5F00_TabA.pcapng

RE: nRF52840 random disconnection

Dani — Wed, 01 Jun 2022 10:55:45 GMT

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.

RE: nRF52840 random disconnection

Hung Bui — Wed, 01 Jun 2022 09:15:25 GMT

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)

RE: nRF52840 random disconnection

Dani — Tue, 31 May 2022 15:21:17 GMT

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

RE: nRF52840 random disconnection

Hung Bui — Tue, 31 May 2022 11:17:50 GMT

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.

RE: nRF52840 random disconnection

Dani — Tue, 31 May 2022 10:49:04 GMT

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

RE: nRF52840 random disconnection

Dani — Tue, 31 May 2022 09:20:38 GMT

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

RE: nRF52840 random disconnection

Hung Bui — Tue, 31 May 2022 07:48:03 GMT

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.

RE: nRF52840 random disconnection

Dani — Tue, 31 May 2022 07:34:16 GMT

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.

RE: nRF52840 random disconnection

Hung Bui — Tue, 31 May 2022 07:26:28 GMT

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 ?

RE: nRF52840 random disconnection

Dani — Mon, 30 May 2022 15:26:02 GMT

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.

Danidevzone.nordicsemi.com/.../Android_5F00_pairing_5F00_30_5F00_05_5F00_22-2.pcapng

RE: nRF52840 random disconnection

Hung Bui — Mon, 30 May 2022 14:55:43 GMT

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.

devzone.nordicsemi.com/.../6445.ble_5F00_app_5F00_gls.zip

devzone.nordicsemi.com/.../8182.SnifferTraceExplain.pcapng