raspberrypi / pico-sdk

BSD 3-Clause "New" or "Revised" License
3.26k stars 838 forks source link

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

Open vladbalmos opened 11 months ago

vladbalmos commented 11 months ago

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]

peterharperuk commented 11 months ago

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

Wolfscowl commented 5 months ago

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

peterharperuk commented 5 months ago

No. Infineon are still working on it.