Error when trying to update to 2M PHY with some dongles

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Thu, 18 Feb 2021 18:29:51 GMT

You have updated latest windows 10 build and drivers?

I could find these threads that seems to indicate that Bluetooth is problematic on the specific DELL model (Dell XPS 13 9350 laptop), there is some suggestions in the below threads of things you can try:
https://www.dell.com/community/Networking-Internet-Bluetooth/Bluetooth-not-working-on-new-XPS-13-9350-Windows-10/td-p/4760065/page/3

https://www.dell.com/community/Networking-Internet-Bluetooth/Windows-10-Bluetooth-Problem/td-p/4626667/page/3

Also, try to comment out pm_handler_secure_on_connection() and/or pm_conn_secure() if you have it in main.c to see if that make a difference.

One final comment: Try to set SEC_PARAM_LESC 0, in case the laptop can't handle this bit.

Kenneth

RE: Error when trying to update to 2M PHY with some dongles

Federico — Thu, 18 Feb 2021 16:31:45 GMT

I was using the default NRF_SDH_CLOCK_LF_ACCURACY, with a value of 7 which corresponds to NRF_CLOCK_LF_ACCURACY_20_PPM. I changed it to 1, that should be NRF_CLOCK_LF_ACCURACY_500_PPM.

I got the same result, the nRF aborts transmission anyway and I'm still getting the wrong CRC on the sniffer. At this point the only two clues to go on are the wrong CRC on the sniffer and the logged errors:

[00:00:39.677,825] <debug> nrf_ble_gatt: Peer on connection 0x2 requested an ATT MTU of 527 bytes.
[00:00:39.677,856] <debug> nrf_ble_gatt: Updating ATT MTU to 0 bytes (desired: 0) on connection 0x2.
[00:00:39.677,886] <error> nrf_ble_gatt: sd_ble_gatts_exchange_mtu_reply() returned NRF_ERROR_INVALID_PARAM.

But they might not be related at all

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Thu, 18 Feb 2021 15:24:40 GMT

What is the ppm tolerance you have set for the 32kHz lfclk when enable the BLE softdevice? Can you try to increase it (e.g. 500ppm for test)?

Kenneth

RE: Error when trying to update to 2M PHY with some dongles

Federico — Thu, 18 Feb 2021 15:10:40 GMT

That would log an error to the debug console right? It would also stop execution on the NRF_BREAKPOINT_COND at the end of app_error_fault_handler, or reset the nRF. I can't see any of these things happening, execution seems to resume normally. What other condition could cause the nRF to stop transmitting altogether?

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Thu, 18 Feb 2021 14:24:45 GMT

Quickly looking at the screenshot it looks like the peripheral just stop responding, are you sure you are not having an assert? Maybe check the app_error_fault_handler() for any error?

Kenneth

RE: Error when trying to update to 2M PHY with some dongles

Federico — Thu, 18 Feb 2021 14:13:17 GMT

I contacted the manufacturer, they are looking into it so I'll update when they get back to me. On the other hand, I've found another issue with a different laptop that bears some resemblance to this error, albeit without the incorrect answer issue. I posted it here: https://devzone.nordicsemi.com/f/nordic-q-a/71779/unable-to-pair-with-bluetooth-4-1-windows-10-laptop

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Sat, 13 Feb 2021 13:10:59 GMT

Hi,

If the problem consistently seems to be triggered by the LL_PHY_REQ, even when changing timing, then I agree that the peer seems to not follow spec no by replying with a correct LL_PHY_UPDATE_IND or LL_UNKNOWN_RSP.

Best regards,
Kenneth

RE: Error when trying to update to 2M PHY with some dongles

Federico — Thu, 11 Feb 2021 20:59:43 GMT

I tried adding a delay for the PHY update request and for the sd_ble_gattc_exchange_mtu_request, but I get the same result. I also tried adding a huge delay for the PHY update, like 2s, to make sure that it happens after the pairing has finished, but still the result is the same.

At this point I think it's not very useful to debug the dongle itself, maybe I could contact the manufacturer to report this.

Thank you very much for the help.

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Wed, 10 Feb 2021 16:44:33 GMT

It really does look like the central (master) in this case is misbehaving yes.

I know that the application by default for instance may call sd_ble_gattc_exchange_mtu_request() on BLE_GAP_EVT_CONNECTED event in on_connected_evt() in nrf_ble_gatt.c. It may be that the peer can’t handle this call if it’s called early in the connection, can you try to add a nrf_delay_ms(100); before calling sd_ble_gattc_exchange_mtu_request() in on_connected_evt() to see if that affect the issue? Something like:

static void on_connected_evt(nrf_ble_gatt_t * p_gatt, ble_evt_t const * p_ble_evt)
{
…
nrf_delay_ms(100); // #include "nrf_delay.h"

err_code = sd_ble_gattc_exchange_mtu_request(conn_handle, p_link->att_mtu_desired);
…
}

RE: Error when trying to update to 2M PHY with some dongles

Federico — Wed, 10 Feb 2021 15:27:19 GMT

I checked the link you sent, it shows the same thing I had found earlier. There seems to be no case where the Central should send an LL_PHY_RSP. It should either send LL_PHY_UPDATE_IND or LL_UNKNOWN_RSP (variants 3 and 4). Could this confirm the dongle is out of spec? This would explain the problem I guess.

Slave latency is set to 0 when calling sd_ble_gap_ppcp_set.

I'm attaching the first sniffer capture.

Again, thank you very much for the help

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Wed, 10 Feb 2021 14:18:22 GMT

You can find message sequence charts here that describe 7 variants of the PHY update:
https://infocenter.nordicsemi.com/topic/com.nordic.infocenter.s132.api.v7.2.0/group___b_l_e___g_a_p___p_e_r_i_p_h_e_r_a_l___p_h_y___u_p_d_a_t_e.html

I think you best look at these on what may occurring, if you still have issues I would need an nRF sniffer log and I may be of more help.

Have in mind that if you have slave latency enabled, then any packets will appear as retransmits from the central if the peripheral don't have any data to send during the slave latency period.

Kenneth

RE: Error when trying to update to 2M PHY with some dongles

Federico — Tue, 09 Feb 2021 20:55:35 GMT

Hi Kenneth,

Thank you very much for the advise and answer. I'm working with s132_nrf52_6.1.0_softdevice.

I can see that the identical packets are re-transmits now, that makes sense. However, I've traced all calls to sd_ble_gap_phy_update and this is the only one that is executing.

I tried the setup again and this time, it works a little differently (not sure what changed, I'm on a different PC but everything is the same). Now, the nRF never answers. I only get a bunch of LL_PHY_RSP after the first and only LL_PHY_REQ. All the LL_PHY_RSP have the same sequential number. After 10 seconds, the communication stops; it would appear that a timeout expires on the nRF because it never got the expected answer. However, if this was the case, I would expect retransmissions, as in the original post.

What event should the LL_PHY_RSP raise in the nRF? Is it possible I'm not answering and that's why it's retransmitting all the time?

The LL_PHY_RSP packets have an incorrect CRC flag in the sniffer, is this relevant? Could they be malformed packets, and that's why the nRF never answers?

This link shows a few communication diagrams, where it would appear that the Laird dongle is out of spec. When the Slave initiates the PHY change (6.31 - 6.33), the Master never answers LL_PHY_RSP, it can answer either LL_PHY_UPDATE_IND or LL_UNKNOWN_RSP. I have tested both these cases and they work fine: a BT5 laptop accepts and sends LL_PHY_UPDATE_IND to change to 2Mbps, a 4.0 dongle sends LL_UNKNOWN_RSP because it doesn't support PHY change. Could this be the issue?

Thank you very much for your time

Edit: all LL_PHY_RSP packets have the exact same (incorrect, according to wireshark) CRC. This would seem to discard an interference error, more like a systematic error on either the transmission or reception. Also, the LL_PHY_REQ that the nRF keeps sending are also retransmits (they have the same sequence number; the SN and ENSN seem to indicate that the nRF is not processing the LL_PHY_RSP)

This is the nRF log while this is happening:

[00:00:13.761,962] <debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x1.
[00:00:13.761,993] <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x1.
[00:00:13.762,207] <info> app: Connected.
[00:00:13.762,268] <info> app: Restarted advertising.
[00:00:14.014,770] <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x1.
[00:00:14.014,770] <debug> nrf_ble_gatt: max_rx_octets: 251
[00:00:14.014,801] <debug> nrf_ble_gatt: max_tx_octets: 251
[00:00:14.014,801] <debug> nrf_ble_gatt: max_rx_time: 2120
[00:00:14.014,801] <debug> nrf_ble_gatt: max_tx_time: 2120
[00:00:14.014,831] <debug> nrf_ble_gatt: Data length updated to 251 on connection 0x1.
[00:00:14.014,862] <debug> nrf_ble_gatt: max_rx_octets: 251
[00:00:14.014,862] <debug> nrf_ble_gatt: max_tx_octets: 251
[00:00:14.014,862] <debug> nrf_ble_gatt: max_rx_time: 2120
[00:00:14.014,892] <debug> nrf_ble_gatt: max_tx_time: 2120
[00:00:14.014,892] <info> app: Data length updated to 251 bytes.
[00:00:14.074,707] <debug> nrf_ble_gatt: Peer on connection 0x1 requested a data length of 251 bytes.
[00:00:14.074,737] <debug> nrf_ble_gatt: Updating data length to 0 on connection 0x1.
[00:00:14.074,768] <debug> nrf_ble_gatt: Peer on connection 0x1 requested a data length of 251 bytes.
[00:00:14.074,798] <debug> nrf_ble_gatt: Updating data length to 251 on connection 0x1.
[00:00:23.795,196] <info> app: Disconnected.
[00:00:23.795,227] <info> app: Restarted advertising.

RE: Error when trying to update to 2M PHY with some dongles

Kenneth — Tue, 02 Feb 2021 15:39:28 GMT

Hi,

I have found in general that initiating exchanges directly on connected event is not a good idea, I have seen many reports that some peers don't handle this very well. Likely they may have internal state machines that are not ready or can't handle the exchanges on first connection event. So if possible start an app_timer that may execute the exchange after for instance 100 ms or later. This doesn't really address your issue, but more of a fyi.

The 4 identical packets are simply retransmits, you can see the packet content and sequence numbers are not changed, so this means they are simply retransmits until the peer, in this case the nRF52, send anything in reverse direction to acknowledge the packet is received and the sequence numbers are incremented.

In this case it does indeed look as you have a back-and-forth PHY update requests, so I suggest that you search through your project to find all instances where the sd_ble_gap_phy_update() may be called, likely you have some module in your application that cause this to be called more than once.

What softdevice number and version are you using here?

Best regards,
Kenneth