Ubuntu Xenial isn’t an officially supported operating system for the Raspberry Pi, but there are images available for both the Pi 2 and Pi 3 in Trusty and Xenial versions. I’ve found the Xenial image works quite well, but as I recently discovered the Bluetooth chip that is present on the Pi 3 isn’t detected at all out of the box. Getting it working turned out to be a bit of a mission.
The short version
- Add my personal apt repo to your system
- Install the
sudo service hciuart start1
hcitool dev, and make sure the MAC reported looks plausible
Bluetooth on the Pi 3 is provided by a Broadcom BCM43438 - the same chip that provides the WiFi connection - which supports Bluetooth 4.1 as well as BTLE. I’m not sure why the WiFi component of this chip work out of the box but the Bluetooth parts don’t. The Bluetooth component connects to the host system over UART. At power on, the Bluetooth component just waits for the host system to write a firmware blob over the UART. Once it has its firmware, the Bluetooth chip can start up and begin processing commands.
There are a few components needed to make this work:
- Firmware blob
- Tool to write firmware into chip memory
- Tool to translate commands over UART
- Service to make this all happen automatically
a binary firmware blob for this chip in the form of a file called
. I have built a Debian package
pi-firmware-bt that installs this file into
/lib/firmware/brcm where it can be found by
BlueZ provides a tool to do both the ‘write firmware’ and ‘connect to device over UART’ called
hciattach. Unfortunately, the version that ships with Ubuntu doesn’t work very reliably on the Pi 3. The patches I’m using I found in the Yocto project layer for the Pi, but seem to originate with the Pi foundation itself. The package I’m building is
hciattach-rpi3 which just contains the patched
hciattach-rpi3 so it doesn’t conflict with the ‘real’ BlueZ package.
One gotcha with
hciattach is that it will attempt to start the device even if it can’t find a firmware blob to load. In this case, you will end up with a device visible when you run
hcitool dev, but the MAC address will be shown as
AA:AA:AA:AA:AA:AA and commands sent to the device will time out.
hciattach doesn’t always reset the device correctly when it stops, in this case trying to start
hciattach again will usually succeed.
hciattach needs to be running in the background to use the device. The command that needs to be run is
/usr/bin/hciattach-rpi3 /dev/ttyAMA0 bcm43xx 921600 noflow -. I’ve packaged a SystemD unit file that runs this command as appropriate as
pi-bluetooth. This package also depends on the
- It may take a couple of tries to start the service successfully
- Under a somewhat restrictive licence
c0fff507841e02396c981174c546046d9c80cf04. As far as I can tell, this is the only version of the firmware available