Thread 中讨论的其他器件：WL1831
我们正在开发一个将 TI WL18xx 用作蓝牙控制器的硬件/软件项目。 该产品的主要功能之一是通过低功耗蓝牙连接与传感器硬件进行通信。 我们遇到了一个问题、我们在引脚定位方面遇到了困难、但感觉可能存在于 TI WL18xx 硬件/固件中。 间歇性地、连接第二个低功耗蓝牙器 件后、从写入和通知其中一个已连接器件的特性开始的响应时间会变得非常长。
详细信息
主机产品器件 在 TI AM4376x 处理器上运行我们自己的嵌入式 Linux 映像。 内核为 4.14.79、我们的通信堆栈位于 Bluez5之上。 WiFi/蓝牙芯片是 Jorjin WG7831-BO、运行 TIInit_11.8.32.bts 固件版本4.5。 它基于 TI WL1831。 我们连接到的传感器器件是我们自己的器件、我们 使用自定义命令协议、该协议使用两个特性来执行命令握手。 这些器件在许多其他平台上都能正常工作、包括 Mac、Windows、Linux、Chrome、 等等
导致问题的工作流程是：
- 用户空间应用 可让用户通过 BLE 发现传感器器件并将其连接到我们的传感器器件、BLE 每次一个器件。
- 初始连接需要针对上述 BLE 特性进行大量命令/响应类型通信。
- 连接后、流量会显著减少到偶尔发出新测量的通知、以及用户触发的偶尔命令/响应交换。
- 单个器件始终看起来稳定且性能出色。
- 当用户连接到第二个设备时、初始连接按预期进行。
- 但是、一旦第二个器 件的连接过程完成、我们开始看到、在最初连接的器件上、命令/响应时间会延长数百倍。
- 第二个器件通信按 预期速度继续。
- 此问题仅在我们 遵循此工作流程的第一台设备大约50%时发生。
迹线
附件是我们的器件通信 库(前缀为"D2PIO_SDK")和显示蓝牙问题的 btmon 的完整跟踪。 下面是由跟踪日志构成的问题的简短片段、该日志是我们的库调试和 btmon 跟踪的组合。
直到第4102行、一切看起来都很好、我们在该行看到以下内容：
< ACL 数据 TX：处理1025个标志0x00 dlen 22 #1081 [hci0] 00：12：48.654867
ATT：写入命令(0x52) len 17
句柄：0x0014
数据：580fd8c71bff00204e00000000
D2PIO_SDK：GMBLNGIBLOPP.CPP (1532)：发送的 Blob cmd：1bh 至 GDX -用于07100117；长度= 15；滚动计数器= 216；时间戳= 258104ms。
> HCI 事件：已完成数据包的数量(0x13) PLEN 5. #1082 [hci0] 00：12：49.387892
数字句柄：1.
手柄：1025
数量：1.
> ACL Data RX：handle 1025 flags 0x02 dlen 23 #1083 [hci0] 00：12：51.801225
ATT：处理值通知(0x1b) len 18
句柄：0x0016
数据：9810272f1bd8ff00204e00000000
D2PIO_SDK：GMBLNGIBlobSource.CPP (1745)：GetNextResponse (GDX-for 07100117)在3139=(261263-258124)毫秒后返回1bh cmd bb。
