rpi-distro / pi-bluetooth Goto Github PK
View Code? Open in Web Editor NEWLoads BCM43430A1 firmware on boot
Loads BCM43430A1 firmware on boot
Moving from #8 since it was closed.
09-06 RPI OS Lite x64 image with apt-update just after install:
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-09-23 21:21:56 CEST; 5s ago
Docs: man:bluetoothd(8)
Main PID: 1137 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4164)
CPU: 56ms
CGroup: /system.slice/bluetooth.service
└─1137 /usr/libexec/bluetooth/bluetoothd --noplugin=sap,wiimote,battery,deviceinfo,hostname,scanparam,autopair
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) wiimote
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) autopair
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) sap
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) scanparam
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) deviceinfo
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Excluding (cli) battery
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Bluetooth management interface 1.21 initialized
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Failed to set mode: Rejected (0x0b)
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Failed to set mode: Rejected (0x0b)
Sep 23 21:21:56 raspberrypi bluetoothd[1137]: Failed to set privacy: Rejected (0x0b)
This persists on service restart (i.e. different than previous issue)
After installing bluez 5.63 as mentioned here #8 (comment)
● bluetooth.service - Bluetooth service
Loaded: loaded (/lib/systemd/system/bluetooth.service; enabled; vendor preset: enabled)
Active: active (running) since Fri 2022-09-23 21:41:42 CEST; 1s ago
Docs: man:bluetoothd(8)
Main PID: 769 (bluetoothd)
Status: "Running"
Tasks: 1 (limit: 4164)
CPU: 32ms
CGroup: /system.slice/bluetooth.service
└─769 /usr/libexec/bluetooth/bluetoothd
Sep 23 21:41:42 raspberrypi systemd[1]: Starting Bluetooth service...
Sep 23 21:41:42 raspberrypi bluetoothd[769]: Bluetooth daemon 5.63
Sep 23 21:41:42 raspberrypi bluetoothd[769]: src/main.c:check_config() Unknown group Controller in /etc/bluetooth/main.conf
Sep 23 21:41:42 raspberrypi systemd[1]: Started Bluetooth service.
Sep 23 21:41:42 raspberrypi bluetoothd[769]: Bluetooth management interface 1.21 initialized
Sep 23 21:41:42 raspberrypi bluetoothd[769]: Failed to set mode: Rejected (0x0b)
Sep 23 21:41:42 raspberrypi bluetoothd[769]: Failed to set mode: Rejected (0x0b)
Sep 23 21:41:42 raspberrypi bluetoothd[769]: Failed to set privacy: Rejected (0x0b)
Anyone having same error when full-upgrading Twister OS?
Job for hciuart.service failed because the control process exited with error code.
See "systemctl status hciuart.service" and "journalctl -xe" for details.
I get it back when command systemctl restart hciuart.service but everytime I restart it, is the same story.
I don't know if it's driver related, perhaps not since the old check \s(B8:27:EB:|DC:A6:32:)'
worked, the address on the bluetooth device isn't set on the CM4 IO Board, stays AA:AA:AA:AA:AA:AA.
Switching the check in bthelper to include this case seems to work fine:
if ( /usr/bin/hcitool -i $dev dev | grep -q -E '\s43:4[35]:|AA:AA:AA:AA:AA:AA' ); then
Is there maybe a better approach?
Thank you
Hi,
i'm trying to do a snap for Ubuntu Core 20.04.3 that must run on a Raspberry Pi 4 Model B. This snap is based on a python script that use the python library 'bleak'. When i run the snap on Ubuntu desktop there isn't problem. The problem is when i try to run the snap on Ubuntu Core 20.04 because there is the following error:
OSError: [Errno 8] Exec format error: 'bluetoothctl'.
I understood that to use the bluetooth on Ubuntu Core with the Raspberry Pi i must use the pi-bluetooth snap, but i don't know how to use this with my snap. More precisely, I don't know how to make my snap in such a way as to be able to use bluetooth on the Raspberry Pi.
This is my current snapcraft file to realize the snap:
name: iot-band
base: core20
version: '1.0'
summary: Iot band app
description: |
Iot band app
grade: devel
confinement: devmode
architectures:
- build-on: amd64
run-on: arm64
apps:
iot-band:
environment:
PYTHONPATH: $SNAP/lib/python3.8/site-packages/iot-band
command: bin/iot_band.py
plugs:
- bluez
parts:
iot-band:
# See 'snapcraft plugins'
source: .
plugin: python
python-packages:
- .
bluez:
plugin: nil
stage-snaps: [bluez]
How can i realize correctly the snap (using the "snap pi-bluetooth") to resolve this problem with the bluetooth?
When purging the pi-bluetooth
package, the hciuart.service
(hciattach
process) is still running:
# systemctl is-active hciuart
active
debhelper seems to add a block to remove the service, but it doesn't seem to imply stopping it:
# Automatically added by dh_installsystemd/13.3.4
if [ "$1" = "remove" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper mask 'hciuart.service' >/dev/null || true
fi
fi
if [ "$1" = "purge" ]; then
if [ -x "/usr/bin/deb-systemd-helper" ]; then
deb-systemd-helper purge 'hciuart.service' >/dev/null || true
deb-systemd-helper unmask 'hciuart.service' >/dev/null || true
fi
fi
# End automatically added section
Usually it doesn't cause issues, but in some scripting scenarios it does, and I think it is expected that a service which does not exist on the system anymore is not continued to run.
How about adding some release tags or branches?
With release tags/branch, we do not need to remember the commit id when including this library.
On Pi 4b running Ubuntu 21.04 and pi-bluetooth/hirsute,now 0.1.15ubuntu2 arm64 the following warnings appear at boot:
systemd-udevd[976]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:14 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 58: invalid substitution type), ignoring, but please fix it.
systemd-udevd[976]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:27 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if [ -e /dev/ttyAMA0 ]; then exit 1; elif cmp -s $ALIASES/uart0 $ALIASES/serial0; then echo 0;elif cmp -s $ALIASES/uart0 $ALIASES/serial1; then echo 1; else exit 1; fi'" for PROGRAM (char 97: invalid substitution type), ignoring, but please fix it.
systemd-udevd[976]: /usr/lib/udev/rules.d/90-pi-bluetooth.rules:38 Invalid value "/bin/sh -c 'ALIASES=/proc/device-tree/aliases; if cmp -s $ALIASES/uart1 $ALIASES/serial0; then echo 0; elif cmp -s $ALIASES/uart1 $ALIASES/serial1; then echo 1; else exit 1; fi '" for PROGRAM (char 58: invalid substitution type), ignoring, but please fix it.
You have made changes for Raspberry Pi 4?
If you have an USB adapter connected to pi then after restart the integrated (UART) Bluetooth adapter is not initiated.
The bug was introduced in revision 0.1.14 , most likely this commit 294a534
Tested on pi 3 and 4 with three different vendor CSR 4.0 USB Bluetooth adapters.
More details here: https://www.raspberrypi.org/forums/viewtopic.php?f=28&t=282948
I was trying to pinpoint the exact line causing trouble but had to give up and leave it to professionals.
The workaround I've suggested is to downgrade to 1.1.13 until a fix is released.
The steps are:
wget https://archive.raspberrypi.org/debian/pool/main/p/pi-bluetooth/pi-bluetooth_0.1.13_all.deb
sudo dpkg -i pi-bluetooth_0.1.13_all.deb
echo "pi-bluetooth hold" | sudo dpkg --set-selections
sudo reboot
If it gets fixed in 0.1.16 or later than to unlock upgrades you would need to run:
echo "pi-bluetooth install" | sudo dpkg --set-selections
I've tested it manually, simply btuart doesn't fork. It starts, works, stops.
The systemd service should be of type simple, not forking.
Newer (upstream) kernels have the ability to manage the uart connection and load firmware themselves, without a need for the hciattach daemon.
However when using such kernel with Raspbian it currently takes a minute or two before bluetooth works.
This is because your hciuart service is waiting a long time for dev-serial1
to appear (which never will, as device is claimed by kernel), before eventually timing out.
Since you have Before=bluetooth.service
that prevents startup of bluetoothd during that time.
It would be nice if hciuart didn't hold off starting up bluetoothd.
Isn't it capable of dealing with hci devices appearing later?
Sorry but, another bug for you :D
/usr/bin/bthelper: 19: /usr/bin/bdaddr: not found
There isn't any bdaddr :D
Should it be provided by the package, or use another tool?
https://packages.debian.org/search?searchon=contents&keywords=bdaddr&mode=path&suite=stable&arch=any it's empty :D
...
Since upgrading from 0.1.15 to 0.1.16, I cannot get Bluetooth to work anymore. I am not sure about the exact details, but pi-bluetooth is the only package that was recently updated. Sadly, I cannot downgrade, because 0.1.15 is no longer in the repository.
In /var/log/apt/history.log:
Start-Date: 2021-05-19 02:35:08
Commandline: /usr/bin/unattended-upgrade
Upgrade: pi-bluetooth:armhf (0.1.15, 0.1.16)
End-Date: 2021-05-19 02:36:16
hciuart status
$ sudo systemctl status hciuart.service
● hciuart.service - Configure Bluetooth Modems connected by UART
Loaded: loaded (/lib/systemd/system/hciuart.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2021-05-20 01:19:36 CEST; 19min ago
Process: 18328 ExecStart=/usr/bin/btuart (code=exited, status=1/FAILURE)
May 20 01:19:06 hassio systemd[1]: Starting Configure Bluetooth Modems connected by UART...
May 20 01:19:36 hassio btuart[18328]: Initialization timed out.
May 20 01:19:36 hassio btuart[18328]: bcm43xx_init
May 20 01:19:36 hassio systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
May 20 01:19:36 hassio systemd[1]: hciuart.service: Failed with result 'exit-code'.
May 20 01:19:36 hassio systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
journalctl -xe after restarting hciuart
May 20 01:16:18 hassio btuart[17931]: Initialization timed out.
May 20 01:16:18 hassio btuart[17931]: bcm43xx_init
May 20 01:16:18 hassio systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit hciuart.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
May 20 01:16:18 hassio systemd[1]: hciuart.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit hciuart.service has entered the 'failed' state with result 'exit-code'.
May 20 01:16:18 hassio systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
-- Subject: A start job for unit hciuart.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit hciuart.service has finished with a failure.
--
-- The job identifier is 90699 and the job result is failed.
Manually trying to connect a device:
$ sudo hciattach /dev/ttyAMA0 bcm43xx 921600 noflow
bcm43xx_init
Initialization timed out.
After upgrading from 0.8 to 0.9, I can no longer connect to a BLE-based medical device (the BLE Connect or Pair operation times out with no response). The problem is still there with version 0.10.
If I do "systemctl restart bluetooth" some time after the system has already booted, it then works. I haven't determined how soon I can do this (in rc.local for example); so far it's been after the system comes up, I ssh in, and run that command from the command line.
So there's something related to the timing or initialization of the bluetooth service that's the issue. The BLE connection attempts after the Pi comes up are failing until I restart bluetooth, and then they all succeed.
Basic BT commands like discovery do work as soon as the system boots, just not the BLE connection ones that I'm using (Connect and Pair, I think).
If there's a particular kind of logging or sniffing I can capture to help debug this, please let me know.
I'm not entirely sure this is a direct pi-blutooth bug, so I apologize if this isn't the right project, but beginning with 0.1.16 release on raspberry pi 3 with rasbain/Buster, on pi-bluetooth upgrade I now get the following failures noted in the terminal:
Job for hciuart.service failed because the control process exited with error code.
See "systemctl status hciuart.service" and "journalctl -xe" for details.
Checking the journal related to hciuart, I see:
May 21 00:24:54 raspberryz systemd[1]: hciuart.service: Dependency Before=bluetooth.device ignored (.device units cannot be delayed)
May 21 00:24:56 raspberryz systemd[1]: hciuart.service: Dependency Before=bluetooth.device ignored (.device units cannot be delayed)
May 21 19:05:16 raspberryz systemd[1]: Stopping Configure Bluetooth Modems connected by UART...
May 21 19:05:18 raspberryz systemd[1]: hciuart.service: Succeeded.
May 21 19:05:18 raspberryz systemd[1]: Stopped Configure Bluetooth Modems connected by UART.
May 21 19:05:18 raspberryz systemd[1]: Starting Configure Bluetooth Modems connected by UART...
May 21 19:05:48 raspberryz btuart[12649]: Initialization timed out.
May 21 19:05:48 raspberryz btuart[12649]: bcm43xx_init
May 21 19:05:48 raspberryz systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
May 21 19:05:48 raspberryz systemd[1]: hciuart.service: Failed with result 'exit-code'.
May 21 19:05:48 raspberryz systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
May 21 19:05:49 raspberryz systemd[1]: Starting Configure Bluetooth Modems connected by UART...
May 21 19:06:19 raspberryz btuart[12700]: Initialization timed out.
May 21 19:06:19 raspberryz btuart[12700]: bcm43xx_init
May 21 19:06:19 raspberryz systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
May 21 19:06:19 raspberryz systemd[1]: hciuart.service: Failed with result 'exit-code'.
May 21 19:06:19 raspberryz systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
I have 2 raspberry Pi 3 (one 3+) with the Pi 3 being flawless (no errors at all) since Jessie was installed, and the 3+ flawless since the original Buster install. The only additional packages installed in recent history were:
gpsd gpsd-clients libbluetooth3 libgps-dev libgps23 python-gps
So bottom line. Now, hciuart
fails on pi-bluetooth
update (or start on boot, etc..). I have searched and there are some threads that claim the errors are harmless and should be ignored, but they were not present earlier. So I am submitting here. If this isn't the correct location, just let me know. Also, If you need additional information or details, let me know and I'll be happy to get it for you.
I am occasionally finding that on boot the hciuart service does not start. I get these errors:
Initialization timed out.
bcm43xx_init
Seems to be the same issue as #25
Is there a fix for this?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.