Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

Running BlueZ on CY Part

Running BlueZ on CY Part

VinayakS_26
Moderator
Moderator
Moderator
100 replies posted 50 replies posted 25 replies posted

Introduction

 

The blog is to run BlueZ stack on a linux  host machine to initialize Cypress Bluetooth Controller, which is connected to Ubuntu machine through UART transport. The blog contains the necessary packages to install, the commands to be send to configure the Ubuntu Host

 

 

Pre-requisites

-- CYW920706WCDEVAL Board (recommended to download an empty Application)

-- Linux System/  Linux Machine (preferably Ubuntu)

 

 

Setting up the Host Machine

 

1. Plugging in the board

 

Plug in the CYW920706WCDEVAL board to the Host Linux Machine(in my case i used a Ubuntu Laptop). Check the dmesg logs to see the device files generated to which the UART transport has bound. In my case, the CYW920706WCDEVAL board had a PUART and HCI UART. Hence, the dmesg displayed two device files.

Eg: dmesg log for enumeration

enumeration.png

 

If the dmesg logs didn't display the device files to which the board had bound, then it could be because the fdti LKM(loadable Kernel Module) was not loaded in the kernel during boot. You could manually add it using the following command.

>>> modprobe ftdi_sio

Check whether the VID and PID parameters of the USB device is getting added to the following file

>>>c/sys/bus/usb-serial/drivers/ftdi_sio/new_id

else add the PID and VID to the file the following location.

>>>echo <vid> <pid>  > /sys/bus/usb-serial/drivers/ftdi_sio/new_id

 

Replug the device back to the host machine and check the dmesg logs to see bonded device files.

After a reboot, the ftdio_sio LKM might get unloaded. To make the LKM load after every reboot, you could define a rule in the rules.d list.

To find about more about adding rules in the rules.d list , check the following page

https://unix.stackexchange.com/questions/226041/adding-usb-device-to-rules-d

 

2. Setting up BlueZ

 

Download the necessary packages for Bluez from the link given below and run the following commands. Additional packages  contains utilities to check the status of Bluez Daemon.

BlueZ » Download

>>>tar -xvf bluez-5.??.tar.xz

>>>cd bluez-5.??.tar.xz

>>>./configure

>>>make

>>>make install

Additional packages to download are given here.(if they are missing in your system).

>>>sudo apt-get install libdbus-1-dev libudev-dev libical-dev libreadline-dev bluetooth bluez-tools rfkill rfcomm

Once done with the download, check whether the Bluetooth adapter is unblocked.

>>> rfkill list all

>>> rfkill unblock all

Check the status of the corresponding systemd(system daemon) service:

>>>systemctl status bluetooth.service

The daemon can be reloaded with the following commands:

>>>systemctl daemon-reload

>>>systemctl restart bluetooth

 

3. HCI UART bring-up

 

Use hciattach command to attach the serial device via HCI UART to the BlueZ stack.

eg:

>>>sudo hciattach  /dev/ttyUSB0 -t 10 any 115200 noflow nosleep

 

The hciattach utility tries to send a HCI reset to the device via the HCI UART. Check the dmesg logs to see the status of HCI reset. If a reset timeout is happening, do a manual reset of the device while the reset commands are being send to the device by the host machine.

Once successful, you are ready to send the hci command using the hcitool utility.

The following picture shows dmesg logs for hciattach. Here, timeout is happening when host tries to send a HCI reset. This can be resolved by manually resetting the device.

timeout.png

Use the following command to check the hci devices

eg:

>>>hcitool dev

Device:

          hci0      5C:AC:4C:F8:1F:80

          hci1      20:70:6A:20:f4:9B

The following diagram shows the commands to send to determine whether the device has been attached to the hci interface generated in the host.

It also gives further details like the BD address and the traffic the is going in the BT device.

hciconfig.png

For scanning LE devices:

>>> hcitool -i hci1 lescan

 

LE SCAN initiated in the interface hci1 created for the new device.

lescan.png

 

HCI command Injection

 

For sending specific HCI commands, use the following format:

>>>hcitool cmd <ogf> <ocf> [parameters]

 

eg: Write Local Name Command (ocf :HCI_Write_Local_Name -- 0x0013  & ogf: 0x03 )

For HCI Control and Baseband commands <ogf> is 0x03

(ABCD -- 0x41 0x42 0x43 0x44 )

The following picture show the usage of the hcitool cmd

hcicmd.png

3490 Views
Comments
bish_4755391
Level 1
Level 1
First reply posted Welcome!

hello

     Let me ask you a question     Bluetooth: hci1 command 0x1009 tx timeout,

timeout is happening when host tries to send a HCI reset.  How to solve this by manual reset.

[ 2159.920458] Bluetooth: HCI UART driver ver 2.3

[ 2159.920461] Bluetooth: HCI UART protocol H4 registered

[ 2159.920462] Bluetooth: HCI UART protocol BCSP registered

[ 2159.920462] Bluetooth: HCI UART protocol LL registered

[ 2159.920463] Bluetooth: HCI UART protocol ATH3K registered

[ 2159.920463] Bluetooth: HCI UART protocol Three-wire (H5) registered

[ 2159.920482] Bluetooth: HCI UART protocol Intel registered

[ 2159.920489] Bluetooth: HCI UART protocol BCM registered

[ 2159.920490] Bluetooth: HCI UART protocol QCA registered

[ 2161.927123] Bluetooth: hci1 command 0x1003 tx timeout

[ 2163.931125] Bluetooth: hci1 command 0x1001 tx timeout

[ 2165.935137] Bluetooth: hci1 command 0x1009 tx timeout

[ 2171.923134] Bluetooth: hci1 command 0x1003 tx timeout

[ 2173.927356] Bluetooth: hci1 command 0x1001 tx timeout

[ 2175.931266] Bluetooth: hci1 command 0x1009 tx timeout

[ 2186.443833] Bluetooth: hci1 command 0x1003 tx timeout

[ 2188.448143] Bluetooth: hci1 command 0x1001 tx timeout

[ 2190.451851] Bluetooth: hci1 command 0x1009 tx timeout

[ 2318.656461] Bluetooth: hci1 command 0x1003 tx timeout

[ 2320.661166] Bluetooth: hci1 command 0x1001 tx timeout

[ 2322.664982] Bluetooth: hci1 command 0x1009 tx timeout