pico-sdk icon indicating copy to clipboard operation
pico-sdk copied to clipboard

bluetooth/btstack: SCO connection not established (PicoW)

Open vladbalmos opened this issue 1 year ago • 3 comments

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]

vladbalmos avatar Jul 21 '23 08:07 vladbalmos

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

peterharperuk avatar Jul 21 '23 08:07 peterharperuk

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

wolfscowl avatar Feb 05 '24 19:02 wolfscowl

No. Infineon are still working on it.

peterharperuk avatar Feb 05 '24 19:02 peterharperuk