BLE_HCI_CONNECTION_TIMEOUT with Linux Central

[federunco]

Hello,

I've flashed to my custom nRF52832 board the ble_app_hrs_pca10040_s132 example, it works fine with iOS and Android hosts but when I try to connect to my development host via bluetooth it disconnects almost instantaneously outputting BLE_HCI_CONNECTION_TIMEOUT. I've read in other threads that the RC low frequency clock could cause this problem, but with other hosts (even a Raspberry PI Zero 2 with linux running) is working fine. How can i address this issue?

SoftDevice version: S132 7.3.0
SoftDevice clock config:

#define NRF_SDH_CLOCK_LF_ACCURACY 1
#define NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 2
#define NRF_SDH_CLOCK_LF_RC_CTIV 16
#define NRF_SDH_CLOCK_LF_SRC 0

Debug window output:

<debug> nrf_sdh_ble: BLE event: 0x10.
<debug> nrf_ble_gatt: Requesting to update ATT MTU to 247 bytes on connection 0x0.
<debug> nrf_ble_gatt: Updating data length to 251 on connection 0x0.
<info> peer_manager_handler: Peer data updated in flash: peer_id: 1, data_id: Peer rank, action: Update, no change
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected, reason 8.

bluetoothctl output while pairing:

[bluetooth]# pair FD:81:ED:2A:E3:26 
Attempting to pair with FD:81:ED:2A:E3:26
[CHG] Device FD:81:ED:2A:E3:26 Connected: yes
[DEL] Device 77:CD:7D:D0:7B:85 77-CD-7D-D0-7B-85
Failed to pair: org.bluez.Error.ConnectionAttemptFailed
[CHG] Device FD:81:ED:2A:E3:26 Connected: no
[DEL] Device 4A:81:81:64:3D:7C 4A-81-81-64-3D-7C

[Vidar Berg]

Hello,

Clock drift could be a possible reason for why you are not able to establish the connection, but it's not very common.  I would recommend you start with capturing a sniffer trace of the failed connection attempt (nrf sniffer). That may provide us with some more hints.

Some follow up questions:

1. Is this on a PC, and does it have built-in Bluetooth?

2. What version of Bluez? Older or newer than the one running on the Pi?

3. Is it possible to plug in another BT USB stick on this system to see if the connection problems goes away with another controller?

Best regards,

Vidar

[federunco]

1. Yes, the PC has built-in BLE (Intel 8265 8087:0a2b)

2. Host PC ver: 5.60-0ubuntu2.2, Pi version: 5.55-3.1+rpt1

3. I've tried two different BLE sticks but the board is not even discovered with both external sticks.

I can have the packet capture tomorrow, as I don't have an nRF dongle on hand right now, I've captured with wireshark the bluetooth0 interface, I hope it could be useful

bt1.pcapng

[Vidar Berg]

Hi,

I'm surprised is not working with other BT dongles either. Do you have a 52 DK or similar you can test with to see if it results in the same connection problem?  Also, as a test, you may try with this clock configuration on your board:

NRF_SDH_CLOCK_LF_SRC 2

NRF_SDH_CLOCK_LF_RC_CTIV 0

NRF_SDH_CLOCK_LF_RC_TEMP_CTIV 0

NRF_SDH_CLOCK_LF_ACCURACY 1

This will select the more accurate synthesized clock source, and therefore provide more margin if the issue is indeed related to clock drift.

The HCI dump shows "Connection failed to be established".

[federunco]

I tried using the synth clock it's not working. 

Here's the full capture with nRF sniffer:bt2.pcapng

[Vidar Berg]

You need to select your peripheral device from the Device menu to make the sniffer track the connection (or connection attempt) (Sniffing a connection involving a single Peripheral). The sniffer will only listen on the adv. channels otherwise.

[federunco]

Here you go: bt3.pcapng

[Vidar Berg]

Thanks. The sniffer trace shows that your intel controller is not receiving or acknowledging the packet responses from your board, which is strange. Could you try to disable the MTU request on your peripheral to see if it makes any difference? You can do so by setting NRF_SDH_BLE_GATT_MAX_MTU_SIZE in sdk_config.h to '23'

[federunco]

It was already set to 23, I've tried setting it to another value but it doesn't work either

[Vidar Berg]

Is this setting applied in your ble_stack_init() function? The sniffer trace shows that it is requesting a 247 byte MTU.

[federunco]

I've made a mistake in the code, now it requests a 23 byte MTU but it doesn't work either:

Log output (first successful connection with my iPhone, second connection with dev host)

<info> app_timer: RTC: initialized.
<debug> nrf_sdh: State request: 0x00000000
<debug> nrf_sdh: Notify observer 0x000312FC => ready
<debug> nrf_sdh: State change: 0x00000000
<debug> nrf_sdh: State change: 0x00000001
<debug> nrf_sdh_ble: RAM starts at 0x20003328
<debug> nrf_sdh_ble: RAM start location can be adjusted to 0x20002250.
<debug> nrf_sdh_ble: RAM size for application can be adjusted to 0xDDB0.
<info> app: EyesDrive NOSIGHT-FW running
<info> app: Fast advertising.
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x21.
<debug> app: PHY update request.
<debug> nrf_sdh_ble: BLE event: 0x22.
<debug> nrf_sdh_ble: BLE event: 0x23.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested a data length of 251 bytes.
<debug> nrf_ble_gatt: Updating data length to 27 on connection 0x0.
<debug> nrf_sdh_ble: BLE event: 0x24.
<debug> nrf_ble_gatt: Data length updated to 27 on connection 0x0.
<debug> nrf_ble_gatt: max_rx_octets: 27
<debug> nrf_ble_gatt: max_tx_octets: 27
<debug> nrf_ble_gatt: max_rx_time: 2120
<debug> nrf_ble_gatt: max_tx_time: 2120
<debug> nrf_sdh_ble: BLE event: 0x55.
<debug> nrf_ble_gatt: Peer on connection 0x0 requested an ATT MTU of 293 bytes.
<debug> nrf_ble_gatt: Updating ATT MTU to 23 bytes (desired: 23) on connection 0x0.
<debug> nrf_sdh_ble: BLE event: 0x50.
<debug> nrf_sdh_ble: BLE event: 0x12.
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected, reason 19.
<debug> nrf_sdh_ble: BLE event: 0x10.
<info> app: Connected.
<debug> nrf_sdh_ble: BLE event: 0x11.
<info> app: Fast advertising.
<info> app: Disconnected, reason 8.

Here's the packet capture during both connections:  bt4.pcapng

[Vidar Berg]

It shows the same as before - the master does not acknowledge packets sent by your slave for no apparent reason. I'm not sure if this points to an issue with the Bluez host or the controller. Have you been able to interface with other BT devices on this PC? 

Edit:

federunco said:

I've tried two different BLE sticks but the board is not even discovered with both external sticks.

What chipset does these dongles have? Broadcam, intel,..?

Also, do you have a nordic DK you can test with in order to rule out any potential HW issues with your custom board?