Can not connect paired Maya W1 and iOS iPhone Bluetooth LE

[Jan_Walter]

Hello,

i have problems using a MAYA-W166-00B based on NXP IW416 as a bluetooth LE GATT server.
Using an iPhone, i can only connect the first time, pair the devices and then use the GATT server, but if i try to connect a second time with both devices already paired, i get a timeout after 15 s. I have to unpair both devices and connect and pair them again to use the GATT server again.
Using an Android phone, i see no such problems.
One difference i have seen is that Android uses LE Channel Selection Algorithm #2 and iOS uses LE Channel Selection Algorithm #1, but i found no way to configure the LE Channel Selection Algorithm. So i do not know if that is the issue.

hciconfig shows no errors:
hci0: Type: Primary Bus: UART
BD Address: 6C:1D:EB:93:80:40 ACL MTU: 1021:7 SCO MTU: 120:6
UP RUNNING
RX bytes:6012 acl:61 sco:0 events:199 errors:0
TX bytes:4051 acl:68 sco:0 commands:107 errors:0

I am using an i.MX 6SoloX on a custom board running linux 5.4.84 with following bluetooth kernel config:
CONFIG_BT=y
CONFIG_BT_BREDR=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=y
CONFIG_BT_LE=y
CONFIG_BT_DEBUGFS=y
CONFIG_BT_HCIUART=y
CONFIG_BT_HCIUART_H4=y
https://github.com/nxp-imx/imx-firmware lf-6.1.55_2.2.0 and https://github.com/nxp-imx/mwifiex lf-6.1.55_2.2.0
bluez 5.55
I already tried linux 5.15.71, linux 6.1.55 with btnxpuart driver, bluez 5.72 and various versions of imx-firmware and mwifiex.

Using a usb dongle based on a rtl8761bu with following additional bluetooth kernel config and patches to add support for it in the btrtl driver works fine:
CONFIG_BT_INTEL=y
CONFIG_BT_RTL=y
CONFIG_BT_HCIBTUSB=y
CONFIG_BT_HCIBTUSB_RTL=y

Steps to reproduce:
See console outputs console1.txt and console2.txt

I captured the whole process using btmon
See capture file btmon.log.bin

Any advice on how to fix this?

[cdoumenc]

Checking internally

[cdoumenc]

Hi,

Since you are using ublox module MAYA-W1 series | u-blox, did you already check ublox support first (ublox documentation and online support) ?

Better to use the latest driver (GitHub - nxp-imx/mwifiex at lf-6.6.3-1.0.0) and firmware (GitHub - nxp-imx/imx-firmware at lf-6.6.3-1.0.0) : see UM11675 on product page https://www.nxp.com/products/wireless-connectivity/wi-fi-plus-bluetooth-plus-802-15-4/2-4-5-ghz-dual... if needed ("How to Download and Build NXP Wi-Fi Drivers - User manual (restricted)")
You can also check UM11490 from the same page ("Feature Configuration Guide for NXP-based Wireless Modules on i.MX 8M Quad EVK - User manual")

[cdoumenc]

especially chapter "4.7 Bluetooth LE device as GATT server"

[Jan_Walter]

Hi,

I just tried lf-6.6.3-1.0.0, but it behaves exactly the same.
I also tried using the battery service via bluetoothctl, as described in the user manual, but when I try to connect the iPhone a second time, I also get a timeout after 15 s.
I have to unpair both devices to connect again.

I am using an iPhone 11 Pro with iOS Version 17.1.1 and the "BLE Scanner 4.0" App Version 7.0 by Bluepixel Technologies LLP to test.

[cdoumenc]

Hi,

I am checking internally. On your side, do you have any feedback from ublox ?

[Jan_Walter]

Unfortunately, I have no feedback from ublox yet

[cdoumenc]

We have checked the shared logs, please find the below analysis for the same.

At HCI#151 we could see that the LE connection is established between iPhone and DUT with handle 0x0080.

At HCI#401 BR/EDR connection was established between DUT and iPhone with handle 0x0001.

At HCI#163 BT link got disconnected between DUT and remote.

At HCI#522 the LE data transfer is ongoing over the BLE link 0x0080.

At HCI#540 LE link was disconnected between DUT and remote.

At HCI#557 again LE connection was established between DUT and remote and the link got disconnected at HCI#562 after ~15 seconds.

Also, it doesn't look like the issue is related channel selection algorithm as we could see that the in first attempt at HCI#305 with the same channel parameter it got connected,

 

For further investigation, only HCI logs will not help, So can you please help to share the HCI and OTA sync logs to conclude on this?

Also please share the frequency of the issue.

[Jan_Walter]

By "HCI and OTA sync logs" do you mean HCI and OTA logs of the same procedure? Or HCI and OTA logs of just the pairing process?

Also is there a way to capture the OTA logs on the device or do I need external hardware?

The issue occurs every time.

[cdoumenc]

Yes, by "HCI and OTA sync logs", I mean HCI and OTA logs of the same procedure.

OTA logs are captured using Sniffer box + Sniffer Software. Below are few of the known sniffer software/HW

• Ellisys Bluetooth Explorer 400 ( BR/EDR/BLE sniffer) + Ellisys Bluetooth Analyzer SW
• Sodera Bluetooth protocol Analyzer + ComProbe Protocol Analysis System

[cdoumenc]

Do you know when you will be able to provide the logs ?

[Jan_Walter]

I captured an OTA log using a STM32WB Nucleo Board as a sniffer ( https://wiki.st.com/stm32mcu/wiki/Connectivity:STM32_Sniffer_for_BLE ) and btmon on the DUT at the same time.

I had to limit the advertising channels to 39 only, because the STM32 sniffer is a bit finicky.

[cdoumenc]

Working on it internally

[cdoumenc]

We have checked the shared logs and could not see the packet information for the OTA logs captured with STM. We have used the Wireshark Software to open the shared logs but it does not show any useful data as you can see in the attached screenshot. 

Here is our below observation from the HCI btsnoop logs: -

• This first time LE connection gets established properly at HCI#364 with BD Address: 5a:07:37:b5:6e:f2, and later LE Channel Selection Algorithm with #1 also received at HCI#366.
• This LE link was connected for almost 45 seconds without any trouble, which shows that the FW supports LE channel selection algorithm #1. Later on at HCI#717, the link was disconnected from a remote device.
• The second time the LE connection got established at HCI#724 with BD Address: 47:27:d4:2d:01:89 and later, the LE Channel Selection Algorithm with #1 was also received at HCI#726.
• At HCI#727 DUT Host has sent the LE Read Remote Features command which did not respond from the remote device.
• Here before the above gets served the link gets disconnected within 2 seconds with the remote user terminated connection.
• To understand what happened in this iteration we required the Sync HCI + OTA logs.

Unfortunately, without having the proper logs, we will not be able to progress on this issue. So, now, we will wait for you to share the proper HCI & OTA sync logs, so we can analyze it and debug the issue.

[Jan_Walter]

You have to install the ST LUA Plugins:

https://wiki.st.com/stm32mcu/wiki/Connectivity:STM32_Sniffer_for_BLE_Setup_guide#Installing_Wireshar... 

It should then look like this:

[Jan_Walter · Accepted solution]

We received PVT test FW via our distributor, who also contacted NXP regarding this issue. I do not see this issue anymore with the PVT test FW

[cdoumenc]

We managed to install ST LUA Plugins were able to see the logs.

We could observe that the HCI and OTA logs are synchronized,

In the failure instance, the LE connection was established at HCI#724 with BD Address: 47:27:d4:2d:01:89 and later, the LE Channel Selection Algorithm with #1 was also received at HCI#726. the same connection instance we could observe on OTA#2656 CONNECT_IND.

At HCI#727, the DUT Host sent the LE Read Remote Features command which did not respond from the remote device, because at OTA#2664 DUT initiated LL_LENGTH_REQ and at the same time at OTA#2665 remote device initiated LL_ENC_REQ, due to this collision scenario happened for these both requests from DUT and Remote, which leads to LL deadlock and disconnection was observed.

So, this log confirmed that this issue is exactly the same as the one the shared pvt FW was targeting.

[Jan_Walter]

We currently do not have a Bluetooth Sniffer on hand, but we are looking into getting one. I can not tell you how long that will take.