Intermittent BLE connection

RE: Intermittent BLE connection

adunk — Mon, 23 Sep 2024 14:42:25 GMT

We are no longer having the issue since changing our antenna layout.

RE: Intermittent BLE connection

Maria Gilje — Wed, 24 Jul 2024 13:11:30 GMT

Thank you for the update!

RE: Intermittent BLE connection

adunk — Tue, 23 Jul 2024 12:06:18 GMT

Hello Maria. We have recently discovered an antenna layout issue so its possible this is a legitimate failure to exchange data during the connection process. Once I am given a device with a corrected layout I will attempt to duplicate this failure and post the logs as requested or close the issue. Thanks!

RE: Intermittent BLE connection

Maria Gilje — Tue, 23 Jul 2024 12:00:15 GMT

Hello,

The connection fails with 0x3D (BTLE_CONN_TERMINATED_DUE_TO_MIC_FAILURE) which indicates incorrect encryption keys. Please do a new test with CONFIG_BT_LOG_SNIFFER_INFO=y and share the sniffer log for a successful and an unsuccessful connection.

Best regards,

Maria

RE: Intermittent BLE connection

Maria Gilje — Mon, 22 Jul 2024 15:11:18 GMT

I have caught up on the previous posts here and have found that I need to forward this issue internally. Thank you again for your patience, and I will update you again by Thursday.

RE: Intermittent BLE connection

Maria Gilje — Fri, 19 Jul 2024 15:39:29 GMT

Hello,

I am following up with this case while Hieu is away. Unfortunately I have not had the time to look into the issue this week due to the aforementioned high workload.

You'll hear from me again on Monday. Thank you for your patience.

Best regards,

Maria

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 19:08:56 GMT

Above is the log for turning on the HCI core debug logging.
Also, on the peripheral, that bt_conn_set_state occurs every time there is a disconnection. But on the Central it only occurs when there is a failure.

I was unable to set a breakpoint at that location on the peripheral. I think because its a delayed work queue. The breakpoint just advances to the next function.

My suspicion's regarding the connection handle was based on a previous post I had seen regarding not waiting for the disconnect callback before attempting another connection but I was unable to find that issue in my logs.

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 19:03:58 GMT

-- [00:08:27.978,240] <inf> ble_supv: Advertising to CB:80:08:52:DA:8D (random) started

-- [00:08:31.791,351] <dbg> bt_hci_core: bt_recv: buf 0x20023f5c len 33
-- [00:08:31.791,381] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
-- [00:08:31.791,381] <dbg> bt_hci_core: rx_work_handler: buf 0x20023f5c type 1 len 33
-- [00:08:31.791,381] <dbg> bt_hci_core: hci_event: event 0x3e
-- [00:08:31.791,412] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x0a
-- [00:08:31.791,534] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: status 0x00 handle 119                                                                                                 role 1 peer CB:80:08:52:DA:8D (random) peer RPA 00:00:00:00:00:00
-- [00:08:31.791,595] <dbg> bt_hci_core: bt_hci_le_enh_conn_complete: local RPA 00:00:00:00:0                                                                                                0:00
-- [00:08:31.791,595] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
-- [00:08:31.791,625] <dbg> bt_conn: bt_conn_unref: handle 0 ref 2 -> 1
-- [00:08:31.791,625] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
-- [00:08:31.791,656] <dbg> bt_conn: bt_conn_set_state: connecting-adv -> connected
-- [00:08:31.791,687] <dbg> bt_smp: bt_smp_accept: conn 0x20005778 handle 119
-- [00:08:31.791,687] <dbg> bt_smp: bt_smp_connected: chan 0x200066d4 cid 0x0006
-- [00:08:31.792,022] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x2016 param_len 2
-- [00:08:31.792,053] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200252e8
-- [00:08:31.792,053] <dbg> bt_hci_core: bt_hci_cmd_send_sync: buf 0x200252e8 opcode 0x2016 l                                                                                                en 5
-- [00:08:31.792,083] <dbg> bt_hci_core: process_events: count 2
-- [00:08:31.792,083] <dbg> bt_hci_core: process_events: ev->state 4
-- [00:08:31.792,114] <dbg> bt_hci_core: send_cmd: calling net_buf_get
-- [00:08:31.792,114] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
-- [00:08:31.792,114] <dbg> bt_hci_core: send_cmd: Sending command 0x2016 (buf 0x200252e8) to                                                                                                 driver
-- [00:08:31.792,114] <dbg> bt_hci_core: bt_send: buf 0x200252e8 len 5 type 0
-- [00:08:31.792,144] <dbg> bt_hci_core: process_events: ev->state 1
-- [00:08:31.792,175] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:08:31.792,175] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20005778 to poll list
-- [00:08:31.792,175] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:08:31.792,205] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
-- [00:08:31.792,236] <dbg> bt_hci_core: bt_recv: buf 0x20023f7c len 8
-- [00:08:31.792,327] <dbg> event: thread_status_event_supv: Conn evnt
-- [00:08:31.792,327] <inf> oob: Push:20
-- [00:08:31.792,419] <dbg> event: thread_status_event_supv: Bonds:Conn Evnt
-- [00:08:31.792,419] <dbg> event: thread_status_event_supv: No phy conn
-- [00:08:31.792,449] <inf> oob: MSG 20
-- [00:08:31.792,449] <inf> oob: OOB msgq during BLE
-- [00:08:31.792,572] <dbg> bt_hci_core: bt_recv: buf 0x200252e8 len 6
-- [00:08:31.792,572] <dbg> bt_hci_core: hci_cmd_status: opcode 0x2016
-- [00:08:31.792,572] <dbg> bt_hci_core: hci_cmd_done: opcode 0x2016 status 0x00 buf 0x200252                                                                                                e8
-- [00:08:31.792,602] <dbg> bt_hci_core: bt_hci_cmd_send_sync: rsp 0x200252e8 opcode 0x2016 l                                                                                                en 0
-- [00:08:31.792,633] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:31.792,633] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
-- [00:08:31.792,663] <dbg> bt_hci_core: rx_work_handler: buf 0x20023f7c type 1 len 8
-- [00:08:31.792,663] <dbg> bt_hci_core: hci_event: event 0x3e
-- [00:08:31.792,663] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x12
-- [00:08:31.792,694] <dbg> bt_adv: bt_hci_le_adv_set_terminated: status 0x00 adv_handle 0 co                                                                                                nn_handle 0x77 num 0
-- [00:08:31.792,694] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:31.792,694] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:31.842,376] <dbg> bt_hci_core: bt_recv: buf 0x200246cc len 11
-- [00:08:31.842,407] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
-- [00:08:31.842,407] <dbg> bt_hci_core: rx_work_handler: buf 0x200246cc type 3 len 11
-- [00:08:31.842,437] <dbg> bt_hci_core: hci_acl: buf 0x200246cc
-- [00:08:31.842,437] <dbg> bt_hci_core: hci_acl: handle 119 len 7 flags 2
-- [00:08:31.842,437] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:31.842,468] <dbg> bt_conn: tx_notify: conn 0x20005778
-- [00:08:31.842,468] <dbg> bt_conn: bt_conn_recv: handle 119 len 7 flags 02
-- [00:08:31.842,468] <dbg> bt_conn: bt_acl_recv: First, len 7 final 3
-- [00:08:31.842,468] <dbg> bt_conn: bt_acl_recv: Successfully parsed 7 byte L2CAP packet
-- [00:08:31.842,498] <dbg> bt_conn: bt_conn_send_cb: conn handle 119 buf len 7 cb 0x59169 us                                                                                                er_data 0x20014954
-- [00:08:31.842,529] <dbg> bt_conn: bt_conn_ref: handle 119 ref 2 -> 3
-- [00:08:31.842,529] <dbg> bt_conn: bt_conn_unref: handle 119 ref 3 -> 2
-- [00:08:31.842,529] <dbg> bt_hci_core: bt_hci_host_num_completed_packets: Reporting complet                                                                                                ed packet for handle 119
-- [00:08:31.842,559] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x0c35 param_len 5
-- [00:08:31.842,559] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200252e8
-- [00:08:31.842,559] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x0c35 len 8
-- [00:08:31.842,590] <dbg> bt_hci_core: bt_send: buf 0x200252e8 len 8 type 0
-- [00:08:31.842,620] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:31.842,651] <dbg> bt_hci_core: process_events: count 3
-- [00:08:31.842,651] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:31.842,651] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:31.842,651] <dbg> bt_hci_core: process_events: ev->state 4
-- [00:08:31.842,681] <dbg> bt_conn: bt_conn_process_tx: conn 0x20005778
-- [00:08:31.842,681] <dbg> bt_conn: send_buf: conn 0x20005778 buf 0x20025820 len 7
-- [00:08:31.842,681] <dbg> bt_conn: send_buf: send single
-- [00:08:31.842,681] <dbg> bt_conn: do_send_frag: conn 0x20005778 buf 0x20025820 len 7 flags                                                                                                 0x02
-- [00:08:31.842,712] <dbg> bt_hci_core: bt_send: buf 0x20025820 len 11 type 2
-- [00:08:31.842,742] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:08:31.842,742] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20005778 to poll list
-- [00:08:31.842,773] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:08:31.842,773] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
-- [00:08:31.992,156] <dbg> bt_hci_core: bt_recv: buf 0x200248a8 len 7
-- [00:08:31.992,156] <dbg> bt_hci_core: hci_num_completed_packets: num_handles 1
-- [00:08:31.992,156] <dbg> bt_hci_core: hci_num_completed_packets: handle 119 count 1
-- [00:08:31.992,187] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:31.992,218] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:31.992,218] <dbg> bt_conn: tx_complete_work: conn 0x20005778
-- [00:08:31.992,248] <dbg> bt_conn: tx_notify: conn 0x20005778
-- [00:08:31.992,248] <dbg> bt_conn: tx_notify: tx 0x20014588 cb 0x59169 user_data 0x20014954
-- [00:08:31.992,584] <dbg> bt_hci_core: bt_recv: buf 0x20023f7c len 15
-- [00:08:31.992,614] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
-- [00:08:31.992,614] <dbg> bt_hci_core: rx_work_handler: buf 0x20023f7c type 1 len 15
-- [00:08:31.992,645] <dbg> bt_hci_core: hci_event: event 0x3e
-- [00:08:31.992,645] <dbg> bt_hci_core: hci_le_meta_event: subevent 0x05
-- [00:08:31.992,645] <dbg> bt_hci_core: le_ltk_request: handle 119
-- [00:08:31.992,675] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:31.992,675] <dbg> bt_hci_core: bt_hci_cmd_create: opcode 0x201a param_len 18
-- [00:08:31.992,675] <dbg> bt_hci_core: bt_hci_cmd_create: buf 0x200252e8
-- [00:08:31.992,706] <dbg> bt_hci_core: bt_hci_cmd_send: opcode 0x201a len 21
-- [00:08:31.992,706] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:31.992,736] <dbg> bt_hci_core: process_events: count 3
-- [00:08:31.992,736] <dbg> bt_hci_core: process_events: ev->state 4
-- [00:08:31.992,767] <dbg> bt_hci_core: send_cmd: calling net_buf_get
-- [00:08:31.992,767] <dbg> bt_hci_core: send_cmd: calling sem_take_wait
-- [00:08:31.992,767] <dbg> bt_hci_core: send_cmd: Sending command 0x201a (buf 0x200252e8) to                                                                                                 driver
-- [00:08:31.992,797] <dbg> bt_hci_core: bt_send: buf 0x200252e8 len 21 type 0
-- [00:08:31.992,797] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:31.992,828] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:31.992,828] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:08:31.992,828] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20005778 to poll list
-- [00:08:31.992,858] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:08:31.992,858] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 3 events
-- [00:08:31.993,438] <dbg> bt_hci_core: bt_recv: buf 0x200252e8 len 8
-- [00:08:31.993,438] <dbg> bt_hci_core: hci_cmd_complete: opcode 0x201a
-- [00:08:31.993,438] <dbg> bt_hci_core: hci_cmd_done: opcode 0x201a status 0x00 buf 0x200252                                                                                                e8
-- [00:08:32.192,291] <dbg> bt_hci_core: bt_recv: buf 0x20023f7c len 6
-- [00:08:32.192,291] <dbg> bt_hci_core: hci_disconn_complete_prio: status 0x00 handle 119 re                                                                                                ason 0x3d
-- [00:08:32.192,291] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:32.192,321] <dbg> bt_conn: bt_conn_set_state: connected -> disconnect-complete
-- [00:08:32.192,321] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:32.192,352] <dbg> bt_hci_core: rx_work_handler: Getting net_buf from queue
-- [00:08:32.192,352] <dbg> bt_hci_core: rx_work_handler: buf 0x20023f7c type 1 len 6
-- [00:08:32.192,382] <dbg> bt_hci_core: hci_event: event 0x05
-- [00:08:32.192,382] <dbg> bt_hci_core: hci_disconn_complete: status 0x00 handle 119 reason                                                                                                 0x3d
-- [00:08:32.192,382] <dbg> bt_conn: bt_conn_ref: handle 119 ref 1 -> 2
-- [00:08:32.192,413] <dbg> bt_conn: bt_conn_set_state: disconnect-complete -> disconnected
-- [00:08:32.192,413] <dbg> bt_conn: tx_notify: conn 0x20005778
-- [00:08:32.192,443] <dbg> bt_conn: bt_conn_unref: handle 119 ref 2 -> 1
-- [00:08:32.192,474] <dbg> bt_hci_core: process_events: count 3
-- [00:08:32.192,474] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:32.192,474] <dbg> bt_hci_core: process_events: ev->state 1
-- [00:08:32.192,474] <dbg> bt_hci_core: process_events: ev->state 0
-- [00:08:32.192,504] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:08:32.192,535] <dbg> bt_hci_core: hci_tx_thread: Calling k_poll with 2 events
-- [00:08:32.192,565] <dbg> bt_conn: deferred_work: conn 0x20005778
-- [00:08:32.192,565] <dbg> bt_smp: bt_smp_disconnected: chan 0x200066d4 cid 0x0006
-- [00:08:32.192,565] <dbg> bt_smp: smp_pairing_complete: got status 0x8
-- [00:08:32.192,596] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x200066d4 conn 0x20005778 ha                                                                                                ndle 119 encrypt 0x00 hci status 0x1f
-- [00:08:32.192,596] <wrn> ble_supv: Security failed: level 1 err 9
-- [00:08:32.192,596] <wrn> ble_supv: Failed to disconnect -128

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 17:39:21 GMT

Regarding the v2.7.0 change, I don't know what exactly is going on in the BLE stack during the connection procedure, but I was speculating if the Central tried to connect a 2nd time to the Peripheral in the middle of the connection process, it could cause a disconnection from the 1st attempt or possibly a failed 2nd connection attempt because its now already connected. I think this would be a question for someone more familiar with whoever addressed this "issue" that was resolved in 2.7.0. Etc-were other people seeing similar issues that I'm seeing?

I will follow up with the responses to the remainder of your questions.

RE: Intermittent BLE connection

Hieu — Mon, 15 Jul 2024 17:32:11 GMT

Could you please share how the v2.7.0 change item could result in the issue? I don't quite follow.

One thing stands out in the Peripheral log to me:

<dbg> bt_conn: bt_conn_set_state: connected -> disconnect-complete

This is odd because this log can only be produced here: https://github.com/nrfconnect/sdk-zephyr/blob/v3.5.99-ncs1/subsys/bluetooth/host/conn.c#L800

Does this consistently appear before a failure?

Could you please set a breakpoint there and use debug mode to get the call stack leading up to that?

While doing that, could you please also enable CONFIG_BT_HCI_CORE_LOG_LEVEL_DBG?

Also, regarding the initial suspicion that the connection handle is somehow being reused and mixed up, do you see this being the case in the full log? The log so far is only for the attempt where the issue happens, so I don't see what the connection handle is before that.

Another thing is, if you want to upload large amount of log text, you might want to use the Insert > Code function:

Unfortunately, I am out of office tomorrow. Another engineer will follow-up with you. We are all facing abnormally high loading, so please excuse us if there is any delay in following up.

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 15:09:55 GMT

I noticed in the latest SDK release, an issue was fixed in the nRF5340. Is this a symptom of this issue? Is it trying to connect again during the connection process?

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 12:23:53 GMT

I was able to get a log file from the Central when the failure occurred as well.

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 12:03:36 GMT

As a reference, heres the log from a successful connection:

RE: Intermittent BLE connection

adunk — Mon, 15 Jul 2024 11:09:50 GMT

Yes, ble_supv is the module where I receive the BLE callbacks. I then push an event into the event_supv and perform the functionality.

I turned the debug logging on the peripheral on those 2 modules and duplicated the failure process. Here's the output from Wireshark during the failure:

Here's the debug output from the connection callback to a little after the disconnection occurs. You can see it restarting the advertising at the end of 9:06 and then reconnect at 9:11:
-- [00:09:06.095,275] <dbg> event: thread_status_event_supv: Bonds:Conn Evnt
-- [00:09:06.095,275] <dbg> event: thread_status_event_supv: No phy conn
-- [00:09:06.095,520] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.095,550] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.095,550] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.145,233] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.145,263] <dbg> bt_conn: tx_notify: conn 0x20004080
-- [00:09:06.145,263] <dbg> bt_conn: bt_conn_recv: handle 137 len 7 flags 02
-- [00:09:06.145,263] <dbg> bt_conn: bt_acl_recv: First, len 7 final 3
-- [00:09:06.145,263] <dbg> bt_conn: bt_acl_recv: Successfully parsed 7 byte L2CAP packet
-- [00:09:06.145,294] <dbg> bt_conn: bt_conn_send_cb: conn handle 137 buf len 7 cb 0x55d5d us er_data 0x20013314
-- [00:09:06.145,324] <dbg> bt_conn: bt_conn_ref: handle 137 ref 2 -> 3
-- [00:09:06.145,324] <dbg> bt_conn: bt_conn_unref: handle 137 ref 3 -> 2
-- [00:09:06.145,385] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.145,385] <dbg> bt_conn: bt_conn_process_tx: conn 0x20004080
-- [00:09:06.145,416] <dbg> bt_conn: send_buf: conn 0x20004080 buf 0x20024558 len 7
-- [00:09:06.145,416] <dbg> bt_conn: send_buf: send single
-- [00:09:06.145,416] <dbg> bt_conn: do_send_frag: conn 0x20004080 buf 0x20024558 len 7 flags 0x02
-- [00:09:06.145,446] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.145,477] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20004080 to poll list
-- [00:09:06.145,477] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:09:06.195,648] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.195,648] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.245,330] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.245,361] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.245,391] <dbg> bt_conn: tx_complete_work: conn 0x20004080
-- [00:09:06.245,391] <dbg> bt_conn: tx_notify: conn 0x20004080
-- [00:09:06.245,391] <dbg> bt_conn: tx_notify: tx 0x20012e8c cb 0x55d5d user_data 0x20013314
-- [00:09:06.295,593] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.295,623] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.295,684] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.295,684] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20004080 to poll list
-- [00:09:06.295,715] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:09:06.645,233] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.645,233] <dbg> bt_conn: bt_conn_set_state: connected -> disconnect-complete
-- [00:09:06.645,263] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.645,294] <dbg> bt_conn: bt_conn_ref: handle 137 ref 1 -> 2
-- [00:09:06.645,324] <dbg> bt_conn: bt_conn_set_state: disconnect-complete -> disconnected
-- [00:09:06.645,324] <dbg> bt_conn: tx_notify: conn 0x20004080
-- [00:09:06.645,324] <dbg> bt_conn: bt_conn_unref: handle 137 ref 2 -> 1
-- [00:09:06.645,385] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.645,416] <dbg> bt_conn: deferred_work: conn 0x20004080
-- [00:09:06.645,416] <dbg> bt_smp: bt_smp_disconnected: chan 0x20004fdc cid 0x0006
-- [00:09:06.645,446] <dbg> bt_smp: smp_pairing_complete: got status 0x8
-- [00:09:06.645,446] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x20004fdc conn 0x20004080 ha ndle 137 encrypt 0x00 hci status 0x1f
-- [00:09:06.645,477] <wrn> ble_supv: Security failed: level 1 err 9
-- [00:09:06.645,477] <wrn> ble_supv: Failed to disconnect -128
-- [00:09:06.645,660] <dbg> bt_conn: bt_conn_unref: handle 137 ref 1 -> 0
-- [00:09:06.645,721] <dbg> event: thread_status_event_supv: Disc Evnt
-- [00:09:06.702,270] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.702,606] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.702,972] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.703,369] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.703,704] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.704,101] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.704,406] <dbg> bt_conn: bt_conn_set_state: disconnected -> connecting-adv
-- [00:09:06.704,437] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
-- [00:09:06.704,498] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:06.704,925] <dbg> bt_conn: bt_conn_unref: handle 0 ref 2 -> 1
-- [00:09:06.705,017] <inf> ble_supv: Advertising to D0:1F:FC:25:40:22 (random) started
-- [00:09:11.997,802] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
-- [00:09:11.997,833] <dbg> bt_conn: bt_conn_unref: handle 0 ref 2 -> 1
-- [00:09:11.997,833] <dbg> bt_conn: bt_conn_ref: handle 0 ref 1 -> 2
-- [00:09:11.997,863] <dbg> bt_conn: bt_conn_set_state: connecting-adv -> connected
-- [00:09:11.997,894] <dbg> bt_smp: bt_smp_accept: conn 0x20004080 handle 146
-- [00:09:11.997,894] <dbg> bt_smp: bt_smp_connected: chan 0x20004fdc cid 0x0006
-- [00:09:11.998,443] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:11.998,474] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20004080 to poll list
-- [00:09:11.998,474] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:09:11.998,596] <dbg> event: thread_status_event_supv: Conn evnt
-- [00:09:11.998,596] <inf> oob: Push:20
-- [00:09:11.998,687] <dbg> event: thread_status_event_supv: Bonds:Conn Evnt
-- [00:09:11.998,687] <dbg> event: thread_status_event_supv: No phy conn
-- [00:09:11.998,931] <dbg> bt_conn: bt_conn_unref: handle 146 ref 2 -> 1
-- [00:09:11.998,962] <dbg> bt_conn: bt_conn_ref: handle 146 ref 1 -> 2
-- [00:09:11.998,962] <dbg> bt_conn: bt_conn_unref: handle 146 ref 2 -> 1
-- [00:09:12.199,035] <dbg> bt_conn: bt_conn_ref: handle 146 ref 1 -> 2
-- [00:09:12.199,096] <dbg> bt_conn: bt_conn_unref: handle 146 ref 2 -> 1
-- [00:09:12.199,127] <dbg> bt_conn: bt_conn_prepare_events:
-- [00:09:12.199,157] <dbg> bt_conn: conn_prepare_events: Adding conn 0x20004080 to poll list
-- [00:09:12.199,157] <dbg> bt_conn: conn_prepare_events: wait on host fifo
-- [00:09:12.498,992] <dbg> bt_conn: bt_conn_ref: handle 146 ref 1 -> 2
-- [00:09:12.498,992] <dbg> bt_smp: bt_smp_encrypt_change: chan 0x20004fdc conn 0x20004080 ha ndle 146 encrypt 0x01 hci status 0x00

I could also do the same for the Central. But its a little more challenging to get access to that debug UART. But I could if necessary to debug this issue.

As for the shutdown issue, we plan on fixing the shutdown procedure in the Central to wait for the disconnect callback so the peripheral doesn't need to timeout, but that doesn't seem to be the problem in this case because the peripheral is advertising and definitely not connected in this case. Unless of course its not recovering properly.

RE: Intermittent BLE connection

Hieu — Fri, 12 Jul 2024 20:02:10 GMT

Hi adunk,

[quote user=""]After connection is established and bonds are saved, the peripheral basically always advertises if bonds exist. The central device is turned on and off and scans when it turns on. I know this is a little different than traditionally, but the Basic Audio Profile forced which devices are the Central and the Peripheral.[/quote]

I am not familiar with what BAP requires here, but this sound pretty much the same as how a pair of Central and Peripheral would work since Bluetooth 4.x, no? Could I perhaps miss something here?

But if dwelling in the reasons of the setup is not directly related to the issue, we can skip this part.

[quote user=""]I am wondering about the procedure when the Central device is powered down and disconnects. I'm basically just calling the functions to stop streaming and disconnect and then powering down. The peripheral does seem to take a couple of seconds to recognize the disconnection and receive the "disconnect" callback.[/quote]

This sound like the Central powering down happen too quick that the call to disconnect didn't actually work on the Central yet. The Peripheral would then just keep waiting for Central packets that stop coming and eventually time out.

Since you already have a sniffer setup, can you check if that is the case? You could temporarily disable encryption just for this test too.

Also, how does this power cycle happen? Power cycle usually mean a physical power cut and restore. However, you mentioned the central ending the stream and disconnect, that sounds like software is involved.

[quote user=""]Is there still something hanging up in the peripheral device from the connection that is occuring due to my procedure for the disconnection?[/quote]

From what you have described here, that can seem to be the case, but there shouldn't be anything like that...

Let's also look at these logs:

[quote user=""]

-- [00:04:21.230,010] <dbg> event: thread_status_event_supv: Conn evnt
-- [00:04:21.580,444] <wrn> ble_supv: Security failed: level 1 err 9
-- [00:04:21.580,474] <wrn> ble_supv: Failed to disconnect -128
-- [00:04:21.580,718] <dbg> event: thread_status_event_supv: Disc Evnt
-- [00:04:21.640,258] <inf> ble_supv: Advertising to xx:xx:xx:xx:xx:xx (random) started

-- [00:04:25.829,498] <dbg> event: thread_status_event_supv: Conn evnt

[/quote]

I assume ble_supv is one of your code module, and the code is based on one of the sample code. In that case, "Failed to disconnect -128" comes from bt_conn_disconnect(), and error 128 means there wasn't a connection.

This is quite odd. The two modules of the Bluetooth stack involved here are SMP and CONN. Could you please enable these configs to get more logs?
CONFIG_BT_SMP_LOG_LEVEL_DBG
CONFIG_BT_CONN_LOG_LEVEL_DBG

There could be a significant increase in amount of log, so you might also need to configure more buffers for the log module. Please also make sure CONFIG_LOG_MODE_DEFERRED is enabled to minimize the impact of logging to the Bluetooth stack's operations.

[quote user=""]What should the procedure be to properly stop streaming and disconnect from a peripheral? Is it possible its somehow using the "conn" handle from the previous connection?[/quote]

It would be best to wait for a callback confirming the success of an operation before moving on to the next step.

[quote user=""]

The current BLE disconnection procedure when the central is shut down. There is a little more error checking, but basically if we're streaming, stop the streaming and then disconnect:

if (!bt_content_ctlr_media_state_playing()){

return 0; // we are already paused

}

bt_content_ctrl_stop(default_conn);

bt_conn_disconnect(default_conn, BT_HCI_ERR_REMOTE_USER_TERM_CONN);

Its also possible the disconnection procedure has nothing to do with this failure.

[/quote]

Right, so this looks like there is no wait for any procedures to complete at all. Still, in an ideal world, the peripheral should be robust enough that it isn't impacted by what the central does.

[quote user=""]I'm using whitelisting on the peripheral so it only connects to the bonded device. But I am just using regular advertising rather than directed advertising. I didn't see the need for directed advertising since we're using out of band pairing. [/quote]

Noted.

Hieu