search

raspberrypi / linux

Kernel source tree for Raspberry Pi-provided kernel builds. Issues unrelated to the linux kernel should be posted on the community forum at https://forums.raspberrypi.com/
Other
11.1k stars 4.97k forks source link

Bluetooth connection drops randomly #2832

Open acolombier opened 5 years ago

acolombier commented 5 years ago

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

Logs

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

Thanks, @MilhouseVH.

acolombier commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

notare-alname commented 5 years ago

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

orclex commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

schornstephan commented 5 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

Does the reset work before the connection drops?

hajo62 commented 4 years ago

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 commented 4 years ago

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

pelwell commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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)
hajo62 commented 4 years ago

@pelwell : And tried again directly after reboot and after getting the first value from the sensor and got the same message as shown above...

rbauduin commented 4 years ago

I am experiencing the same problem with a raspberry pi zero W. @pelwell 's script had some effect: the pi reconnected and disconnected 3 times , but then stayed disconnected. (so it had some effect, but didn't get the system working again). Some additional info:

pi@wc:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2019-09-26
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 80d486687ea77d31fc3fc13cf3a2f8b464e129be, stage2
pi@wc:~ $ vcgencmd version
Sep 24 2019 17:37:19 
Copyright (c) 2012 Broadcom
version 6820edeee4ef3891b95fc01cf02a7abd7ca52f17 (clean) (release) (start)
pi@wc:~ $ uname -a
Linux wc 4.19.75+ #1270 Tue Sep 24 18:38:54 BST 2019 armv6l GNU/Linux
rbauduin commented 4 years ago

As only a reboot gets bluetooth working again, I thought I'd share how I automated things. I added this to a shell script started as a service on the my pi (it could also be added as a new service, similarly to what is done below for the btreboot service):

# USB_ADDR is the address of the usb peer of the form XX:XX:XX:XX:XX:XX
(while true; do hcitool lq $USB_ADDR &> /dev/null; sleep 1; done)&

This will trigger an error message in dmesg output, which I then monitor from a btreboot service. Systemd service:

[Unit]
Description=Reboot is we detect a bt error in dmesg

[Service]
Type=simple
ExecStart=/usr/local/bin/btreboot.sh

[Install]
WantedBy=multi-user.target

And the script called by the service:

#!/bin/bash
# reboot if bluetooth problem is detected in dmesg
dmesg -w | egrep "Bluetooth: hci0: command .* tx timeout" --line-buffered | while read l; do reboot; done

Hope this helps

ole1986 commented 4 years ago

Not to blame your script, but this can simply not the solution of restating the raspberry.

But thanks for the idea

rbauduin commented 4 years ago

Not to blame your script, but this can simply not the solution of restating the raspberry.

I agree with you it isn't meant to be the solution. But in the meantime, I needed a work-around and thought I'd share it. Looking forward to deploying a proper fix though!

gmazilla commented 4 years ago

Have the same problem as TS. Bluetooth stops working after about 30 minutes of audio streaming to BT headset BQ-618. dmseg says:

...
[   28.339907] Bluetooth: RFCOMM ver 1.11
[   28.349654] fuse init (API version 7.27)
[  111.670567] Bluetooth: HIDP (Human Interface Emulation) ver 1.2
[  111.670600] Bluetooth: HIDP socket layer initialized
[  111.677811] hid-generic 0005:099A:0500.0003: unknown main item tag 0x0
[  111.678192] input: Bluetooth Mouse as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:11/0005:099A:0500.0003/input/input4
[  111.678819] hid-generic 0005:099A:0500.0003: input,hidraw2: BLUETOOTH HID v1.1b Mouse [Bluetooth Mouse] on b8:27:eb:d9:46:15
[  300.389385] input: 37:3E:29:48:30:C5 as /devices/virtual/input/input5
[11614.292098] input: 37:3E:29:48:30:C5 as /devices/virtual/input/input6
[11622.631218] hid-generic 0005:05D6:000A.0004: unknown main item tag 0x0
[11622.631719] input: BQ-618 Consumer Control as /devices/platform/soc/3f201000.serial/tty/ttyAMA0/hci0/hci0:12/0005:05D6:000A.0004/input/input7
[11622.640898] hid-generic 0005:05D6:000A.0004: input,hidraw3: BLUETOOTH HID v2.40 Device [BQ-618] on b8:27:eb:d9:46:15
[11720.759024] input: 37:3E:29:48:30:C5 as /devices/virtual/input/input8
[12901.325100] Bluetooth: hci0: hardware error 0x00
[12905.900717] Bluetooth: hci0: command 0x1003 tx timeout
[12907.981199] Bluetooth: hci0: command 0x1001 tx timeout
[12910.061025] Bluetooth: hci0: command 0x1009 tx timeout
[13129.581699] Bluetooth: hci0: command 0x1003 tx timeout
[13131.661726] Bluetooth: hci0: command 0x1001 tx timeout
[13133.741732] Bluetooth: hci0: command 0x1009 tx timeout
[13401.345094] Bluetooth: hci0: command 0x1003 tx timeout
[13403.425298] Bluetooth: hci0: command 0x1001 tx timeout
[13405.505210] Bluetooth: hci0: command 0x1009 tx timeout

'bluetoothctl show' says BT is not powered. 'bluetoothctl power on' fails.

I have RPI3B+ Linux raspberrypi 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

samueleforconi commented 4 years ago

Hi, same problem here with a RPi 3B+, running Raspbian Lite (Stretch).

$ 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+-0156

$ 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

$ uname -a Linux raspberry-pi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

To debug the problem, I have disabled both hciuart.service and bluetooth.service from starting up at boot.

Then I login on the system and run: $ sudo /usr/bin/hciattach -n /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:78:11:21 bcm43xx_init Flash firmware /lib/firmware/brcm/BCM4345C0.hcd Set BDADDR UART: b8:27:eb:78:11:21 Set Controller UART speed to 3000000 bit/s Device setup complete

Then, I stop hciattach pressing CTRL+C and run: sudo /opt/vc/bin/vcmailbox 0x38041 8 8 128 0 ...wait for a few seconds, and run: sudo /opt/vc/bin/vcmailbox 0x38041 8 8 128 1 (these commands should perform an hw-reset of the bluetooth peripheral)

But then, if I try to restart the bluetooth interface: $ sudo /usr/bin/hciattach -n /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:78:11:21 bcm43xx_init Initialization timed out.

And the only way to recover the bluetooth interface is to reboot the Raspberry.

pelwell commented 4 years ago

A bug was found in the UART driver last week and fixed/worked around. The fix is in the kernel available by running "sudo rpi-update". Update to the new kernel and see Bluetooth is more stable.

N.B. The "fix" will have no effect on the ability to reset the modem should something go wrong (that still needs to be investigate), but it might avoid the need for the reset in the first place.

samueleforconi commented 4 years ago

Hi Phil, regarding bluetooth/uart stability, I have found problems only on RPi 3B v1.2 that doesn't have the flow control. In that device I set the uart baudrate to 460800 to minimize the probability of errors on uart (with the default baudrate set at 921600 I have experienced many hci errors). However, as we are using the RPi as a headless bluetooth receiver (that is expected to run for days/months/years...), a reset functionality will be strongly desired. Thanks for your help, I'll stay tuned for updates on this issue.

hajo62 commented 4 years ago

A bug was found in the UART driver last week and fixed/worked around. The fix is in the kernel available by running "sudo rpi-update". Update to the new kernel and see Bluetooth is more stable.

N.B. The "fix" will have no effect on the ability to reset the modem should something go wrong (that still needs to be investigate), but it might avoid the need for the reset in the first place.

I made the upgrade some days ago and unfortunately I had a connection drop after 1 day 22 hours. Second connection drop after 6 days 20h.

And now alive since 9 days 9 h.

Thanks for the patch. Much better than before!

pelwell commented 4 years ago

I've been following this up with Cypress, and they are confident that the reset pin should be working. Trying again I found that the second invocation of btreset worked, and this pattern seemed to be repeatable. The difference with the second run is that there is no hciattach process, which made me wonder if the asynchronous nature of killing hciattach was causing problems.

Try this modified version of the script:

sudo killall hciattach
sleep 2
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

Note the addition of the sleep 2 after the sudo killall hciattach. This extra delay has (in my testing) made the reset reliable.

samueleforconi commented 4 years ago

Hi Phil, I tried your script on a RPi3B+, but with no luck... can you tell me if I'm doing something wrong.

This is the hardware used for testing: pi@raspberrypi:/ $ cat /proc/cpuinfo ... Hardware : BCM2835 Revision : a020d3 ...

pi@raspberrypi:/ $ uname -a Linux raspberrypi 4.19.66-v7+ #1253 SMP Thu Aug 15 11:49:46 BST 2019 armv7l GNU/Linux

pi@raspberrypi:~ $ cat /etc/os-release PRETTY_NAME="Raspbian GNU/Linux 9 (stretch)" NAME="Raspbian GNU/Linux" VERSION_ID="9" VERSION="9 (stretch)" VERSION_CODENAME=stretch ID=raspbian ID_LIKE=debian HOME_URL="http://www.raspbian.org/" SUPPORT_URL="http://www.raspbian.org/RaspbianForums" BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs

Then this is the list of commands that I have run to test your script:

  1. Check running processes (that refers to the Bluetooth hardware): pi@raspberrypi:~ $ ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND ... root 445 0.0 0.0 1912 108 ? S 10:56 0:00 /usr/bin/hciattach /dev/serial1 bcm43xx 3000000 flow - b8:27:eb:de:2c:bd root 452 0.0 0.3 7596 3628 ? Ss 10:56 0:00 /usr/libexec/bluetooth/bluetoothd -E pi 1406 0.8 0.4 6268 4404 pts/0 Ss 10:57 0:00 -bash pi 1526 0.0 0.3 7740 2860 pts/0 R+ 10:57 0:00 ps aux

  2. Create the bluetoooth test reset script: pi@raspberrypi:~ $ cd /tmp/ pi@raspberrypi:/tmp $ sudo nano test-reset.sh pi@raspberrypi:/tmp $ cat test-reset.sh #!/bin/bash sudo killall hciattach sleep 2 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 pi@raspberrypi:/tmp $ sudo chmod 755 test-reset.sh

  3. Run the script: pi@raspberrypi:/tmp $ ./test-reset.sh 0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000 0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000 bcm43xx_init Failed to reset chip, command failure Can't initialize device: Success pi@raspberrypi:/tmp $

I'm doing something wrong? How are you checking the bluetooth reset functionality?

pelwell commented 4 years ago

I tested the script on a 4B, not a 3B+, but it should be the same circuitry around the 43455. Trying now I also see a failure to reset.

  1. I have had success with the following version, but it has the considerable disadvantage that it takes out the WiFi connection as well - it would just be good to get some confirmation that you see the same behaviour:

    sudo killall hciattach
sleep 2
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
/opt/vc/bin/vcmailbox 0x38041 8 8 129 0
sleep 1
/opt/vc/bin/vcmailbox 0x38041 8 8 129 1
sleep 1
/opt/vc/bin/vcmailbox 0x38041 8 8 128 1
fi
sleep 4
sudo btuart

  2. What is your use case on the 3B+ that requires a hard reset? It would be good to reproduce it here so I can forward it to Cypress.

  3. Can you try an HCI reset command instead?

    $ sudo hciconfig reset
pelwell commented 4 years ago

How are you checking the bluetooth reset functionality?

while true; do hcitool clock; sleep 2; done is a useful way to monitor the BT status. Not only does it show when the connection is lost, the Clock value (which is normally constantly incrementing) gets reset to zero when the device is reset.

samueleforconi commented 4 years ago

Hi Phil, I'll try to describe here as best as I can the tests that I have done.

I'm actually using the RPi as a headless BLE receiver. In the previous test, the OS was booted and my BLE receiver daemon was started (by systemd), then I killed it and tested your reset script (and I get the previously reported results).

Now, I have disabled the startup of my BLE receiver daemon, so the only Bluetooth-related processes that are running are hciattach and bluetoothd, and repeated the test.

Please note: each test has been done rebooting the RPi.

Test 1 - Only Bluetooth pin toggled. Script used:

sudo killall hciattach
sleep 2
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

Result of running test-reset script:

pi@raspberrypi:/tmp $ ./test-reset.sh
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
bcm43xx_init
Initialization timed out.

Test 2 - Both Wifi and Bluetooth pins toggled. Script used:

sudo killall hciattach
sleep 2
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
  /opt/vc/bin/vcmailbox 0x38041 8 8 129 0
  sleep 1
  /opt/vc/bin/vcmailbox 0x38041 8 8 129 1
  sleep 1
  /opt/vc/bin/vcmailbox 0x38041 8 8 128 1
fi
sleep 4
sudo btuart

Result of running test-reset script:

pi@raspberrypi:/tmp $ ./test-reset.sh
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
bcm43xx_init
Cannot open directory '/etc/firmware': No such file or directory
Patch not found, continue anyway
Set BDADDR UART: b8:27:eb:de:2c:bd
Set Controller UART speed to 3000000 bit/s
Device setup complete

Test 3 - Only Wifi pin toggled. Script used:

sudo killall hciattach
sleep 2
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 129 0
  sleep 1
  /opt/vc/bin/vcmailbox 0x38041 8 8 129 1
fi
sleep 4
sudo btuart

Result of running test-reset script:

pi@raspberrypi:/tmp $ ./test-reset.sh
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
bcm43xx_init
Cannot open directory '/etc/firmware': No such file or directory
Patch not found, continue anyway
Set BDADDR UART: b8:27:eb:de:2c:bd
Set Controller UART speed to 3000000 bit/s
Device setup complete

Test 4 - Re-enable BLE receiver daemo and toggle Wifi pin only. sudo systemctl enable ble-recvd.service sudo reboot

Script used:

sudo killall hciattach
sleep 2
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 129 0
  sleep 1
  /opt/vc/bin/vcmailbox 0x38041 8 8 129 1
fi
sleep 4
sudo btuart

Result of running test-reset script:

pi@raspberrypi:/tmp $ ./test-reset.sh
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000000 0x00000000
0x00000020 0x80000000 0x00038041 0x00000008 0x00000008 0x00000000 0x00000001 0x00000000
bcm43xx_init
Cannot open directory '/etc/firmware': No such file or directory
Patch not found, continue anyway
Set BDADDR UART: b8:27:eb:de:2c:bd
Set Controller UART speed to 3000000 bit/s
Device setup complete

It seems that toggling pin 129 works to perform the reset of the BLE module, while pin 128 does nothing (in my setup). I don't know the schematic of how these pins are connected, but are we sure that the reset pin of the BLE module is on 128? Let me know if I can perform some other tests to help understanding what's going on...

pelwell commented 4 years ago

I now have two different 3B+s, one of which resets as expected and one of which behaves exactly like yours.

Which build revision do you have (cat /proc/device-tree/model)?

samueleforconi commented 4 years ago 
$ cat /proc/device-tree/model
Raspberry Pi 3 Model B Plus Rev 1.3
$ cat /proc/cpuinfo
processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 1
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 2
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

processor       : 3
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Hardware        : BCM2835
Revision        : a020d3
Serial          : 0000000032748617
pelwell commented 4 years ago

After a bit of archaeology I can confirm that you have what could be called a rev 1.4 3B+, even though the OTP still marks it as a 1.3. The design had to be changed to accommodate a slightly changed 43455 part, and that forced the removal of the independent BT_ON signal (GPIO 0 on the expander, a.k.a. GPIO 128); it is wired to WL_ON (GPIO 1/129) instead.

Unfortunately this means that if you are using WiFi then you can't issue a hard reset to Bluetooth.

Can you try the "sudo hciconfig reset" command as an alternative to toggling BT_ON?

samueleforconi commented 4 years ago

Ok, I have understand. Regarding the software reset (hci command), it should work if the hci interface is up and running correctly. The problem is that on some RPis we get the hci interface completely stuck and checking dmesg we have these logs:

[205797.968484] Bluetooth: hci0: advertising data len corrected
[294998.085946] Bluetooth: hci0: advertising data len corrected
[704512.084701] Bluetooth: hci0: advertising data len corrected
[988104.776316] Bluetooth: hci0: advertising data len corrected
[1579091.893507] Bluetooth: hci0: advertising data len corrected
[2202761.890594] Bluetooth: hci0: advertising data len corrected
...
[2403905.221839] Bluetooth: hci0: Frame reassembly failed (-84)
[2403905.221941] Bluetooth: hci0: Frame reassembly failed (-84)
[2403905.222116] Bluetooth: hci0: Frame reassembly failed (-84)
[2403905.222290] Bluetooth: hci0: Frame reassembly failed (-84)
[2403905.222458] Bluetooth: hci0: Frame reassembly failed (-84)
[2403905.222655] Bluetooth: hci0: Frame reassembly failed (-84)
[2916857.093301] Bluetooth: hci0: advertising data len corrected

I don't know if these errors could cause the hci interface to stop working, but for this reason, I was looking for a hardware reset of the bluetooth module, because on these devices the hci interface is not working / not responsive anymore.

henzef commented 4 years ago

on my end the hciconfig reset does not fix the issue (even though it does not raise an error), but the reset via WL_ON pin works fine.