Attachments (0)
Nordic Case Info
  • Case ID: 347622
Options

Getting instantly disconnected when trying to connect to BLE (0x3e with HCI)

GilDev

Hello,

I’m having an issue with my setup: I have a nRF9160 running the bt/peripheral sample through a nRF52840 (running the hci_lpuart sample). It seems to work fine with nRF SDK v2.7.0. However when embedded in my application, I have a somewhat erratic behavior with some showing this in the logs:

Fullscreen
1
2
3
[00:01:25.682,312] <inf> ble: Connected
[00:01:25.943,084] <wrn> bt_conn: conn 0x20017c98 failed to establish. RF noise?
[00:01:25.957,672] <inf> ble: Disconnected (reason 0x3e)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

I have compared the CONFIG_BT_* attributes in the .config of both the sample and my app and there is no difference at all. So far, it fails with a Pixel 9 running Android 16.

I have checked similar issues but nothing seems to help… It looks like it could be a parameter negociation issue, a clock issue, maybe the fact that the modem is enabled could also be an issue… I have tried changing multiple parameters, increasing the BT TX stack, nothing has helped. Here’s the log (debug level) with my application, and the log with the peripheral sample (running on the same hardware and nRF SDK version, with the same nRF52 hci_lpuart binary):
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
RAM usage & Logs
My app
uart> kernel threads
Scheduler: 596106 since last call
Threads:
0x20018a78 bt_rx_thread
options: 0x0, priority: -8 timeout: 0
state: pending, entry: 0x7079d
stack size 2200, unused 1616, usage 584 / 2200 (26 %)
0x20017a20 BT RX WQ
options: 0x0, priority: -8 timeout: 0
state: pending, entry: 0x8396d
stack size 2200, unused 1616, usage 584 / 2200 (26 %)
0x20017968 BT TX
options: 0x0, priority: -9 timeout: 0
state: pending, entry: 0x551d9
stack size 512, unused 72, usage 440 / 512 (85 %)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Peripheral
uart:~$ kernel threads
Scheduler: 17939 since last call
Threads:
0x200107b0 bt_rx_thread
options: 0x0, priority: -8 timeout: 0
state: pending, entry: 0x353b1
stack size 2200, unused 1672, usage 528 / 2200 (24 %)
0x2000fe88 BT RX WQ
options: 0x0, priority: -8 timeout: 0
state: pending, entry: 0x394e1
stack size 2200, unused 1656, usage 544 / 2200 (24 %)
0x2000fdd0 BT TX
options: 0x0, priority: -9 timeout: 0
state: pending, entry: 0x217d1
stack size 512, unused 112, usage 400 / 512 (78 %)
0x200106f8 conn_mgr_monitor
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Do you please have any idea on what could be happening? I have checked with the Nordic AI and in all the posts I could find. I have been successfully connected only ONCE with my Pixel 9 (using the nRF Connect app) but other than that it always fail. It seems to time out because there is no data communication between the phone and the device, making my smartphone disable its Bluetooth entirely for about 10 seconds before turning it on again, like something crashed and it just reset the Bluetooth.
Thanks!
  • 0

    After multiple days of digging, it seems that I found the issue.

    I had an orphaned `BT_DATA_BYTES(BT_DATA_UUID_ALL)` in my advertisement data, which looked like this:

    Fullscreen
    1
    2
    3
    4
    5
    static const struct bt_data ad[] = {
    BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    BT_DATA_BYTES(BT_DATA_UUID16_ALL),
    BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_CUSTOM_SERVICE_VAL),
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    That middle line should have been entirely removed when I adapter the zephyr/peripheral sample, which looks like this:

    Fullscreen
    1
    2
    3
    4
    5
    6
    7
    8
    static const struct bt_data ad[] = {
    BT_DATA_BYTES(BT_DATA_FLAGS, (BT_LE_AD_GENERAL | BT_LE_AD_NO_BREDR)),
    BT_DATA_BYTES(BT_DATA_UUID16_ALL,
    BT_UUID_16_ENCODE(BT_UUID_HRS_VAL),
    BT_UUID_16_ENCODE(BT_UUID_BAS_VAL),
    BT_UUID_16_ENCODE(BT_UUID_CTS_VAL)),
    BT_DATA_BYTES(BT_DATA_UUID128_ALL, BT_UUID_CUSTOM_SERVICE_VAL),
    };
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    I guess some smartphones use Bluetooth stacks that are more strict than others, which made the whole thing crash somehow. I wonder if Android could have given me some useful logs about this…

Terms of service