Bluetooth connection drops randomly

[acolombier]

Describe the bug

I am experiencing random Bluetooth connect drop between the Pi and an audio speaker. These drops appear after a random time, sometime few minutes, sometime few hours.

Once the the drop happen, the only fix is to reboot the PI: RFKILL report no block, Bluez report an Unknown Error, hciconfig hci0 down && hciconfig hci0 up has no effect, only the dmesg seems to spot a problem.

I am using LibreElec 9 (8.95.003)

I am using both onboard Wi-Fi and Bluetooth (I upgraded to 3 to 3B+ because I read the antenna design was changed and allow both in use)

To reproduce

Connect a Bluetooth speaker, and start playing audio on it.

Expected behaviour

No drop at any time, or at least no need for reboot

Actual behaviour

Bluetooth getting completely unusable after drop

System

• Which model of Raspberry Pi? Pi3B+
• Which OS and version (cat /etc/rpi-issue)? LibreElec 9 (8.95.003)
• Which firmware version (vcgencmd version)? bcefbb195b77d6b9a02dfbad0e1fff3b18122585 (Jan 9 2019 20:07:49)
• Which kernel version (uname -a)? 4.19.14

Logs

• dmesg*

[   xxxx] Bluetooth: hci0: hardware error 0x00
[   xxxx] Bluetooth: hci0: command 0x1003 tx timeout
[   xxxx] Bluetooth: hci0: command 0x1007 tx timeout
[   xxxx] Bluetooth: hci0: command 0x1009 tx timeout
<Keep repeating>

** Additional context **

I was using the RPI 3 before, with the exact same OS/Version, but this one didn't experience such a bug.

[pelwell]

We've recently received an updated Bluettooth firmware for the BCM43455 that hasn't made its way into a release yet. Can you see if it improves the symptoms for you?

1. Download the file from here.
2. Back-up the old file:

$ cp /lib/firmware/brcm/BCM4345C0.hcd BCM4345C0.hcd.orig

3. Copy in the new version:

$ sudo cp BCM4345C0_003.001.025.0156.0280.hcd /lib/firmware/brcm/BCM4345C0.hcd

4. Reboot.

To return to the original firmware, should you need to:

$ sudo cp BCM4345C0.hcd.orig /lib/firmware/brcm/BCM4345C0.hcd

[MilhouseVH]

@pelwell as this is LibreELEC the firmware should be copied to

/storage/.config/firmware/brcm/BCM4345C0.hcd

and there is no need to backup the existing firmware (which is in the read-only squashfs).

I've actually been including the new Bluetooth firmware in LibreELEC test builds for the last 10 days (not yet merged) since build #0117 so upgrading from 8.95.003 to a recent nightly will automatically include the new firmware (along with 4.19.17 in the latest #0126 release).

However upgrading only the Bluetooth firmware will result in a simplified before/after testing scenario, which might be the best option for now.

[pelwell]

Thanks, @MilhouseVH.

[acolombier]

Thanks @pelwell and @MilhouseVH. I have just installed the driver at the indicated location, I will come back here for the result of this fix.

[acolombier]

Unfortunately, I'm still experiencing the same issue. I don't have a computer with me currently, so I can't check if dmesg is logging the same error, but the symptoms are strictly the same. Do I have a way to ensure the new driver is loaded correctly?

[pelwell]

I haven't found a way of reading the version of the loaded firmware, but you can extract version info from the firmware file using strings:

pi@raspberrypi:~$ strings /lib/firmware/brcm/BCM4345C0.hcd | grep Raspberry
&BCM43455 37.4MHz Raspberry Pi 3+-0156

[orclex]

Same problem with bluetooth connection drops here. Only a pi restart helps, bluetooth restart does nothing.

Raspberry Pi 3B+ Raspbian GNU/Linux 10 (buster) $ strings /lib/firmware/brcm/BCM4345C0.hcd | grep Raspberry &BCM43455 37.4MHz Raspberry Pi 3+-0159

[iczero]

Same problem here. After what seems to be a random period of time, an error occurs and bluetooth stops working. Restarting hciuart reports the device is not responding.

$ strings /lib/firmware/brcm/BCM4345C0.hcd | grep Raspberry
&BCM43455 37.4MHz Raspberry Pi 3+-0156

[pelwell]

Which kernel versions are you all running (uname -a)? The recent 4.19.58 release includes a trial fix for a UART driver bug that would cause it to lose chunks of characters under the right conditions. You can try the new kernel by running sudo rpi-update (I'm not aware of any major issues with the current testing builds, but it's wise to make a backup first and not run bleeding-edge firmware on systems you can't afford to be without).

[JamesH65]

@acolombier @iczero @orclex Did moving to 4.19.58 fix your issues?

[notare-alname]

I had similar issues and rpi-update solved it for me.

[orclex]

@acolombier @iczero @orclex Did moving to 4.19.58 fix your issues? Unfortunately I cannot test it anymore. I've disabled the bluetooth device and added an external bluetooth USB device which is working without problems. Now the RPi is working productive and I cannot experiment anymore. Maybe someone other can confirm that it is working now?

[rixwoodling]

This issue still appears to be open as OP has described on version 4.19.66, RPi3B+. Bluetooth connects, audio plays. Then, audio drops at a random time and I am unable to determine why it drops and how to reconnect without rebooting as a workaround. It is worth noting that when attempting to 'power on' bluetooth after a dropout, it never does:

sudo bluetoothctl

Agent registered
[bluetooth]# show
: 
Powered: no
: 
[bluetooth]# power on
[bluetooth]# show
: 
Powered: no
: 
Failed to set power on: org.bluez.Error.Failed

---

Linux 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv71 GNU/Linux
&BCM43455 37.4MHz Raspberry Pi 3+-0156 # Raspbian 10 ( Buster )

[schornstephan]

I experience the same problem as OP. I investigated a little and found out, that the Bluetooth device, the BCM4345, seems to rest in an unusable state. As a hardware defect seems highly unlikely, I'd guess there is a problem with the firmware as already stated. However, Rasbian for example doesn't seem to be affected although it uses the same firmware (can someone confirm that?). Are there any things that Libreelec does differently than Raspbian for example when sending signals to the chip? It should be something that happens during normal operation, like keep alive signals or something like that.

However, as I'm no expert on that, I tried a different approach to achieve a workaround: Power cycling the BCM4345 during normal operation. It seems to be possible for USB devices by echoing signals to /sys/bus/usb/devices[...]/control. But I was not successful in determining how this chip is connected to the board. It doesn't seem to be usb, my best guess is sdio. I also wasn't successful in turning off any sdio device. I just got an sh: write error: Invalid argument when attempting to write into the control file.

Has anybody any ideas about this powercycling effort? If it's possible to do it, it was easy to implement it into some script... I am at the limit of my knowledge here...

[orclex]

Since Raspbian 10 runs on my Pi 3B+, I can unfortunately say that it is definitely affected, too.

[schornstephan]

Thanks! That's too bad. I've got a Rasbian running, too. I've used Bluetooth audio every now and then on it and never experienced these drops on it. Probably, that was just a coincidence. Randomly occurring errors really are a pain in the a...

[ole1986]

So sad, same here:

strings /lib/firmware/brcm/BCM4345C0.hcd | grep Raspberry
&BCM43455 37.4MHz Raspberry Pi 3+-0159

Sporadically breaks and only a reboot is the solution

[schornstephan]

@acolombier @iczero @orclex Did moving to 4.19.58 fix your issues?

I'm on 4.19.66 and nothing has changed. The "waiting for input" label can be removed.

[hajo62]

I see the same. If no solution could be found, maybe someone has an idea how to re-enable without need to boot the whole system?

$uname
4.19.66-v7+

$strings /lib/firmware/brcm/BCM4345C0.hcd | grep Raspberry
&BCM43455 37.4MHz Raspberry Pi 3+-0156

$dmesg | grep Bluetooth
[   12.467080] Bluetooth: Core ver 2.22
[   12.467239] Bluetooth: HCI device and connection manager initialized
[   12.467262] Bluetooth: HCI socket layer initialized
[   12.467277] Bluetooth: L2CAP socket layer initialized
[   12.467324] Bluetooth: SCO socket layer initialized
[   12.525705] Bluetooth: HCI UART driver ver 2.3
[   12.525719] Bluetooth: HCI UART protocol H4 registered
[   12.525805] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   12.526016] Bluetooth: HCI UART protocol Broadcom registered
[   12.917144] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   12.917152] Bluetooth: BNEP filters: protocol multicast
[   12.917166] Bluetooth: BNEP socket layer initialized
[   17.484314] Bluetooth: RFCOMM TTY layer initialized
[   17.484343] Bluetooth: RFCOMM socket layer initialized
[   17.484382] Bluetooth: RFCOMM ver 1.11

$sudo bluetoothctl
[NEW] Controller BB:22:EE:88:66:77 raspberrypi [default]
[NEW] Device 44:66:AA:DD:FF:DD MJ_HT_V1
[bluetooth]# show
Controller B8:27:EB:82:66:70
	Name: raspberrypi
	Alias: raspberrypi
	Class: 0x480000
	Powered: yes
	Discoverable: no
	Pairable: yes
	UUID: Headset AG                (00001112-0000-1000-8000-00805f9b34fb)
	UUID: Generic Attribute Profile (00001801-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Generic Access Profile    (00001800-0000-1000-8000-00805f9b34fb)
	UUID: PnP Information           (00001200-0000-1000-8000-00805f9b34fb)
	UUID: A/V Remote Control Target (0000110c-0000-1000-8000-00805f9b34fb)
	UUID: Audio Source              (0000110a-0000-1000-8000-00805f9b34fb)
	UUID: Handsfree Audio Gateway   (0000111f-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d052B
	Discovering: no

[pelwell]

I have a script I call btreset that I've published on other threads:

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

[hajo62]

Thanks for the script @pelwell : Unfortunately it does not solve my problem and the last command results in a timeout.

sudo btuart:

bcm43xx_init
Initialization timed out.

[pelwell]

You could try increasing the sleep 1s to sleep 2s (or make them all 10 to be certain), but that really ought to hard-reset the BT modem. If it still doesn't work with the extra delays, what does raspi-gpio get 30-33 report?

[hajo62]

Made all three sleeps to 10s. Still Initialization timed out.

$raspi-gpio get 30-33
GPIO 30: level=0 fsel=7 alt=3 func=CTS0
GPIO 31: level=1 fsel=7 alt=3 func=RTS0
GPIO 32: level=1 fsel=7 alt=3 func=TXD0
GPIO 33: level=1 fsel=7 alt=3 func=RXD0

[pelwell]

Does the reset work before the connection drops?

[hajo62]

I will try, but than the connection is on again and I can't say how long it takes, till it drops again. Last time it took 24h. Sometimes it is several days..

[pelwell]

If it's not too late, can you capture the output of dmesg before rebooting?

[pelwell]

Unless you are frequently disconnecting and reconnecting USB devices, or there is some problem in the system, the kernel log ought to be quiet. I'm curious to see if there was any clue as to why the BT modem died.

[hajo62]

Has been to late but term history had the output before running your script. Putted the dmseg output to dropbox and will remove in an hour. https://www.dropbox.com/s/3r5dh665opy7seh/dmesg.out?dl=0 (removed sharing...)

I have just one device connected to my Pi...

How would I mail a log only to you without storing in github?

[pelwell]

I saw the log before it disappeared. There was nothing BT-related, just a lot of Docker messages.

Let me know when you've managed to try a reset before the failure.

[hajo62]

Here the output of your script:

0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000 
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000 
bcm43xx_init
Initialization timed out.

Looks like I do not receive values from that sensor after I ran the script.

$ dmesg | grep Bluetooth
[   11.651060] Bluetooth: Core ver 2.22
[   11.651120] Bluetooth: HCI device and connection manager initialized
[   11.651136] Bluetooth: HCI socket layer initialized
[   11.651143] Bluetooth: L2CAP socket layer initialized
[   11.651164] Bluetooth: SCO socket layer initialized
[   11.695777] Bluetooth: HCI UART driver ver 2.3
[   11.695788] Bluetooth: HCI UART protocol H4 registered
[   11.695840] Bluetooth: HCI UART protocol Three-wire (H5) registered
[   11.695992] Bluetooth: HCI UART protocol Broadcom registered
[   12.252713] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   12.252727] Bluetooth: BNEP filters: protocol multicast
[   12.252756] Bluetooth: BNEP socket layer initialized
[   12.462355] Bluetooth: RFCOMM TTY layer initialized
[   12.462380] Bluetooth: RFCOMM socket layer initialized
[   12.462403] Bluetooth: RFCOMM ver 1.11
[43032.385004] Bluetooth: hci0: sending frame failed (-49)