Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bluetooth HSP/HFP not working in Raspberry PI 3 #2229

Open
SoloVeniaASaludar opened this issue Oct 14, 2017 · 55 comments

Comments

@SoloVeniaASaludar
Copy link

commented Oct 14, 2017

Trying to use a bluetooth mic/speaker in a raspberry pi 3 (headless).

Hardware is Raspberry pi 3, firmware updated today, running raspbian also dist-upgraded today. Using bluez and pulseaudio (system service start mode).

  • The device is trusted, paired and connects/disconnects without problems.
  • When device is initially connected, "pactl list" shows the device is using the profile named "headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: yes)". With this profile, no sound (trying to play with aplay command).
  • When profile is changed to "a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)" (using command pactl set-card-profile), the sound is played correctly.

No error messages seen in any log file.

Moreover, if I "down" ("hciadmin hci0 down") the internal raspberry bluetooth controller and use instead an external bluetooth controller connected in an usb port, both modes works correctly. Thus, problem seems related with the bluetooth device in raspberry card.

These are result from some related commands.

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.9.56-v7+ #1044 SMP Fri Oct 13 15:23:13 BST 2017 armv7l GNU/Linux

pi@raspberrypi:~ $ hciconfig -a
hci0:   Type: Primary  Bus: UART
    BD Address: B8:27:EB:7E:DA:2A  ACL MTU: 1021:8  SCO MTU: 64:1
    UP RUNNING 
    RX bytes:14641 acl:101 sco:0 events:1341 errors:0
    TX bytes:2208546 acl:2358 sco:7 commands:97 errors:0
    Features: 0xbf 0xfe 0xcf 0xfe 0xdb 0xff 0x7b 0x87
    Packet type: DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3 
    Link policy: RSWITCH SNIFF 
    Link mode: SLAVE ACCEPT 
    Name: 'raspberrypi'
    Class: 0x0c0000
    Service Classes: Rendering, Capturing
    Device Class: Miscellaneous, 
    HCI Version: 4.1 (0x7)  Revision: 0x145
    LMP Version: 4.1 (0x7)  Subversion: 0x2209
    Manufacturer: Broadcom Corporation (15)

pi@raspberrypi:~ $ pactl list
...
Card #3
    Name: bluez_card.E8_07_BF_11_10_A0
    Driver: module-bluez5-device.c
    Owner Module: 15
    Properties:
        device.description = "SPUBT710"
        device.string = "E8:07:BF:11:10:A0"
        device.api = "bluez"
        device.class = "sound"
        device.bus = "bluetooth"
        device.form_factor = "speaker"
        bluez.path = "/org/bluez/hci0/dev_E8_07_BF_11_10_A0"
        bluez.class = "0x240414"
        bluez.alias = "SPUBT710"
        device.icon_name = "audio-speakers-bluetooth"
    Profiles:
        headset_head_unit: Headset Head Unit (HSP/HFP) (sinks: 1, sources: 1, priority: 20, available: yes)
        a2dp_sink: High Fidelity Playback (A2DP Sink) (sinks: 1, sources: 0, priority: 10, available: yes)
        off: Off (sinks: 0, sources: 0, priority: 0, available: yes)
    Active Profile: headset_head_unit
    Ports:
        speaker-output: Speaker (priority: 0, latency offset: 0 usec)
            Part of profile(s): headset_head_unit, a2dp_sink
        speaker-input: Bluetooth Input (priority: 0, latency offset: 0 usec)
            Part of profile(s): headset_head_unit 

# systemctl status bluetooth
● bluetooth.service - Bluetooth service
   Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-10-14 15:49:16 UTC; 36min ago
     Docs: man:bluetoothd(8)
 Main PID: 461 (bluetoothd)
   Status: "Running"
   CGroup: /system.slice/bluetooth.service
           └─461 /usr/lib/bluetooth/bluetoothd

Oct 14 15:49:16 raspberrypi bluetoothd[461]: Bluetooth daemon 5.43
Oct 14 15:49:16 raspberrypi systemd[1]: Started Bluetooth service.
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Starting SDP server
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Bluetooth management interface 1.14 initialized
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Failed to obtain handles for "Service Changed" characteristic
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Sap driver initialization failed.
Oct 14 15:49:16 raspberrypi bluetoothd[461]: sap-server: Operation not permitted (1)
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Endpoint registered: sender=:1.3 path=/MediaEndpoint/A2DPSource
Oct 14 15:49:16 raspberrypi bluetoothd[461]: Endpoint registered: sender=:1.3 path=/MediaEndpoint/A2DPSink
Oct 14 15:55:04 raspberrypi bluetoothd[461]: /org/bluez/hci0/dev_E8_07_BF_11_10_A0/fd0: fd(24) ready

systemctl status pulseaudio

● pulseaudio.service - Pulse Audio
   Loaded: loaded (/etc/systemd/system/pulseaudio.service; enabled; vendor preset: enabled)
   Active: active (running) since Sat 2017-10-14 15:49:12 UTC; 36min ago
 Main PID: 343 (pulseaudio)
   CGroup: /system.slice/pulseaudio.service
           └─343 /usr/bin/pulseaudio --system --disallow-exit --disable-shm --exit-idle-time=-1

Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] main.c: OK, so you are running PA in system mode. Please make sure that you actually do want to do that.
Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] main.c: Please read http://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/WhatIsWrongWithSystemWide/ for an explanation why system mode is usually a bad idea.
Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] authkey.c: Failed to open cookie file '/var/run/pulse/.config/pulse/cookie': No such file or directory
Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] authkey.c: Failed to load authentication key '/var/run/pulse/.config/pulse/cookie': No such file or directory
Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] authkey.c: Failed to open cookie file '/var/run/pulse/.pulse-cookie': No such file or directory
Oct 14 15:49:12 raspberrypi pulseaudio[343]: W: [pulseaudio] authkey.c: Failed to load authentication key '/var/run/pulse/.pulse-cookie': No such file or directory
Oct 14 15:49:16 raspberrypi pulseaudio[343]: E: [pulseaudio] bluez5-util.c: Found duplicated D-Bus path for adapter /org/bluez/hci0
Oct 14 15:49:16 raspberrypi pulseaudio[343]: E: [pulseaudio] bluez5-util.c: Found duplicated D-Bus path for device /org/bluez/hci0/dev_E8_07_BF_11_10_A0
@pratham2003

This comment has been minimized.

Copy link

commented Nov 8, 2017

I'm facing the same issue too

1 similar comment
@Pillar1989

This comment has been minimized.

Copy link

commented Nov 22, 2017

I'm facing the same issue too

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

Would it be possible for commenters to try the latest kernel (4.14) and see if the problems persists? Note, this is a testing branch, so should not be done on a critical system unless it's well backed up!

sudo BRANCH=next rpi-update

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

It's not a kernel issue - it's a BlueZ limitation. As of version 5.0, BlueZ does not support HFP or HSP, only A2DP. I've not found an official explanation from BlueZ, but there are some notes from the PulseAudio devs here: https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/5.0/

If anyone knows of a solution that doesn't involve installing BlueZ 4 as well I'll be interested to hear it.

@viktorgino

This comment has been minimized.

Copy link

commented Dec 5, 2017

To get HFP/HSP working properly you'll need PulseAudio 11 https://www.freedesktop.org/wiki/Software/PulseAudio/Notes/11.0/
HFP works using ofono, but it is only started fully working with version PA version 11.
@SoloVeniaASaludar can you try to install lates versions of PA, bluez and ofono and report back?

@bluetiger9

This comment has been minimized.

Copy link

commented Jan 21, 2018

Seems that, we have a solution to use the HSP profile with Raspberry Pi 3’s built in BCM43438 chip. The culprit was the so called SCO audio routing. HSP / HFP uses SCO audio packets to transmit audio and in order to make PulseAudio work the packets must be routed to the HCI interface. This can be done by sending the the following HCI command:

sudo hcitool cmd 0x3F 0x01C 0x01 0x02 0x00 0x01 0x01

After issuing this command, both paplay and parecord should work with the HSP profile.

More details here:
https://www.spinics.net/lists/linux-bluetooth/msg73883.html
https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Bluetooth/#index8h3
http://youness.net/raspberry-pi/bluetooth-headset-raspberry-pi-3-ad2p-hsp#comment-2484

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Jan 23, 2018

Ooh, interesting. That hci command that could easily be added to the Pi-specific script /usr/bin/btuart if it solves the problem.

@YOUN3SS

This comment has been minimized.

Copy link

commented Feb 8, 2018

Hi,

I confirm that this command solves the problem.
More details: How To Connect Bluetooth Headset Or Speaker To Raspberry Pi 3

@kp339

This comment has been minimized.

Copy link

commented Apr 10, 2018

Hi,

hcitool cmd can solve the connect problem in HSP/HFP mode, but the sound is terrible, have distortion.
Do anyone have the same problem as I do?

Thanks!

@bluetiger9

This comment has been minimized.

Copy link

commented Apr 10, 2018

@kp339, the sound is a little noisy for me too. I contacted the Cypress's support, their FW team is checking the CYW43438's firmware right now.

@kp339

This comment has been minimized.

Copy link

commented Apr 10, 2018

@bluetiger9 If there is any progress, please let me know. Thanks!

@CliveWongTohSoon

This comment has been minimized.

Copy link

commented May 17, 2018

It happens to me too, the sound is too distorted until the speech recognition can't even work. Please let me know how to improve the sound quality.

@bluetiger9

This comment has been minimized.

Copy link

commented May 23, 2018

The problem was identified as a timing issue in PulseAudio.

In an nutshell, PulseAudio uses a hard-coded (e)SCO packet size of 48 bytes, instead of using the packet size negotiated at the eSCO connect (ex 60 bytes). The timing logic used for SCO connections, is to send (e)SCO packets (one at a time), at each SCO packet received. If the negotiated packet size is bigger (ex 60 bytes) than the hard-coded 48 bytes, the SCO packets are received at a lower rate, which causes PulseAudio to send the SCO packets way too slow.

More details on the following [pulseaudio-discuss] thread:
[pulseaudio-discuss] Bluetooth - HSP / HFP - source based timing & hard-coded MTU causes SCO packets to be badly delayed

As a workaround PulseAudio 11.1 can be used, with the module-bluetooth-discover started with autodetect_mtu=yes parameter. The parameter can be set in /etc/pulse/default.pa:

.ifexists module-bluetooth-discover.so
load-module module-bluetooth-discover autodetect_mtu=yes
.endif

(note: be aware that this setting breaks the compatibility with some adapters)

The PulseAudio 11.1 is not yet available for Raspbian, but it can be compiled from source:

$ git clone git://anongit.freedesktop.org/pulseaudio/pulseaudio
$ cd pulseaudio
$ sudo apt-get build-dep pulseaudio
$ ./bootstrap.sh
$ make
$ sudo make install
$ sudo ldconfig

Cheers,
Attila

@kp339

This comment has been minimized.

Copy link

commented May 24, 2018

Yeah, and if your PulseAudio's version lower than 11.1, you can try this way:

  1. You should build pulseaudio from source like Attila push below
  2. Modify the mtu packets in source code, bcm43438 mtu packets is 64
diff --git a/src/modules/bluetooth/backend-native.c
index 8d9d95c..7dde1f8 100644
--- a/src/modules/bluetooth/backend-native.c
+++ b/src/modules/bluetooth/backend-native.c
@@ -148,10 +148,10 @@ static int bluez5_sco_acquire_cb(pa_bluetooth_transport *t, bool optional, size_
      * by the kernel */
 
     if (imtu)
-        *imtu = 48;
+        *imtu = 64;
 
     if (omtu)
-        *omtu = 48;
+        *omtu = 64;

diff --git a/src/modules/bluetooth/backend-ofono.c
index 755df9e..e1091b6 100644
--- a/src/modules/bluetooth/backend-ofono.c
+++ b/src/modules/bluetooth/backend-ofono.c
@@ -170,9 +170,9 @@ static int hf_audio_agent_transport_acquire(pa_bluetooth_transport *t, bool opti
      * made available to userspace by the Bluetooth kernel subsystem.
      * Meanwhile the empiric value 48 will be used. */
     if (imtu)
-        *imtu = 48;
+        *imtu = 64;
     if (omtu)
-        *omtu = 48;
+        *omtu = 64;
 
     t->codec = card->codec;



  1. If you want to fit more devices, you can modify the code refer to the 11.1 source.

  2. Rebuild the pulseaudio source code and replace the libbluez5-util.so in system:
    $ sudo cp ./src/.libs/libbluez5-util.so /usr/lib/pulse-x.x/modules

  3. Reboot the system

  4. And from the test I found that before you connect your headset, you should enter HCI command first or you will find that your headset profile "headset_head_unit" available is no.

Thanks Attila.

@CliveWongTohSoon

This comment has been minimized.

Copy link

commented May 24, 2018

Hi @bluetiger9 the issue seems to be fixed, sound improves dramatically, thanks! However, I noticed that I can't seem to play anything in my root after using this (I need to be in the root to run manipulate GPIO on my pi), is there any fix? The audio does play with paplay audio.wav, but if I go to my root, paplay audio.wav gives error as such:

No protocol specified
xcb_connection_has_error() returned true
Connection failure: Connection refused
pa_context_connect() failed: Connection refused

Any idea how to fix?

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2018

Can anybody give a précis of the current state of this? Sounds like it's pretty much fixed?

Related to #1401?

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Jun 28, 2018

Yes, the two issues are (already) linked. The next Raspbian release (due shortly) includes a startup script to send the HCI command mentioned above that switches SCO traffic to the HCI interface.

@et-hzn

This comment has been minimized.

Copy link

commented Oct 18, 2018

Indeed. Issues with SCO traffic routing and mtu packet size are fixed. I can confirm that but....
After using it for a while and making calls there is a timeout error on hci0;

I am using R-Pi3B+ with
Linux RPi-Host-1 4.14.71-v7+ #1145 SMP Fri Sep 21 15:38:35 BST 2018 armv7l GNU/Linux
Raspbian Stretch 9.4
PulseAudio 10.0 (patched for coping with the MTU size problem)
Bluez 5.50
Ofono 1.18

/var/log/kern.log shows something like this when the error occurs:

Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649493] Bluetooth: hci0 command 0x0c24 tx timeout
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649742] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649749] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649808] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649858] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649893] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649909] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:21 RPi-Host-1 kernel: [51675.649980] Bluetooth: hci0: Frame reassembly failed (-84)
Oct 18 09:25:23 RPi-Host-1 kernel: [51677.719490] Bluetooth: hci0 command 0x0c52 tx timeout
Oct 18 09:25:25 RPi-Host-1 kernel: [51679.799507] Bluetooth: hci0 command 0x0406 tx timeout
Oct 18 09:28:56 RPi-Host-1 kernel: [51890.408019] Bluetooth: hci0 link tx timeout

The only way I have found until now to get it going again is re-booting the RaspberryPi.

Reloading bluetooth (sudo systemctl relaod bluetooth) does not solve this. And unloading the kernel modules (rmmod bluetooth) is impossible as the module is "in use"

Anybody knows of any progress in getting newer BCM43438 firmware? Or knows how to restart bluetooth without rebooting?

Thanks,

Engelbert

@oscargomezf

This comment has been minimized.

Copy link

commented Oct 18, 2018

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2018

I use the following script to reset the bluetooth interface - I call it btreset:

sudo killall hciattach
if grep -a Zero /proc/device-tree/model; then
  raspi-gpio set 45 op dl
  sleep 1
  raspi-gpio set 45 op dh
else
  /opt/vc/bin/vcmailbox 0x38041 8 8 128 0
  sleep 1
  /opt/vc/bin/vcmailbox 0x38041 8 8 128 1
fi
sleep 4
sudo btuart
@oscargomezf

This comment has been minimized.

Copy link

commented Oct 18, 2018

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Oct 18, 2018

  1. It is 45 on the Zero, and 128 (GPIO 0 of the expander) on the 3B+.
  2. Just BT.
  3. Do you see the "... 0", sleep 1, "... 1"? That's low, then high.
@bluetiger9

This comment has been minimized.

Copy link

commented Oct 18, 2018

@et-hzn

This comment has been minimized.

Copy link

commented Oct 19, 2018

Phil,

Thanks a lot. That indeed resets the bluetooth device and communication is re-established on my R-Pi3B+.

Now of course I would like to know why it gets stuck but that is probably a firmware problem somewhere. Would not know how to debug that.

Another thing I noticed is that after every HFP call I make the usage count of bluetooth kernel module is increasing by 1. Actually during the call it is increasing by 2 and when the call is finished only a +1 remains. So something is released but not everything.

Anybody any hints on how to attack this? Or is there a way to forcefully reload the bluetooth kernel module at regular interval to reset the count? "rmmod bluetooth" does not work obviously as the count is not 0 so the module is "in use"

Thanks,

Engelbert

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2018

Another thing I noticed is that after every HFP call I make the usage count of bluetooth kernel module is increasing by 1.

Although I understand the basic concepts I've never written a Bluetooth app of any description. However, a simple, repeatable problem like you describe sounds very fixable. If you can reduce your code down to the simple test and upload it somewhere with simple instructions (including links for installing any non-standard dependencies) I can take a look when I get a moment.

@oscargomezf

This comment has been minimized.

Copy link

commented Oct 19, 2018

@et-hzn

This comment has been minimized.

Copy link

commented Oct 19, 2018

Well actually this is what I see:
Before a call:
#lsmod |grep bluetooth|grep hci_uart
bluetooth 368640 220 hci_uart,btbcm,rfcomm

After the call:
#lsmod |grep bluetooth|grep hci_uart
bluetooth 368640 221 hci_uart,btbcm,rfcomm

But I have no clue what is now exactly increasing and indeed as you point out does it harm?

An "rfkill list" on my R-Pi only shows this btw:

rfkill list

3: hci0: Bluetooth
Soft blocked: no
Hard blocked: no

@et-hzn

This comment has been minimized.

Copy link

commented Oct 19, 2018

Phil,

Below how to do that. (to get it down to the very basic) but actually it is not a bluetooth app that I am developing it is actually getting HFP working stable (also using Ofono and Pulseaudio as part of this) so it continues to work over a long period of time.

You will need the ofono source to be installed as it contains a number of python scripts that will allow you to use ofono to make calls etc.

The basics actually comes down to this:

  1. Make sure bluetooth pairing between R-Pi and Mobile phone is succesfull and both are in connected state
  2. Make sure the "ofono modem" is enabled (use "enable-modem" from the ofono tools)
  3. Check the count using: lsmod |grep bluetooth (value = x)
  4. Make a call using "dial-number extension-to-be-dialed" from ofono tools
  5. Answer the call at the B-party (HFP now active and sound on headset/speaker on R-Pi side)
  6. Check the count (it is now increased by 2 so x+2).
  7. Terminate the call
  8. Check the count again. It is now x+1.

During the call 2 "sound channels" are opened via bluetooth to get the audio to/from the R-Pi. Maybe one of them is not released correctly? Could of course also be a PulseAudio or Ofono problem. And maybe it is no problem at all.
After booting the and before the first call the usage count is:28 and I now have it at 575 and still working OK

Engelbert

@oscargomezf

This comment has been minimized.

Copy link

commented Oct 20, 2018

@et-hzn

This comment has been minimized.

Copy link

commented Oct 21, 2018

Oscar,

What exact problem do you have? Resetting the BT device using the commands provided by Phil will solve issue whe Bluetooth device (hci0) is not responding anymore. When that happens you will have something like this in your /var/log/kern.log file:

Oct 19 21:55:39 RPi-Host-1 kernel: [116182.475828] Bluetooth: hci0 hardware error 0x00
or
Oct 19 22:01:55 RPi-Host-1 kernel: [116558.846998] Bluetooth: hci0 command 0x0406 tx timeout
or
Oct 19 22:01:55 RPi-Host-1 kernel: [116558.847226] Bluetooth: hci0: Frame reassembly failed (-84)

When the device error happens the bt-reset (as described by Phil) will re-initialise everything for bluetooth and if pairing was succesfull before and devices trusted also the Bluetooth device will be re-connected. At least that is what is happening in my setup.

Do you already have succesfully paired R-Pi3B+ and a mobile phone?
Able to make a call using the Ofono python tools?
Why are you referring to USB? For HFP yuo don't need USB unless you have connected a USB headset for the audio part?

Engelbert

@oscargomezf

This comment has been minimized.

Copy link

commented Oct 22, 2018

@et-hzn

This comment has been minimized.

Copy link

commented Oct 23, 2018

Oscar,

I don't know this bt-adapter program. It is for sure not present on my Raspbian based RaspberryPi 3B+.

What results do you get when using bluetoothctl?

Engelbert

@oscargomezf

This comment has been minimized.

Copy link

commented Oct 29, 2018

Hi Engelbert,

I'm sorry for answering so late.

bt-adpater is a command from the new bluez-utils 5.x. It is similar to hcitool (bluez3 utils). This two command are equivalent:

$ hcitool -i hci0 scan

and

$ bt-adapter -a hci0 -d

Best regards.

Oscar Gomez Fuente
TST Sistemas
www.tst-sistemas.es

@et-hzn

This comment has been minimized.

Copy link

commented Nov 2, 2018

Oscar,

Hmm. I don't have that problem. See below example from my R-Pi3B+:

pi@xgen-rpi-x:~ $ hcitool -i hci0 scan
Scanning ...
B8:27:EB:89:87:38 RPi-Host-1

Engelbert

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 22, 2018

I use the following script to reset the bluetooth interface - I call it btreset:

/opt/vc/bin/vcmailbox 0x38041 8 8 128 0
sleep 1
/opt/vc/bin/vcmailbox 0x38041 8 8 128 1

This command works fine on rpi 3b but makes no difference on rpi 3b+. Did the GPIO for BT_ON changed on rpi 3b+?

Tested while using bluetooth and it stops completely once set to 0 on rpi 3b but keeps working normally on 3b+. I was only able to disable bluetooth when disabling WL_ON (GPIO 1 of the expander).

Tested with latest raspbian (2018-11-13).

@oscargomezf

This comment has been minimized.

Copy link

commented Nov 23, 2018

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

The BT_ON GPIO is exactly the same on the 3B+ as on the 3B - GPIO #0 on the expander, aka GPIO 128. The btreset command I posted above works as advertised for me.

Two suggestions:

  1. Try increasing the length of the sleeps.
  2. Before running it, run these shell commands:
# Clear the dmesg log so you only see new additions
sudo dmesg -C
# Display new entries in the kernel log - stop with "fg" and Ctrl-C, or "kill %1" (if 1 is its job number).
dmesg -w &

For comparison, the output I get is:

pi@raspberrypi:~$ btreset
[  155.522982] Bluetooth: hci0: sending frame failed (-49)
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
bcm43xx_init
Flash firmware /lib/firmware/BCM4345C0.hcd
Set BDADDR UART: b8:27:eb:b6:57:72
Set Controller UART speed to 3000000 bit/s
Device setup complete
@et-hzn

This comment has been minimized.

Copy link

commented Nov 23, 2018

Confirmed here also that this procedure as described by Phil in indeed working on my R-Pi3B+'s ( I have a couple and they all work).

What worries me more is the frequency of btresets that is needed to keep bluetooth operational. At least a couple per day when continuously using bluetooth connection to a mobile phone.

Anybody any idea what is causing the lockup?

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

The BT_ON GPIO is exactly the same on the 3B+ as on the 3B - GPIO #0 on the expander, aka GPIO 128. The btreset command I posted above works as advertised for me.

Weird as it makes no difference on my rpi 3b+, running the same script on a clean raspbian (2018-11-13), but it does work fine on my rpi 3b.

Two suggestions:

  1. Try increasing the length of the sleeps.
  2. Before running it, run these shell commands:

Tried with different sleep values but no difference, it seems changing BT_ON is not really having any side effect on the chip. I can only get the expected behavior if I also change WL_ON.

pi@raspberrypi:~ $ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)"
NAME="Raspbian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"

pi@raspberrypi:~ $ ./btreset
#!/bin/sh
+ sudo killall hciattach
+ /opt/vc/bin/vcmailbox 0x38041 8 8 128 0
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
+ sleep 5
#!/bin/sh
+ /opt/vc/bin/vcmailbox 0x38041 8 8 128 1
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
+ sleep 5
+ sudo btuart
bcm43xx_init
Failed to reset chip, command failure
Can't initialize device: Success

Kernel log:
Nov 23 12:55:11 raspberrypi kernel: Bluetooth: hci0 sending frame failed (-49)

pi@raspberrypi:~ $ cat /proc/cpuinfo
...
Hardware	: BCM2835
Revision	: a020d3
Serial		: 000000002598ab32

Early boot:
Nov 22 21:19:35 raspberrypi kernel: Booting Linux on physical CPU 0x0
Nov 22 21:19:35 raspberrypi kernel: Linux version 4.14.79-v7+ (dc4@dc4-XPS13-9333) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0
Nov 22 21:19:35 raspberrypi kernel: CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=10c5383d
Nov 22 21:19:35 raspberrypi kernel: CPU: div instructions available: patching division code
Nov 22 21:19:35 raspberrypi kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Nov 22 21:19:35 raspberrypi kernel: OF: fdt: Machine model: Raspberry Pi 3 Model B Plus Rev 1.3
@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

I use the standard way to use GPIOS on my raspberry Pi 3B+ (export, write,... etc using /sys/class/ method).

I used this method and it also works fine on my pi 3b, but fails the same way on my pi 3b+. And this is a problem because upstream dtb uses the BT_ON gpio to enable/disable the chip, so I can't really get it to work again after removing and loading the hci_uart module (as it stays broken, as it does after running the btreset script).

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

To be clear, if you comment out the killall hciattach and the btuart command, is BT completely unaffected by the btreset script?

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

What worries me more is the frequency of btresets that is needed to keep bluetooth operational. At least a couple per day when continuously using bluetooth connection to a mobile phone.

Anybody any idea what is causing the lockup?

That would be ideal, as I'm getting tons of hardware errors as well (using my rpi as a bt 6lowpan gateway, with several bt le mcus connected at the same time).

Is there any way to get this reported to cypress? Not sure if the chip has a method to extract the crash/error dump.

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

To be clear, if you comment out the killall hciattach and the btuart command, is BT completely unaffected by the btreset script?

Completely unaffected, keeps working just fine (had another terminal running 'hcitool lescan --duplicates' and made no difference).

On my rpi 3b it stops the scan right after bringing BT_ON down (the first vcmailbox line).

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

Is there any way to get this reported to cypress? Not sure if the chip has a method to extract the crash/error dump.

Unfortunately bugs like this - running it for a long time in a complex setup locks up after several hours - take a lot of effort to reproduce, often without success because they depend on an unknown environmental factor, so they are way down the list.

The only comms channel we have to the modem is the UART, and when it becomes unresponsive the only way to wake it is the reset, which loses any state. I have a feeling the chip may have JTAG interface, but it isn't something we've hooked up and have no idea how you would go about using it.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

Completely unaffected, keeps working just fine (had another terminal running 'hcitool lescan --duplicates' and made no difference).

That's what I thought you meant. It's really strange, because it works for me. BT_ON and WL_ON are adjacent on both the GPIO expander and the modem, so a short isn't impossible.

Could you try using the sysfs interface to, one at a time, make each of the first two GPIOs on the expander (for me they are 504 and 505) an input and report its value while the other GPIO is an output driving high, and output driving low, and an input? (Doing so will kill your WiFi, of course).

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

I have a feeling the chip may have JTAG interface, but it isn't something we've hooked up and have no idea how you would go about using it.

Looking at the bcm43455 data sheet it seems there is a jtag/swd interface available for debugging, but might require proprietary tools. Do you know if the SWD pins are at least exported as test points on the rpi?

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

Could you try using the sysfs interface to, one at a time, make each of the first two GPIOs on the expander (for me they are 504 and 505) an input and report its value while the other GPIO is an output driving high, and output driving low, and an input? (Doing so will kill your WiFi, of course).

Doesn't look like there is a short, they kept with different values even when playing with in/out as direction (out didn't change the in value, when testing with 504 and 505).

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

Can also confirm that I'm getting the same behavior on new rpi 3b+ I got a few days ago, so this is the second 3b+ that got the same issue.

What is weird is that BT_ON is needed for bluetooth to work and I can only get it to reset after bringing WL_ON down and up, which indicates that there could indeed be a short somehow (manual says that all regulators are powered down only when both BT_REG_ON and WL_REG_ON are deasserted).

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

The JTAG/SWD pins appear to not be connected - I know that routing was very tight in that area.

@ricardosalveti

This comment has been minimized.

Copy link

commented Nov 23, 2018

@pelwell do you know if there is any test pin I can use to confirm the BT/WL_ON pin values? Looks like the wireless piece is not covered in the public schematics, and it's quite hard to find that out even without the shield.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

No - there are no suitable test pins.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

@ricardosalveti A recent read of the 3A+ schematic revealed that, due to routing congestion around the WiFi combo chip, the BT_ON pin is slaved off the WL_ON pin, both being driven by GPIO1 on the expander. During the discussion with the hardware team it came to light that this same arrangement is used on the current production 3B+s, which explains the behaviour you have seen.

The 3B+ on my desk I use for testing, and the schematic I have for the 3B+, comes from the penultimate design that still had BT_ON on a dedicated pin (GPIO 0 on the expander), which unfortunately was not suitable for volume manufacturing.

@ricardosalveti

This comment has been minimized.

Copy link

commented Dec 15, 2018

@pelwell thanks for the update, good to have a confirmation from the hardware side, too bad there is no a good software workaround that can be done without also affecting wifi when getting bt hardware errors.

Do you know if there is a way identify, from the software side, the 3b+ boards that are using the latest design? That way we could at least have a software workaround that would not affect the boards based on the penultimate design.

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2018

No, unfortunately - both versions are programmed with the same revision code:

$ grep Revision /proc/cpuinfo
Revision        : a020d3
@ole1986

This comment has been minimized.

Copy link

commented Jun 13, 2019

Will the raspberry also work with HFP using ofono?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.