bluetooth/btstack: SCO connection not established (PicoW)

vladbalmos commented

2023-07-21 03:10:41 -05:00

(Migrated from github.com)

The hfp_hf_demo example from the btstack library stops working once a SCO connection needs to be established after codecs negotiation is successful.

SDK versions: 1.5.0, 1.5.1

Steps to reproduce

Set the correct device address of an HFP AG in device_addr_string in pico-examples/hfp_hf_demo.c
Enable bt packet logger: hci_dump_init(hci_dump_embedded_stdout_get_instance());
Enable bt logging: ENABLE_LOG_INFO, ENABLE_LOG_ERROR
Build the hfp_hf_demo example and flash a pico w board
Connect to the AG and initiate a call

Expected result
A SCO connection should have been established after codec negotiation

Actual result
After codec negotiation, no more packets/events are logged, no SCO connection is established, and no more commands can be sent to pico and the device gets disconnected from the AG. It seems the pico is still waiting for a response and stops processing any input (via the STDIN cli)

Tested HFP AGs: iphone se 2020, android (2019 motorola version)

btstack logs:

[codec negotiation happens]

00:00:14.918] LOG -- hfp_hf.c.1124: hfp: codec confirmed: mSBC
[00:00:14.925] LOG -- hfp.c.276: HFP_TX AT+BCS=2
[00:00:14.929] ACL => 0B 00 12 00 0E 00 4F 00 1B EF 12 00 41 54 2B 42 43 53 3D 32 0D 8F
[00:00:14.937] EVT <= 6E 00
[00:00:14.941] CMD => 35 0C 05 01 0B 00 01 00
[00:00:14.945] EVT <= 6E 00
[00:00:14.949] EVT <= 13 05 01 0B 00 02 00
[00:00:14.953] EVT <= 79 02 42 00
[00:00:14.956] EVT <= 89 02 01 00
[00:00:14.960] EVT <= 79 02 42 00
[00:00:14.965] EVT <= 1B 03 0B 00 01
[00:00:14.970] EVT <= 04 0A 6C 42 9B DF 80 38 00 00 00 02
[00:00:14.974] LOG -- hci.c.3539: Connection_incoming: 38:80:DF:9B:42:6C, type 2
[00:00:14.981] LOG -- hci.c.316: create_connection_for_addr 38:80:DF:9B:42:6C, type fc
[00:00:14.989] LOG -- hfp.c.895: accept sco 2
[00:00:14.994] LOG -- hfp.c.1989: HFP: sending hci_accept_connection_request, packet types 0x0048, sco_voice_setting 0x43
[00:00:15.005] CMD => 29 04 15 6C 42 9B DF 80 38 40 1F 00 00 40 1F 00 00 08 00 43 00 02 88 03
[00:00:15.014] EVT <= 6E 00
[00:00:15.017] ACL <= 0B 20 0F 00 0B 00 42 00 19 FF 0D 01 0D 0A 4F 4B 0D 0A 49
[00:00:15.023] LOG -- rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x01: 1, now 10
[00:00:15.031] LOG -- hfp.c.2144: HFP_HF_RX: '\r\nOK\r\n'
[00:00:15.036] LOG -- hfp.c.1394: command string 'OK', handsfree 1 -> cmd id 3
[00:00:15.043] CMD => 35 0C 05 01 0B 00 01 00
[00:00:15.048] EVT <= 6E 00
[00:00:15.051] EVT <= 0F 04 00 01 29 04

[no more events received]

The hfp_hf_demo example from the btstack library stops working once a SCO connection needs to be established after codecs negotiation is successful. SDK versions: 1.5.0, 1.5.1 **Steps to reproduce** 1. Set the correct device address of an HFP AG in `device_addr_string` in pico-examples/hfp_hf_demo.c 2. Enable bt packet logger: hci_dump_init(hci_dump_embedded_stdout_get_instance()); 3. Enable bt logging: ENABLE_LOG_INFO, ENABLE_LOG_ERROR 4. Build the **hfp_hf_demo** example and flash a pico w board 5. Connect to the AG and initiate a call **Expected result** A SCO connection should have been established after codec negotiation **Actual result** After codec negotiation, no more packets/events are logged, no SCO connection is established, and no more commands can be sent to pico and the device gets disconnected from the AG. It seems the pico is still waiting for a response and stops processing any input (via the STDIN cli) Tested HFP AGs: iphone se 2020, android (2019 motorola version) btstack logs: [codec negotiation happens] 00:00:14.918] LOG -- hfp_hf.c.1124: hfp: codec confirmed: mSBC [00:00:14.925] LOG -- hfp.c.276: HFP_TX AT+BCS=2 [00:00:14.929] ACL => 0B 00 12 00 0E 00 4F 00 1B EF 12 00 41 54 2B 42 43 53 3D 32 0D 8F [00:00:14.937] EVT <= 6E 00 [00:00:14.941] CMD => 35 0C 05 01 0B 00 01 00 [00:00:14.945] EVT <= 6E 00 [00:00:14.949] EVT <= 13 05 01 0B 00 02 00 [00:00:14.953] EVT <= 79 02 42 00 [00:00:14.956] EVT <= 89 02 01 00 [00:00:14.960] EVT <= 79 02 42 00 [00:00:14.965] EVT <= 1B 03 0B 00 01 [00:00:14.970] EVT <= 04 0A 6C 42 9B DF 80 38 00 00 00 02 [00:00:14.974] LOG -- hci.c.3539: Connection_incoming: 38:80:DF:9B:42:6C, type 2 [00:00:14.981] LOG -- hci.c.316: create_connection_for_addr 38:80:DF:9B:42:6C, type fc [00:00:14.989] LOG -- hfp.c.895: accept sco 2 [00:00:14.994] LOG -- hfp.c.1989: HFP: sending hci_accept_connection_request, packet types 0x0048, sco_voice_setting 0x43 [00:00:15.005] CMD => 29 04 15 6C 42 9B DF 80 38 40 1F 00 00 40 1F 00 00 08 00 43 00 02 88 03 [00:00:15.014] EVT <= 6E 00 [00:00:15.017] ACL <= 0B 20 0F 00 0B 00 42 00 19 FF 0D 01 0D 0A 4F 4B 0D 0A 49 [00:00:15.023] LOG -- rfcomm.c.1447: RFCOMM data UIH_PF, new credits channel 0x01: 1, now 10 [00:00:15.031] LOG -- hfp.c.2144: HFP_HF_RX: '\r\nOK\r\n' [00:00:15.036] LOG -- hfp.c.1394: command string 'OK', handsfree 1 -> cmd id 3 [00:00:15.043] CMD => 35 0C 05 01 0B 00 01 00 [00:00:15.048] EVT <= 6E 00 [00:00:15.051] EVT <= 0F 04 00 01 29 04 [no more events received]

👍 1

peterharperuk commented

2023-07-21 03:14:32 -05:00

(Migrated from github.com)

This is a known problem with the WiFi firmware. It should have been documented somewhere (probably not). We're hoping for a fix eventually

👍 3

wolfscowl commented

2024-02-05 13:32:53 -06:00

(Migrated from github.com)

Has the problem been fixed in the meantime or is there any solution for it?

peterharperuk commented

2024-02-05 13:43:55 -06:00

(Migrated from github.com)

No. Infineon are still working on it.

willnix commented

2025-04-30 05:27:46 -05:00

(Migrated from github.com)

Any news on this issue?
From what I understand the cyw43 needs to be configured to route Audio via SCO-HCI and one needs to use vendor specific commands to do so. Is this correct?

Any news on this issue? From what I understand the cyw43 needs to be configured to route Audio via SCO-HCI and one needs to use vendor specific commands to do so. Is this correct?

willnix commented

2025-04-30 08:06:21 -05:00

(Migrated from github.com)

If I'm not completely off base, this document describes the necessary HCI command(s) to configure SCO routing:

https://www.infineon.com/dgdl/Infineon-AN214937_Bluetooth_Audio_Over_I2S.pdf-ApplicationNotes-v02_00-EN.pdf?fileId=8ac78c8c7e7124d1017e90b771940c56

While the document explains how to achieve the opposite of what we want, using the Write_SCO_PCM_Int_Param command with the SCO_Routing parameter set to 0x01 should do what we want.

I'll give this a shot a soon as I find the time (which might not be before next week).

If I'm not completely off base, this document describes the necessary HCI command(s) to configure SCO routing: https://www.infineon.com/dgdl/Infineon-AN214937_Bluetooth_Audio_Over_I2S.pdf-ApplicationNotes-v02_00-EN.pdf?fileId=8ac78c8c7e7124d1017e90b771940c56 While the document explains how to achieve the opposite of what we want, using the ``Write_SCO_PCM_Int_Param`` command with the ``SCO_Routing`` parameter set to ``0x01`` should do what we want. I'll give this a shot a soon as I find the time (which might not be before next week).

peterharperuk commented

2025-04-30 08:31:32 -05:00

(Migrated from github.com)

SCO doesn't work. We haven't got a fix from Infineon.

willnix commented

2025-04-30 08:42:49 -05:00

(Migrated from github.com)

I got that. I'm basically suggesting the issue might be the fact that its just not routed via HCI transport by default.

mringwal commented

2025-04-30 13:16:19 -05:00

(Migrated from github.com)

SCO is routed over HCI in BTstack if ENABLE_SCO_OVER_HCI is defined (which it is as far as I know, feel free to double-check).
If SCO would be routed over the not connected I2S/PCM lines, nothing bad should happen.

I don't remember the details, but I think the CYW43439 either crashes or the SCO connection drops.

SCO is routed over HCI in BTstack if ENABLE_SCO_OVER_HCI is defined (which it is as far as I know, feel free to double-check). If SCO would be routed over the not connected I2S/PCM lines, nothing bad should happen. I don't remember the details, but I think the CYW43439 either crashes or the SCO connection drops.

willnix commented

2025-04-30 13:57:34 -05:00

(Migrated from github.com)

In my case I'm not using btstack on the Pico, because I just forward HCI via USB-CDC.

But I'll look into what btstack does when ENABLE_SCO_OVER_HCI is enabled.
Thank you very much for the hint! 😊

In my case I'm not using btstack on the Pico, because I just forward HCI via USB-CDC. But I'll look into what btstack does when ENABLE_SCO_OVER_HCI is enabled. Thank you very much for the hint! 😊

mringwal commented

2025-04-30 16:26:45 -05:00

(Migrated from github.com)

@willnix if you don't run BTstack on the Pico itself, you could use a regular USB Bluetooth dongle with your system, e.g. the Ezurio BT-851 with a CYW20704 which uses HCI over USB. SCO over HCI works there as expected.

matsobdev commented

2025-05-01 16:13:48 -05:00

(Migrated from github.com)

@willnix I was playing with HCI over CDC and https://softwaretools.infineon.com/tools/com.ifx.tb.tool.airocbluetoothtool is helpful (Cybluetool is as well). SCO wasn't workig as expected. Right after I've made it, I just stumbled upon that firmware issue. I don't know if it was an issue for you (I've used USB-CDC built in SDK and write() function), but buffers inside https://softwaretools.infineon.com/tools/com.ifx.tb.tool.airocbluetoothtool should be extended to 1026 I belive (max Bluetooth payload and headers and command type). If you have HCI-CDC interface so now it is easy to use that AIROC™ Bluetooth® Test and Debug Tool.

@willnix I was playing with HCI over CDC and https://softwaretools.infineon.com/tools/com.ifx.tb.tool.airocbluetoothtool is helpful (Cybluetool is as well). SCO wasn't workig as expected. Right after I've made it, I just stumbled upon that firmware issue. I don't know if it was an issue for you (I've used USB-CDC built in SDK and `write()` function), but buffers inside https://softwaretools.infineon.com/tools/com.ifx.tb.tool.airocbluetoothtool should be extended to 1026 I belive (max Bluetooth payload and headers and command type). If you have HCI-CDC interface so now it is easy to use that AIROC™ Bluetooth® Test and Debug Tool.

mringwal commented

2025-05-13 02:32:51 -05:00

(Migrated from github.com)

@peterharperuk / @kilograham Do you think Raspberry should ping Infineon once a year?
I don't think it's a hard problem, looks more like a missing "nice to have".

@peterharperuk / @kilograham Do you think Raspberry should ping Infineon once a year? I don't think it's a hard problem, looks more like a missing "nice to have".

mitchellcairns commented

2026-02-17 21:37:39 -06:00

(Migrated from github.com)

Hi, I've been digging into this issue and can confirm the exact same behavior with two Pico W's talking to each other, so it's not phone-specific.

Here's what I've been able to establish:

The SCO routing VSC (hci_bcm_write_sco_pcm_int) works fine and confirms HCI/Transport routing
hci_setup_synchronous_connection returns COMMAND_STATUS 0x00 on the master
hci_accept_synchronous_connection returns COMMAND_STATUS 0x00 on the slave
HCI_EVENT_SYNCHRONOUS_CONNECTION_COMPLETE never arrives on either side

So both the host stack and the firmware are accepting the commands without error, but the CYW43439 never actually completes the SCO negotiation. The firmware blob (CYW4343A2_001.003.016.0065.0000_Generic_SDIO) accepts the HCI commands just fine but appears to silently drop the ball on completing the synchronous link establishment over SPI.

Given this is milestoned for 2.4.0, could you share whether this is being tracked with Infineon/Cypress directly? The firmware blob is really the only place this can be fixed.

The BTstack side seems to be doing everything correctly sans setting up the SCO to tunnel via HCI (it defaults to PCM I guess). It would be really helpful to know if there's a newer firmware version from Infineon that addresses SCO over the PIO SPI, or if there's a specific configuration that needs to be applied to the firmware before SCO setup. Any visibility into the Infineon side of this would be greatly appreciated!

Hi, I've been digging into this issue and can confirm the exact same behavior with two Pico W's talking to each other, so it's not phone-specific. Here's what I've been able to establish: - The SCO routing VSC (hci_bcm_write_sco_pcm_int) works fine and confirms HCI/Transport routing - hci_setup_synchronous_connection returns COMMAND_STATUS 0x00 on the master - hci_accept_synchronous_connection returns COMMAND_STATUS 0x00 on the slave - HCI_EVENT_SYNCHRONOUS_CONNECTION_COMPLETE never arrives on either side So both the host stack and the firmware are accepting the commands without error, but the CYW43439 never actually completes the SCO negotiation. The firmware blob (CYW4343A2_001.003.016.0065.0000_Generic_SDIO) accepts the HCI commands just fine but appears to silently drop the ball on completing the synchronous link establishment over SPI. Given this is milestoned for 2.4.0, could you share whether this is being tracked with Infineon/Cypress directly? The firmware blob is really the only place this can be fixed. The BTstack side seems to be doing everything correctly sans setting up the SCO to tunnel via HCI (it defaults to PCM I guess). It would be really helpful to know if there's a newer firmware version from Infineon that addresses SCO over the PIO SPI, or if there's a specific configuration that needs to be applied to the firmware before SCO setup. Any visibility into the Infineon side of this would be greatly appreciated!

👍 4

Rows
Columns

bluetooth/btstack: SCO connection not established (PicoW) #1461