3

I have an app that needs to make use of the PL011 UART connected to a modem. It also needs to make use of Bluetooth.

I have configured the Pi to use the pi3-miniuart-bt overlay to move Bluetooth to the mini-UART. I have updated hciattach.service to use /dev/ttyS0. I have removed the attachment to the console from cmdline.txt. I have set core_freq to a fixed value in config.txt. All that works fine, and I can [mostly] use both Bluetooth and the hardware uart OK.

But oddly, every now and then when I boot the mini-UART doesnt respond. hciattach returns timeout when run and nothing, other than rebooting, brings it back to life. This seems to happen 1 boot in every 5 or so. Once its up it seems to stay up OK.

Has anyone else had this?

Relevant files

/boot/cmdline.txt
dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

/boot/config.txt
dtoverlay=pi3-miniuart-bt
enable_uart=1
core_freq=250

# I have also tried combinations of the below to lock core clock as docs seem to differ
#arm_freq=700
#arm_freq_min=700
#force_turbo=1

/lib/systemd/system/hciattach.service
[Unit]
ConditionPathIsDirectory=/proc/device-tree/soc/gpio@7e200000/bt_pins
Before=bluetooth.service
After=dev-ttyS0.device

[Service]
Type=forking
ExecStart=/usr/bin/hciattach /dev/ttyS0 bcm43xx 921600 noflow -

[Install]
WantedBy=multi-user.target
1

The issue you were/are facing is hciattach sometimes failing to update the firmware to the uart device. This results in no available hciX device

This in case results in having to restart the hciattach service (might be named hciuart.service as well.

There are numerous github reports on this with from my point of view not completly clear indication. See for example https://github.com/agherzan/meta-raspberrypi/issues/148

Some say update bluez, some say latest kernel, some mention a newer firmware file.

Tried a lot of those with no clear success as of yet.

For me this took too long to figure out and i falled back to a workaround which basically is restart the service on failure (for me it did work all the time after 2 x trying to hciattach).

I have not yet a 100% working setup without a workaround. Given that i usually run this on a jessie device with systemd230 and an ancient kernel this is OK for now, until i find the time to fix all this.

What i do saw is that as long as hciattach is still running another hciattach will fail.

This is the relevant part of my hciuart.service:

/etc/systemd/system/hciuart.service

[Unit]
...
StartLimitIntervalSec=60
StartLimitBurst=4
...

[Service]
Type=forking
#short sleep to prevent hciattach not beeing ready to use the interface
ExecStartPre=/bin/sleep 3
#Limit attach timeout to 10 sec, it usually takes 2-4 sec to actually work, no need to delay for 30 sec which is default
ExecStart=/usr/bin/hciattach -t 10 /dev/ttyS0 bcm43xx 921600 noflow -
Restart=on-failure
RestartSec=5

This has helped me from having to reboot every time the hciattach is unable to actually attach properly and not generating a hciX device name you can use f.e. via hcitool.

As a side notice you might rewrite the service file to not start hciattach directly, but instead do a wrapper which gives you more output, cleans old hciattach tries or similiar, but this is even more a bad design than the workaround of just try again.

For reference, you usually wont find the hciuart or hciattach file under /etc/systemd/system/ but under /lib/systemd/system/

this is per design and basically means if you rewrite the /lib/ one it might get overwritten on the next update of systemd. So for best practise you should copy that file, and store it in /etc/systemd/system.

Don't forget a daemon-reload

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.