主题中讨论的其它部件： TI-BT-4-2-STack-Linux-ADDON
您好，
我们目前正在努力将CC2564MODA集成到我们的Linux系统中。
目前，我们正在使用CC2564MODA评估板。 我们使用的Linux内核是4.4 ，而bluez版本是5.50。
需要辅助模式将音频流直接路由到集成DSP或从集成DSP路由。
我们正在使用 https://www.ti.com/tool/CC256XB-BT-SP上的servicepack版本1.8 (发布日期：2019年8月16日)。
为了配置波特率，我们尝试使用BHET工具。 遗憾的是，该链接不再起作用(https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/71.9651万/cc256xqfnem-cc256x-bluetooth-hardware-evaluation-tool-download-broken)，因此我们使用了WL18xx模块中的HITIester工具： https://www.ti.com/tool/WILINK-BT_WIFI-WIRELESS_TOOLS
因此，第一个问题是：这种工具是否适合继续使用，或者是否有更适合的工具？
因为我们已经开始使用WL18xx的工具。
根据CC256xB BT Service Pack (CC256XB_BT_SP_v 1.8 发行说明)中的文档，对于协助模式，需要执行两个脚本：
initscripts-TIInit_TIInit_add.16_bt_spec_spa.bts 6.7 ，然后 是6.7 ．4.1 16_avpr_add-on.bts
本章1.4 Assisted A2DP (A3DP)或启用WBS也提到，BLE或AVPR可以同时实现。
1.4。辅助A2DP (A3DP)或WBS启用
使用辅助模式(A3DP / WBS)需要运行附加脚本"initscripts-
TIInit_initscripts.16_avpr_add-on.bts 6.7 ”，然后运行主service pack“initscripts -
TIInit_VP.16_bt_spec_VPR.BTS 4.1 ”，启用6.7 ，因为它在默认情况下不启用。
当CC256xB器件与TI双模式蓝牙堆栈一起使用时，此过程
只要是CC256XB.h文件，蓝牙堆栈就会自动处理该文件
(上面的说明)被复制到stack目录(<install_dir>\Bluetootha\btpsvend\)。
注：一次可以启用BLE或AVPR。 请参阅CC2564B
设备数据表，了解更多详细信息。
由于我们不使用双模式蓝牙堆栈，我们必须自行加载固件。
为了测试固件加载，我们首先尝试使用Service Pack中提到的一个示例配置：
蓝牙6.7 ．16.bts
此文件是通过组合6.7 ．16_bt_spec_spic.bts 4.1 和生成的
initscripts－TIInit_TIinit.16_ble_add-on.bts 6.7。 它旨在与TI双模式蓝牙配合使用
STACK TI-BT-4-2-STack-LINUS-ADDON。 它还可以与其他Linux堆栈(如bluez)一起使用。
如果我们将此BTS文件放入固件文件夹/lib/firmware/ti-connectivity，我们可以成功执行hciattach并与电话交互(采集，扫描，配对，连接等)。
所以，基本操作似乎是可以的。
但由于我们需要辅助模式，这项测试只是为了表明其他模式正在工作。 我们需要使用AVPR配置，而不是BLE配置。
根据SWRU581.pdf附录D，“Using the CC256x Service Pack with Linux (TI-BT-4-2-stack-Linux-ADDON)”描述了如何编写这两个BTS文件。
遗憾的是，我们无法完全遵循该文档中描述的步骤，因为我们无法在HCITester中打开BTS文件。
为了获得BTS文件(如文本而不是二进制格式所述)，我们必须使用脚本垫(tstertools的一部分)打开文件。 在选择正确的XML配置后，我们能够在脚本板中编写两个文件。
出于测试目的，我们创建了两个文件，这些文件也附在该请求中：
- 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
放入/lib/firmware/ti-connectivity后，我们已将它们重命名为6.7 
16。
下面是我们收到的结果。
EDAG_BTS_TEST_2_BLE_LINUX.BTS /EDAG_BTS_TEST_2_BLE_LINUX.txt：
hciattach工作正常，我们可以使用电话执行蓝牙通信，如查询，扫描，配对等。)
EDAG_BTS_TEST_3_AVPR_LINUX.BTS/EDAG_BTS_TEST_3_AVPR_LINUX.txt
执行hciattach时，bluez堆栈报告以下消息：
- 找到德州仪器(TI)的芯片！
固件文件：6.7 /lib/firmware/ti-connection/TIInit_TIInit.16.bts
正在将脚本发送到串行设备
已加载BTS脚本版本1
Texas：将波特率更改为11.52万，流控制更改为1
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCWRCSCCCCWRCCWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRWRCCCC
已添加设备hci0
无法初始化设备hci0：设备或资源忙(16)无法初始化设备：设备或资源忙
打印CCC行，因为我们已经在内核中启用了调试。
为了了解这些信息，我们深入了解了Bluez堆栈。
结果是，当内核使用HCI命令请求芯片时，初始化过程中出现该问题。
以下屏幕截图显示了该问题。 在第605行中，如果芯片是否支持LE，则会有一个请求。
我们的期望是模块报告错误，但实际上它在此时报告正确。
为了获得此信息，我们使用内核的动态调试功能来跟踪两个固件加载之间的通信。
日志已附加：dmesg_EDAG_BTS_test_2_BLE_Linux_2_Changed_Kernel 和dmesg_EDAG_BTS_test_3_AVPR_Linux_Changed_Kernel。
dmesg_EDAG_BTS_test_2_BLE Linux _2_Changed_Kernel：
在第355 - 380行中，您可以看到请求 BT_HCI_CMD_READ_LOCAL _features 0x1003。 出于调试目的，在第370行再次打印了答案：FF Fe 2D Fe db ff 7b 87
dmesg_EDAG_BTS_TEST_3_AVPR_Linux_Changed_Kernel：
在第305 - 355行中，您可以看到请求 BT_HCI_CMD_READ_LOCAL _features 0x1003。 出于调试目的，在第320行再次打印了答案：FF Fe 2D Fe db ff 7b 87
从Bluez堆栈中，我们可以得出结论，此处所读的功能来自上面代码部分的hdev。
由于使用两个不同的固件版本时响应相同，LMP_le_capable函数似乎假定在这两种情况下都可以使用BLE。 如果是AVPR设置，则不是这样，LE_setup函数在第611行中失败。
仔细查看函数LMP_le_capable，我们可以看到哪个位是错误的：
- #define LMP_le_capable (dev) ((dev)-> features[0][4]& LMP_LE)
- #define LMP_LE 0x40
- 索引4处的字节是十六进制"DB" 1101 1011
如果禁用BLE /加载AVPR，我们希望控制器报告的功能应为0x9B，而不是0xDB。
我们可以做些什么来改变BT控制器的行为？
此致，
Adalbert
