Bluetooth connection drops randomly #2832

acolombier · 2019-01-27T19:13:28Z

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.

The text was updated successfully, but these errors were encountered:

pelwell · 2019-01-27T20:36:28Z

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?

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

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

Copy in the new version:

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

Reboot.

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

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

MilhouseVH · 2019-01-27T21:00:07Z

@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 · 2019-01-27T21:05:04Z

Thanks, @MilhouseVH.

acolombier · 2019-01-27T22:47:41Z

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 · 2019-02-01T07:53:42Z

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 · 2019-02-01T11:30:49Z

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 · 2019-07-05T06:26:19Z

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 · 2019-07-21T02:46:38Z

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 · 2019-07-21T15:32:35Z

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 · 2019-09-19T13:33:22Z

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

notare-alname · 2019-09-19T23:57:12Z

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

orclex · 2019-09-23T07:22:04Z

@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 · 2019-10-07T11:10:00Z

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 · 2019-10-18T01:07:33Z

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 · 2019-10-18T05:49:26Z

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

schornstephan · 2019-10-18T11:06:45Z

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 · 2019-10-23T17:28:53Z

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 · 2019-11-05T12:55:21Z

@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 · 2019-11-07T20:42:57Z

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 · 2019-11-07T20:47:54Z

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 · 2019-11-07T20:58:29Z

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 · 2019-11-07T21:08:14Z

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 · 2019-11-07T21:11:05Z

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 · 2019-11-07T21:22:00Z

Does the reset work before the connection drops?

hajo62 · 2019-11-07T21:24:26Z

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 · 2019-11-07T21:29:50Z

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

pelwell · 2019-11-07T21:36:23Z

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.

henzef · 2020-03-11T15:49:29Z

which fix are you refering to? I can't find a related change in Hexxeh/rpi-firmware@0dfefdc

pelwell · 2020-03-11T15:52:45Z

The fix is:

kernel: tty: amba-pl011: Avoid rare write-when-full error
See: raspberrypi/firmware#1150

in Hexxeh/rpi-firmware@1526192, i.e. the one before 4.19.102.

mminelli · 2020-03-29T12:53:28Z

Same thing happens to me on osmc with RPi3.
Here is some information about my system:

$ uname -a
Linux osmc 4.19.55-6-osmc #1 SMP PREEMPT Sun Nov 3 22:15:28 UTC 2019 armv7l GNU/Linux

$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Plus Rev 1.3

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

Any idea would be much appreciated.

pelwell · 2020-03-30T13:13:35Z

I think there is a BT/WiFi coexistence problem with the new firmware. You can track the issue here: RPi-Distro/firmware-nonfree#8

mminelli · 2020-03-30T14:43:11Z

Thanks for the reply @pelwell. In my case, the wifi adapter is off, but it should be said that I'm using OSMC distribution (for Kodi), and it's not on the latest version of the packages, including bluez. Perhaps Arch for ARM would help because it has more recent packages. I will give it a try in the coming days and report back.

mminelli · 2020-04-04T17:31:27Z

I can confirm that it's working fine with Arch ARM on a Raspberry Pi 3 and Kodi + Pulseaudio.

agungpambudi55 · 2020-06-06T20:11:44Z

After reading the issue here, I tried to conclude, and it worked for me. I have tested many times the results are satisfactory compared to restarting a PC or mini-PC. The problem is solved by creating a program file to check the bluetooth status so when the status is DOWN INIT RUNNING it will automatically reset the bluetooth firmware.

https://github.com/agungpambudi55/bluetooth-down-init-running

mgrey · 2021-03-10T10:46:41Z

Any updates here?
Same issue with Pi4 with 5.10.17-v7l+ #1403 with latest bluez-firmware (1.2-4+rpt8)
hcitool dev empty, frequent after reboot at least.
Mar 10 10:39:37 mypi kernel: [ 303.197340] Bluetooth: hci0: hardware error 0x00
Mar 10 10:39:39 mypi kernel: [ 305.277321] Bluetooth: hci0: command 0x1003 tx timeout
Mar 10 10:39:41 mypi kernel: [ 307.357358] Bluetooth: hci0: command 0x1001 tx timeout
Mar 10 10:39:43 mypi kernel: [ 309.437386] Bluetooth: hci0: command 0x1009 tx timeout
Mar 10 10:39:47 mypi kernel: [ 313.437509] Bluetooth: hci0: hardware error 0x00
@agungpambudi55 script works to reset
I'm just using bluetooth as a passive listener

bjo81 · 2021-11-05T22:11:44Z

I can confirm that it's working fine with Arch ARM on a Raspberry Pi 3 and Kodi + Pulseaudio.

Nice to hear, do you use armv7h or aarch64? I'm getting the issues with 5.15 on aarch64 and pulseaudio, only rebooting helps :/

pelwell · 2021-11-08T13:40:44Z

How flaky is the Bluetooth connection? And on which Pi (tail -3 /proc/cpuinfo)? I've had a 4B running for hours on the 64-bit kernel, but early Pi 3Bs are lacking the flow control signals necessary to avoid dropping Bluetooth data under load.

bjo81 · 2021-11-08T13:53:38Z

I've switched from aarch64 mainline to the rpi4-aarch64-kernel on a Pi 3B 1.2 and it works fine now (except under high load).

pelwell · 2021-11-08T14:15:24Z

A downstream patch that was present in rpi-5.10.y to avoid UART FIFO overflow is not in rpi-5.15.y, but I believe the patch is no longer necessary because of a change to the usage of the port spinlock.

mminelli · 2021-11-16T19:54:46Z

Sorry for the late reply: my system is a Pi3 B with

$ uname -a
Linux alarmpi 5.10.79-1-raspberrypi-ARCH #1 SMP Mon Nov 15 21:41:38 UTC 2021 armv7l GNU/Linux

$ pacman -Q | grep blue
bluez 5.62-1
bluez-libs 5.62-1
bluez-tools 0.2.0-5
bluez-utils-compat 5.54-1
pulseaudio-bluetooth 15.0-1
python-pybluez 0.23-2

I don't really use it that often via bluetooth, but haven't noticed any "flakiness".

dontech · 2022-04-20T21:05:37Z

Hello all,

I have been using the nice "btreset" script extensively to get around some annoying drops and other problems.

However, now i have a Raspberry PI Zero 2 W which is not covered by the recovery script, and does not work.

Does anyone know how to update the script to cover this?

How was the original pin numbers extracted (and the VCIO address)?

dontech · 2022-04-20T22:07:25Z

OK figured it out for RPI Zero 2 W:

The reset line is still connected via direct GPIO, but its moved from GPIO45->GPIO42

so its:

raspi-gpio set 42 op dl
sleep 1
raspi-gpio set 42 op dh

Now it works!

Workaround for bt_hci timeout. Information from following links : raspberrypi/linux#2832 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/vcmailbox/vcmailbox.c libbt changes are suggested by Lidong Zhou <[email protected]> Change-Id: Ic67eed2d60d9bea23323bbe82f824ea3afc4e674

wtangofoxtrot · 2022-11-06T19:16:07Z

running the 5.15.61-v7l+ kernel and seeing this issue on several pi 3/4s that i use for BLE/BT tracking around the house (mKeRix/room-assistant#1158). Only recourse so far has been to reboot the pi when hci0 goes away

pi@pi-office:~ $ hcitool dev
Devices:
pi@pi-office:~ $ hciconfig hci0 down
pi@pi-office:~ $ hciconfig hci0 up
Can't init device hci0: Connection timed out (110)

Workaround for bt_hci timeout. Information from following links : raspberrypi/linux#2832 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/vcmailbox/vcmailbox.c libbt changes are suggested by Lidong Zhou <[email protected]> Change-Id: Ic67eed2d60d9bea23323bbe82f824ea3afc4e674

Workaround for bt_hci timeout. Information from following links : raspberrypi/linux#2832 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/vcmailbox/vcmailbox.c libbt changes are suggested by Lidong Zhou <[email protected]> Change-Id: Ic67eed2d60d9bea23323bbe82f824ea3afc4e674 Signed-off-by: Michał Gapiński <[email protected]>

Workaround for bt_hci timeout. Information from following links : raspberrypi/linux#2832 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/vcmailbox/vcmailbox.c libbt changes are suggested by Lidong Zhou <[email protected]> Change-Id: Ic67eed2d60d9bea23323bbe82f824ea3afc4e674

guma72 · 2024-01-16T15:49:50Z

I still have a similar issue on Pi 4b.

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 6.1.0-rpi7-rpi-v8 #1 SMP PREEMPT Debian 1:6.1.63-1+rpt1 (2023-11-24) aarch64 GNU/Linux

pi@raspberrypi:~ $ cat /proc/device-tree/model
Raspberry Pi 4 Model B Rev 1.1

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

None of the proposed ways of resetting works for me - reboot is needed. The connection drops after few minutes to few hours.

Workaround for bt_hci timeout. Information from following links : raspberrypi/linux#2832 https://github.com/raspberrypi/userland/blob/master/host_applications/linux/apps/vcmailbox/vcmailbox.c libbt changes are suggested by Lidong Zhou <[email protected]> Change-Id: Ic67eed2d60d9bea23323bbe82f824ea3afc4e674

sai-kiran-y · 2024-09-02T08:36:02Z

Hi,

Did anyone find the reason for the hardware error 0x00 and any possible work around, for the same? I am randomly facing this issue, on another BLE module though.

Thanks,
Sai Kiran.

JamesH65 added the Bluetooth Issue pelwell_there_is_no_escape label Sep 19, 2019

JamesH65 added the Waiting for external input Waiting for a comment from the originator of the issue, or a collaborator. label Sep 19, 2019

JamesH65 removed the Waiting for external input Waiting for a comment from the originator of the issue, or a collaborator. label Nov 5, 2019

mart1nro mentioned this issue Mar 17, 2020

Raspberry Pi 3B randomly stops the script without error message mart1nro/joycontrol#5

Closed

ebisbe mentioned this issue Aug 6, 2020

Connection Lost? mart1nro/joycontrol#66

Open

Bluetooth connection drops randomly #2832

Bluetooth connection drops randomly #2832

Comments

acolombier commented Jan 27, 2019

pelwell commented Jan 27, 2019

MilhouseVH commented Jan 27, 2019

pelwell commented Jan 27, 2019

acolombier commented Jan 27, 2019

acolombier commented Feb 1, 2019

pelwell commented Feb 1, 2019

orclex commented Jul 5, 2019 • edited Loading

iczero commented Jul 21, 2019

pelwell commented Jul 21, 2019

JamesH65 commented Sep 19, 2019

notare-alname commented Sep 19, 2019

orclex commented Sep 23, 2019

rixwoodling commented Oct 7, 2019

schornstephan commented Oct 18, 2019

orclex commented Oct 18, 2019

schornstephan commented Oct 18, 2019

ole1986 commented Oct 23, 2019 • edited Loading

schornstephan commented Nov 5, 2019

hajo62 commented Nov 7, 2019 • edited Loading

pelwell commented Nov 7, 2019

hajo62 commented Nov 7, 2019

pelwell commented Nov 7, 2019

hajo62 commented Nov 7, 2019 • edited Loading

pelwell commented Nov 7, 2019

hajo62 commented Nov 7, 2019

pelwell commented Nov 7, 2019

pelwell commented Nov 7, 2019

henzef commented Mar 11, 2020

pelwell commented Mar 11, 2020

mminelli commented Mar 29, 2020 • edited Loading

pelwell commented Mar 30, 2020

mminelli commented Mar 30, 2020

mminelli commented Apr 4, 2020

agungpambudi55 commented Jun 6, 2020 • edited Loading

mgrey commented Mar 10, 2021

bjo81 commented Nov 5, 2021 • edited Loading

pelwell commented Nov 8, 2021

bjo81 commented Nov 8, 2021 • edited Loading

pelwell commented Nov 8, 2021

mminelli commented Nov 16, 2021 • edited Loading

dontech commented Apr 20, 2022

dontech commented Apr 20, 2022

wtangofoxtrot commented Nov 6, 2022

guma72 commented Jan 16, 2024

sai-kiran-y commented Sep 2, 2024

orclex commented Jul 5, 2019 •

edited

Loading

ole1986 commented Oct 23, 2019 •

edited

Loading

hajo62 commented Nov 7, 2019 •

edited

Loading

hajo62 commented Nov 7, 2019 •

edited

Loading

mminelli commented Mar 29, 2020 •

edited

Loading

agungpambudi55 commented Jun 6, 2020 •

edited

Loading

bjo81 commented Nov 5, 2021 •

edited

Loading

bjo81 commented Nov 8, 2021 •

edited

Loading

mminelli commented Nov 16, 2021 •

edited

Loading