Other Parts Discussed in Thread: TI-BT-4-2-STACK-LINUX-ADDON
Hi there,
We're currently working on integrating a CC2564MODA into our linux system.
At the moment, we're working with the CC2564MODA evaluation board. The Linux Kernel we're using is 4.4 and BlueZ Version is 5.50.
The assisted mode is required to route the audio streams directly to/from an integrated DSP.
We're using the servicepack Version 1.8 from https://www.ti.com/tool/CC256XB-BT-SP (Release date: 16-Aug-2019).
In order to configure the baud rates, we tried to use the BHET tool. Unfortunately, the link is no longer working (https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/719651/cc256xqfnem-cc256x-bluetooth-hardware-evaluation-tool-download-broken) so we used the HCITester Tool from the WL18xx modules: https://www.ti.com/tool/WILINK-BT_WIFI-WIRELESS_TOOLS
So, the first question would be: Is this tool suitable to go ahead or is there a better suited tool?
As we have already proceeded with the tools from WL18xx.
According to the documentation in CC256xB BT Service Pack (CC256XB_BT_SP_v1.8 Release Notes), for the assisted mode two scripts need to be executed:
initscripts-TIInit_6.7.16_bt_spec_4.1.bts followed by initscripts-TIInit_6.7.16_avpr_add-on.bts
This Chapter 1.4 Assisted A2DP (A3DP) or WBS enable also mentions, that either BLE or AVPR can be acitive at the same time.
1.4. Assisted A2DP(A3DP) or WBS enable
Using the Assisted modes (A3DP / WBS) require running an additional script “initscripts-
TIInit_6.7.16_avpr_add-on.bts” after running the main service-pack “initscripts-
TIInit_6.7.16_bt_spec_4.1.bts”, which enables the AVPR, as it is not enabled by default.
When using the CC256xB device with the TI dual-mode Bluetooth stack, this procedure
is automatically handled by the Bluetooth stack as long as the CC256XB.h file
(description above) is copied to the stack directory (<install_dir>\Bluetopia\btpsvend\).
Note: Either BLE or AVPR can be enabled at a time. Please refer to the CC2564B
device datasheet for more details.
As we're not using the dual-mode bluetooth stack, we have to load the firmware ourself.
In order to test the firmware load, we tried first to use one of the sample configuration mentioned in the service pack:
BluetopiaPM_Linux\TIInit_6.7.16.bts
This file is generated by combining the Initscripts-TIInit_6.7.16_bt_spec_4.1.bts and the
Initscripts-TIInit_6.7.16_ble_add-on.bts. It is meant to be used with the TI dual-mode Bluetooth
stack TI-BT-4-2-STACK-LINUX-ADDON. It may also be used with other Linux stacks like BlueZ.
If we put this BTS file into the firmware folder /lib/firmware/ti-connectivity, we can perform an hciattach and interact with the phones (inquiere, scan, pair, connect, etc...) successfully.
So, basic operation seems to be OK.
But as we need the assisted mode, this test was only to show that the rest is working. We need to use the AVPR configuration and not the BLE config.
According to SWRU581.pdf, Annex D, "Using the CC256x Service Pack With Linux (TI-BT-4-2-STACK-LINUX-ADDON)" describes how to compose these two BTS files.
Unfortunately, we cannot exactly follow the procedure described in that document because we cannot open the BTS files in HCITester.
In order to get the bts files - as described in text and not in binary format - we had to open the files using script pad (part of testertools). After selecting the correct XML config, we were able to compose the two files in script pad.
For testing purpose, we created two files, which are also attached to this request:
- EDAG_BTS_TEST_2_BLE_LINUX.bts /EDAG_BTS_TEST_2_BLE_LINUX.txt
- EDAG_BTS_TEST_3_AVPR_LINUX.bts / EDAG_BTS_TEST_3_AVPR_LINUX.txt
When placed into /lib/firmware/ti-connectivity we have renamed them to TIInit_6.7.16 of course.
Here are the results, we received.
EDAG_BTS_TEST_2_BLE_LINUX.bts /EDAG_BTS_TEST_2_BLE_LINUX.txt:
hciattach works and we can perform bluetooth communication wiht the phones like inquiry, scan, pair,...)
EDAG_BTS_TEST_3_AVPR_LINUX.bts / EDAG_BTS_TEST_3_AVPR_LINUX.txt
When executing hciattach, the BlueZ stack report the following messages:
- Found a Texas Instruments' chip!
Firmware file : /lib/firmware/ti-connectivity/TIInit_6.7.16.bts
Sending script to serial device
Loaded BTS script version 1
texas: changing baud rate to 115200, flow control to 1
CCCCCCCCCCCCCCCCCCCCWRCSCCCCWRCCWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRCCCC
Added device hci0
Can't init device hci0: Device or resource busy (16)Can't initialize device: Device or resource busy
The CCC lines are printed, because we havve enabled debuggin in the kernel.
In order to understand the messages, we digged deeper into the Bluez stack.
It turned out that the issue appears during the init process when the kernel requests the chip featured by using HCI-commands.
The following screenshot shows the issue. In line 605, there's a request if the chip is LE capable or not.
Our expectation was that the module reports FALSE but in fact it reports TRUE at this point.
In order to get this information, we have use the dynamic debug function of the kernel in order to trace communication between the two firmware load.
The logs are attached: dmesg_EDAG_BTS_TEST_2_BLE_LINUX_2_Changed_Kernel and dmesg_EDAG_BTS_TEST_3_AVPR_LINUX_Changed_Kernel.
dmesg_EDAG_BTS_TEST_2_BLE_LINUX_2_Changed_Kernel:
In the lines 355 - 380 you can see the request BT_HCI_CMD_READ_LOCAL_FEATURES 0x1003. For debugging purposes, the answer was printed again in line 370: ff fe 2d fe db ff 7b 87
dmesg_EDAG_BTS_TEST_3_AVPR_LINUX_Changed_Kernel:
In the lines 305 - 355 you can see the request BT_HCI_CMD_READ_LOCAL_FEATURES 0x1003. For debugging purposes, the answer was printed again in line 320: ff fe 2d fe db ff 7b 87
From the Bluez stack, we can conclude that the features, which are read here are comming from the hdev from code sections above.
Because the response is identical using the two differen firmware version, it seems lmp_le_capable function assumes in both cases that BLE is possible. In case of the AVPR setup, that's not the case and the le_setup function fails in line 611.
Looking closer into the function lmp_le_capable shows us, which bit is wrong:
- #define lmp_le_capable(dev) ((dev)->features[0][4] & LMP_LE)
- #define LMP_LE 0x40
- Byte at Index 4 is hex "DB" 1101 1011
We would expect that the features reported by the controller should be 0x9B instead of 0xDB in case BLE is disabled/AVPR is loaded.
What can we do in order to change the behaviour of the BT Controller?
Best regards,
Adalbert
