简短的问题 - 参考 WireShark 图像，是什么导致 Master 发送 LL_CHANNEL_MAP_IND 以及为什么需要这么长时间？
我们正在开发一个使用 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 特性进行一系列命令/响应类型的通信。连接后，流量会显着减少，因为偶尔会有新测量的通知，以及偶尔由用户触发的命令/响应交换。单个设备似乎总是稳定且高性能。当用户连接到第二台设备时，初始连接会按预期进行。但是，一旦第二个设备的连接过程完成，我们开始看到命令/响应响应时间在最初连接的设备上变长了数百倍。第二设备通信以预期速度继续。
痕迹
这是由我们的库调试和 btmon 跟踪混合而成的跟踪日志形成的问题的简短片段。
直到第 4102 行，一切似乎都很好，我们在该行看到以下内容：
ACL 数据 TX：句柄 1025 标志 0x00 dlen 22 #1081 [hci0] 00:12:48.654867 ATT：写命令 (0x52) len 17 句柄：0x0014 数据：580fd8c71bff00204e000000000000
D2PIO_SDK：GMBLNGIBlobSource.cpp(1532)：Blob cmd 发送：1bh 到 GDX-FOR 07100117；长度 = 15; 滚动计数器 = 216; 时间戳 = 258104 毫秒。
HCI 事件：已完成数据包数 (0x13) plen 5 #1082 [hci0] 00:12:49.387892 句柄数：1 句柄：1025 计数：1
ACL 数据 RX：句柄 1025 标志 0x02 dlen 23 #1083 [hci0] 00:12:51.801225 ATT：句柄值通知 (0x1b) len 18 句柄：0x0016 数据：9810272f1bd8ff00204e000000000000
D2PIO_SDK：GMBLNGIBlobSource.cpp(1745)：GetNextResponse(GDX-FOR 07100117) 在 3139=(261263-258124) 毫秒后返回 1bh cmd blob。
对于大多数 cmd，GetNextResponse() 报告的经过时间应小于 30 毫秒。当我们打开并向设备 A 发送一堆 cmd 时响应时间很短。当我们打开并向设备 B 发送一堆 cmd 时响应时间仍然很短。但是在随后向设备 A 发送的第一个 cmd 上，响应时间为超过3秒！