Hciuart service fails to start

I have a Raspberry Pi 4 Model B (4Gb) with a Packom M-Bus Master Hat running the latest EmonSD.

The M-Bus Master Hat is using /dev/serial0 and can access the M-Bus.

pi@emonpi:~ $ ls -la /dev/{tty{ACM,AMA,S,USB},serial}* 2>/dev/null
lrwxrwxrwx 1 root root          7 Sep 21 14:46  /dev/serial0 -> ttyAMA0
lrwxrwxrwx 1 root root          5 Sep 21 14:46  /dev/serial1 -> ttyS0
crw-rw---- 1 root dialout 204, 64 Sep 21 15:34  /dev/ttyAMA0
crw-rw---- 1 root dialout   4, 64 Sep 21 14:46  /dev/ttyS0
pi@emonpi:~ $

There are some RuuviTag Bluetooth Sensors which I would like to access using /dev/serial1.

A problem I encountered was this line in /lib/systemd/system/hciuart.service

ConditionFileNotEmpty=/proc/device-tree/soc/gpio@7e200000/bt_pins/brcm,pins

The referenced file is empty and the hciuart service fails to start. I have tried removing the failing condition check and attempting to start hciuart manually.

pi@emonpi:~ $ sudo systemctl start hciuart
Job for hciuart.service failed because the control process exited with error code.
See "systemctl status hciuart.service" and "journalctl -xe" for details.
pi@emonpi:~ $ 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 2023-09-21 15:48:10 BST; 21s ago
    Process: 1532 ExecStart=/usr/bin/btuart (code=exited, status=1/FAILURE)
        CPU: 29ms

Sep 21 15:47:40 emonpi systemd[1]: Starting Configure Bluetooth Modems connected by UART...
Sep 21 15:48:10 emonpi btuart[1539]: Initialization timed out.
Sep 21 15:48:10 emonpi btuart[1539]: bcm43xx_init
Sep 21 15:48:10 emonpi systemd[1]: hciuart.service: Control process exited, code=exited, status=1/FAILURE
Sep 21 15:48:10 emonpi systemd[1]: hciuart.service: Failed with result 'exit-code'.
Sep 21 15:48:10 emonpi systemd[1]: Failed to start Configure Bluetooth Modems connected by UART.
pi@emonpi:~ $

Has anyone managed to get further with Bluetooth on the miniuart?

Tried replacing dtoverlay=miniuart-bt with dtoverlay=miniuart-bt,krnbt=on in /boot/config.txt.

pi@emonpi:~ $ dmesg | grep -i blue
[    6.451114] Bluetooth: Core ver 2.22
[    6.455599] NET: Registered PF_BLUETOOTH protocol family
[    6.455623] Bluetooth: HCI device and connection manager initialized
[    6.455653] Bluetooth: HCI socket layer initialized
[    6.455673] Bluetooth: L2CAP socket layer initialized
[    6.455733] Bluetooth: SCO socket layer initialized
[    6.566068] Bluetooth: HCI UART driver ver 2.3
[    6.566102] Bluetooth: HCI UART protocol H4 registered
[    6.567089] Bluetooth: HCI UART protocol Three-wire (H5) registered
[    6.656512] Bluetooth: HCI UART protocol Broadcom registered
[    8.895014] Bluetooth: hci0: command 0xfc18 tx timeout
[   10.450794] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   10.450816] Bluetooth: BNEP filters: protocol multicast
[   10.450831] Bluetooth: BNEP socket layer initialized
[   17.118975] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   17.119009] Bluetooth: hci0: Failed to set baudrate
[   19.134936] Bluetooth: hci0: command 0x0c03 tx timeout
[   27.358941] Bluetooth: hci0: BCM: Reset failed (-110)
pi@emonpi:~

Any other suggestions?

I moved this to a new thread as the one it was on was several years old and things have changed wrt the Base OS etc.

You may find a broader community might be able to help (Stack exchange or the RPi forums).

[edit]
Does it work with a raw RPi OS image?

Thanks for moving it. I have searched quite widely for “Pi 4 mini-uart Bluetooth” but have not found a definitive answer. Not sure if it is relevant but the target system is an early revision Pi 4 (4GB):

pi@emonpi:~ $ cat /proc/cpuinfo
[...]
Hardware	: BCM2835
Revision	: c03111
Serial		: 100000003de10cda
Model		: Raspberry Pi 4 Model B Rev 1.1
pi@emonpi:~ $ 

Unfortunately, I am interacting with the Pi 4 remotely over SSH which makes it difficult to try a raw RPi OS image (I have a Rev 1.5 (8Gb) at home but it is rather busy running Home Assistant).

1 Like

Hi John,

Have you seen this?

1 Like

Thanks, @Bill.Thomson. I had not see it but I don’t think it gets me any closer to a solution.

[email protected] is disabled. /boot/cmdline.txt contains the following:

console=tty1 root=PARTUUID=99623c50-02 rootfstype=ext4 fsck.repair=yes rootwait

and the end of /boot/config.txt is:

[pi4]
# Run as fast as firmware / board allows
# arm_boost=1
core_freq=250
core_freq_min=250

[all]
dtoverlay=w1-gpio
dtoverlay=disable-bt
enable_uart=1
dtoverlay=miniuart-bt

I have commented out arm_boost=1 because it isn’t relevant to Raspberry Pi 4 Model B Rev 1.1 (I suspect it would be ignored anyway).

In Raspberry Pi Documentation: Configuration I have seen that core_freq=250 (and core_freq_min=250?) is required to enable the mini UART. Although the same document states enable_uart=1 implies core_freq=250 (unless force_turbo=1).

There is a M-Bus Master Hat which is working fine on the primary UART /dev/ttyAMA0 (/dev/serial0). I am trying to use the mini UART /dev/ttyS0 (/dev/serial1) to connect the Bluetooth devices.

Went back to replacing dtoverlay=miniuart-bt with dtoverlay=miniuart-bt,krnbt=on in /boot/config.txt.

This at least seems to see hci0:

pi@emonpi:~ $ dmesg | grep hci0
[    8.159278] Bluetooth: hci0: command 0xfc18 tx timeout
[   16.351298] Bluetooth: hci0: BCM: failed to write update baudrate (-110)
[   16.351334] Bluetooth: hci0: Failed to set baudrate
[   18.367240] Bluetooth: hci0: command 0x0c03 tx timeout
[   26.591255] Bluetooth: hci0: BCM: Reset failed (-110)
pi@emonpi:~ rfkill list
0: hci0: Bluetooth
	Soft blocked: no
	Hard blocked: no
1: phy0: Wireless LAN
	Soft blocked: no
	Hard blocked: no
pi@emonpi:~ hciconfig -a hci0
hci0:	Type: Primary  Bus: UART
	BD Address: 00:00:00:00:00:00  ACL MTU: 0:0  SCO MTU: 0:0
	DOWN 
	RX bytes:0 acl:0 sco:0 events:0 errors:0
	TX bytes:14 acl:0 sco:0 commands:2 errors:0
	Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
	Packet type: DM1 DH1 HV1 
	Link policy: 
	Link mode: SLAVE ACCEPT 

pi@emonpi:~ $ sudo hciconfig -a hci0 up
Can't init device hci0: Connection timed out (110)
pi@emonpi:~ $ 

I have also downloaded and built bluez-5.66.tar.xz with all the "-O2" removed form configure and --enable-debug specified. I note that hciattach and several others are now deprecated (but can be included in the build by specifying --enable-deprecated).

I have tried running the newly built hciconfig -a hci0 up as root with gdb. The problem occurs when ioctl(ctl, HCIDEVUP, hdev) fails, returning ETIMEDOUT (110).

Any suggestions on how to narrow down this problem?

There is a more recent version bluez-5.70.tar.xz on mirrors.kernel.org.

With the tail of /boot/config.txt containing

[pi4]
# Run as fast as firmware / board allows
arm_boost=1
core_freq=500
core_freq_min=500

[all]
dtoverlay=w1-gpio
# dtoverlay=disable-bt
enable_uart=1
dtoverlay=miniuart-bt

something appears to be working. After rebooting the system I can do

pi@emonpi:~ $ bluetoothctl
Agent registered
[CHG] Controller DC:A6:32:1C:C6:81 Pairable: yes
[bluetooth]# show
Controller DC:A6:32:1C:C6:81 (public)
	Name: emonpi
	Alias: emonpi
	Class: 0x00000000
	Powered: yes
	Discoverable: no
	DiscoverableTimeout: 0x000000b4
	Pairable: yes
	UUID: Generic Attribute Profile (00001801-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: A/V Remote Control        (0000110e-0000-1000-8000-00805f9b34fb)
	UUID: Device Information        (0000180a-0000-1000-8000-00805f9b34fb)
	Modalias: usb:v1D6Bp0246d0537
	Discovering: no
	Roles: central
	Roles: peripheral
Advertising Features:
	ActiveInstances: 0x00 (0)
	SupportedInstances: 0x05 (5)
	SupportedIncludes: tx-power
	SupportedIncludes: appearance
	SupportedIncludes: local-name
[bluetooth]# scan on
Discovery started
[CHG] Controller DC:A6:32:1C:C6:81 Discovering: yes
[NEW] Device F3:EE:9F:97:EB:C7 Ruuvi EBC7
[NEW] Device F4:29:6F:90:95:23 ObeliskTop3_00_184680042
[NEW] Device CD:39:02:5B:AD:E2 Ruuvi ADE2
[NEW] Device D1:D8:B9:27:84:2C Ruuvi 842C
[NEW] Device F9:D4:17:90:4E:58 Ruuvi 4E58
[NEW] Device E2:84:A8:A2:E7:A4 Ruuvi E7A4
[NEW] Device F0:08:96:34:76:DA Ruuvi 76DA
[NEW] Device F8:0C:4C:F4:91:B2 Ruuvi 91B2
[NEW] Device CE:65:E2:FD:91:84 Ruuvi 9184
[NEW] Device C4:07:3F:25:79:3F Ruuvi 793F
[NEW] Device E0:81:AF:1B:ED:40 Ruuvi ED40
[NEW] Device CC:D6:54:2F:A5:77 Ruuvi A577
[NEW] Device ED:B7:6D:1E:80:0D Ruuvi 800D
[NEW] Device FB:6B:86:93:63:C3 Ruuvi 63C3
[NEW] Device FD:5C:F2:74:11:BF Ruuvi 11BF
[NEW] Device F4:34:1C:50:80:AA Ruuvi 80AA
[NEW] Device DD:F2:17:21:3E:9E Ruuvi 3E9E
quitetooth]# 
pi@emonpi:~ $ dmesg | grep 'hci0'
pi@emonpi:~ $ 

Using the Get sensor data synchronously with callback example from the RuuviTag Sensor Python Package data can be retrieved from the RuuviTags.

I’m puzzled! Maybe hcistart isn’t necessary to use Bluetooth on the mini UART?