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.

[mminelli]

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]

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]

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]

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

[agungpambudi55]

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]

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]

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]

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]

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]

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]

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]

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]

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!

[wtangofoxtrot]

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)

[guma72]

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.

[sai-kiran-y]

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.

[Nicceboy]

Similar problem.

Bluetooth completely freezes after some hours.

The workload attempts to capture Bluetooth LE advertising packets of nearby devices and nothing else.

Versions:

uname -a
Linux raspberrypi 6.6.62+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.62-1+rpt1 (2024-11-25) aarch64 GNU/Linux

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

Kernel log might have something useful

[11816.559706] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[11816.559769] Mem abort info:
[11816.559784]   ESR = 0x0000000096000005
[11816.559802]   EC = 0x25: DABT (current EL), IL = 32 bits
[11816.559830]   SET = 0, FnV = 0
[11816.559847]   EA = 0, S1PTW = 0
[11816.559863]   FSC = 0x05: level 1 translation fault
[11816.559884] Data abort info:
[11816.559898]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[11816.559919]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[11816.559941]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[11816.559963] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000004400000
[11816.559989] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000
[11816.560038] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
[11816.560066] Modules linked in: rfcomm snd_seq_dummy snd_hrtimer snd_seq snd_seq_device cmac algif_hash aes_arm64 aes_generic algif_skcipher af_alg bnep brcmfmac_wcc binfmt_misc brcmfmac brcmutil hci_uart cfg80211 btbcm bluetooth bcm2835_codec(C) bcm2835_isp(C) bcm2835_v4l2(C) v4l2_mem2mem bcm2835_mmal_vchiq(C) videobuf2_vmalloc videobuf2_dma_contig ecdh_generic videobuf2_memops ecc videobuf2_v4l2 raspberrypi_hwmon rfkill videodev libaes i2c_bcm2835 videobuf2_common mc raspberrypi_gpiomem vc_sm_cma(C) snd_bcm2835(C) i2c_dev ledtrig_pattern fuse dm_mod ip_tables x_tables ipv6 vc4 snd_soc_hdmi_codec snd_soc_core snd_compress snd_pcm_dmaengine snd_pcm snd_timer snd drm_display_helper drm_dma_helper drm_kms_helper drm drm_panel_orientation_quirks backlight cec uio_pdrv_genirq uio
[11816.560591] CPU: 2 PID: 1250 Comm: kworker/u13:2 Tainted: G         C         6.6.62+rpt-rpi-v8 #1  Debian 1:6.6.62-1+rpt1
[11816.560636] Hardware name: Raspberry Pi 3 Model B Plus Rev 1.3 (DT)
[11816.560662] Workqueue: hci0 hci_rx_work [bluetooth]
[11816.560890] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[11816.560923] pc : eir_has_uuids+0x1a0/0x2b8 [bluetooth]
[11816.561117] lr : mgmt_device_found+0x440/0x718 [bluetooth]
[11816.561309] sp : ffffffc08113bab0
[11816.561327] x29: ffffffc08113bab0 x28: 00000000ffffffba x27: 0000000000000000
[11816.561371] x26: 0000000000000080 x25: 0000000000000001 x24: 000000000000007f
[11816.561413] x23: 0000000000000000 x22: 000000000000001e x21: ffffff8002517495
[11816.561455] x20: ffffff800251748e x19: ffffff80031b6000 x18: 0000000000000000
[11816.561498] x17: ffffffa06ceee000 x16: ffffffdfcdae6110 x15: 0000000000000000
[11816.561540] x14: 000000000000000c x13: ffffffdfcdd5cc38 x12: 00000000fdae8b7a
[11816.561582] x11: ffffff8002517497 x10: 0000000000000012 x9 : 0000000000000000
[11816.561623] x8 : 0000000000000011 x7 : 0000000000000010 x6 : 0000000000000020
[11816.561664] x5 : 6e400001b5a3f393 x4 : 0000000000000000 x3 : 0000000000000000
[11816.561705] x2 : 0000000000000001 x1 : 000000000000001e x0 : ffffff8002517495
[11816.561747] Call trace:
[11816.561765]  eir_has_uuids+0x1a0/0x2b8 [bluetooth]
[11816.561958]  mgmt_device_found+0x440/0x718 [bluetooth]
[11816.562154]  process_adv_report.part.0+0x1f4/0x658 [bluetooth]
[11816.562350]  hci_le_adv_report_evt+0x1b4/0x1d0 [bluetooth]
[11816.562540]  hci_le_meta_evt+0xbc/0x190 [bluetooth]
[11816.562730]  hci_event_packet+0x1b0/0x4f8 [bluetooth]
[11816.562923]  hci_rx_work+0xac/0x3d0 [bluetooth]
[11816.563113]  process_one_work+0x148/0x3b8
[11816.563147]  worker_thread+0x32c/0x450
[11816.563173]  kthread+0x11c/0x128
[11816.563207]  ret_from_fork+0x10/0x20
[11816.563244] Code: 14000004 91004084 eb07009f 54000180 (f9400085)
[11816.563273] ---[ end trace 0000000000000000 ]---

[suezz]

I also have bluetooth dropping on Pi4B, bnep0 tethering:

• Bluetooth connected to miniuart 921600 noflow,:
  no drop works ok

• Bluetooth connected to PL011 3000000 flow but also at 921600 noflow:
  random drop with hardware error 0x00, simple wget download seem more stable, browser traffic cause drop in few minute
  or second