CC6 dev kit BlueTooth issue


I’m debugging Bluetooth functionality on a CC6 Jumpstart Dev Kit.
dey-bluetooth package is added to Yocto.

dmesg shows the Bluetooth software services are running:
Bluetooth: Core ver 2.22
Bluetooth: HCI device and connection manager initialized
Bluetooth: HCI socket layer initialized
Bluetooth: L2CAP socket layer initialized
Bluetooth: SCO socket layer initialized
Bluetooth: HCI UART driver ver 2.3
Bluetooth: HCI UART protocol H4 registered
Bluetooth: HCI UART protocol ATH3K registered
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM socket layer initialized
Bluetooth: RFCOMM ver 1.11
Bluetooth: BNEP (Ethernet Emulation) ver 1.3
Bluetooth: BNEP filters: protocol multicast
Bluetooth: BNEP socket layer initialized
Bluetooth: HIDP (Human Interface Emulation) ver 1.2
Bluetooth: HIDP socket layer initialized

I traced the issue to the bluetooth-init script.
The call “hciattach ttyBt ath3k 4000000” step fails with:

Failed to Download configuration: Success
Can’t initialize device: Success

Is this related to downloading the pst files?

In the kernel config, the following are defined:
Atheros AR300x serial support (CONFIG_BT_HCIUART_ATH3K)

Is this one needed too?
HCI_IBS protocol support (CONFIG_BT_HCIUART_IBS)

I would greatly appreciate any recommendations for debugging this issue.


What Yocto version are you using?
Are you testing on stock images on SBC?
are there any BT related errors in bootlog?
can you try commands listed here:
Does it work for you?

I’m not sure what Yocto version. I can find out. We are using a custom version based on your bsp and trying to get Bluetooth working.

bluetoothctl does not list a bluetooth controller:

root@cmems-ccimx6sbc:/etc# bluetoothctl
Agent registered
[bluetooth]# scan on
No default controller available

My thought is this is because the hciattach command in bluetooth-init is failing.

One thing to note: the bluetooth-init script tries to source /etc/init.d/functions which doesn’t exist on our system as it’s using systemd services. It looks like it’s needed for killproc() def. I got around it by defining killproc() in the script.

I don’t see any BT related errors in the bootlog (messages). Let me know if you’d like me to send it or post the contents. I don’t see a way to attach files.


I would try this first with stock images.= and see if BT is working. Also, I would try your custom images on our SBC and see if it is still working.

Yes, the bluetooth hardware is working. I have confirmed BT functionality with the sdcard image here:

Do you have any ideas why hciattach command would fail for out custom image? I’m going to look into pin mux.


Yes, among others, there is a pin that disables radio.

Do you know what pin that is? Also, does that pin disable just BT or both BT and Wifi? Wifi works fine on the system.


Does this script runs in startup in your images?
When I wanted to purposely disable BT on cc6 ,I would try booting with the imx6q-ccimx6sbc-w.dtsDT instead of the imx6q-ccimx6sbc-wb.dts one. Bluetooth will be disabled.

/etc/init.d/bluez doesn’t exist in both the custom image and image that has functional BT. I have bluetooth-init and bluetooth instead.

I see imx6q-ccimx6-wb.dtsi being included.

The version of yocto linux is 4.18



I’m still looking into why hciattach is failing.
The bluetooth-init script toggles the gpio244, do you know what I/O that maps to?

Is it one of these signals? the pwrdown-gpio or disable-gpio as described in the device tree?

bluetooth {
digi,pwrdown-gpios = <&gpio_extender 4 0>;
digi,disable-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
/* U-Boot will fill in the MAC address here */


Also, can you send me or point me to the bluez init script you refer to? Thanks.
Calculating the Linux GPIO number of a GPIO pin
For each GPIO controller entry on the device tree Linux creates an entry /sys/class/gpio/gpiochipN, where N is an integer number starting at 0, with the following read-only attributes:

base: same as N, the first GPIO managed by this chip

label: provided for diagnostics (not always unique)

ngpio: the number of GPIOs this controller manages (from N to N + ngpio - 1)

The PMIC is probed second:

PMIC: /sys/class/gpio/gpiochip240
PMIC GPIO4 is: 240 + 4 = 244
Which is BT_PWD# going to Qualcomm-Atheros AR6233, so it should not be used by anything else.

As a sanity check I was going to check the pin mux on that pin and make sure that is was set to GPIO function. Do you know what port/pin combination that maps too? gpio244 has a symbolic link as follows:

gpio244 -> …/…/devices/gpiochip7/gpio/gpio244

I was going to read the register that defines the pin mux. Where is pin mux defined in the source?

I’m grasping at any ideas that would make the hciattach command fail for setting up bluetooth. The wireless interface (wlan0) works so communication to the chip is working.


The pin is not defined in device tree and is GPIO by default I believe. compile your images with stock device tree:
does it work?
if it does compare your device tree with the stock one and start moving one change at a time to stock one from your’s and see when it breaks.

I diff’ed the dts and dtsi files and differences are related to camera and parallel display (no bluetooth differences). Our custom build is using kernel 4.18. Is there a way to build the 4.18 kernel with Digi release 2.6 instead of kernel 4.9?


I am afraid, not. What is preventing you from upgrading to the newer kernel?

The kernel we are using is actually newer.

Separate question, I’d like to examine the gpio states of the disable-gpios referenced from the Bluetooth Device tree entry:

bluetooth: bluetooth {
digi,pwrdown-gpios = <&gpio_extender 4 0>;
digi,disable-gpios = <&gpio1 9 GPIO_ACTIVE_HIGH>;
/* U-Boot will fill in the MAC address here */

pwrdown-gpios has you stated before is gpio244. what is disable-gpio? Port 1, pin 9. Is it gpio9? Thanks.

yes, if you look ad cc6 SBC schematics you will find that module’s pad H3 is GPIO_9 and is used as BT_DISABLE_N


LinuxGPIO_num = ( - 1) * 32 +
so yes it will become /sys/class/gpio/gpiochip9

Relating back the kernel discussion, earlier in this thread. I know the dey 2.6 release uses 4.9 linux kernel.
Do you know if the upstream 4.18 kernel tree supports the bluetooth interface on this SOM?