This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/814450/cc2564c-cc2564c-a3dp-source-demo-cancel-a-connection-request
您好、Elisa、
获取、空气嗅探器和 FW 日志会有所帮助。 如果没有日志、就很难说出是什么出错了。
谢谢
您好 Hari、
我确实提供了空气跟踪和 FW 日志、我将它们上传到了 Lauren 提供的共享文件夹。
您能否确认您是否有权访问它们？
否则、我可以再次上传它们。
谢谢、
链接可能已过期。 可以、请重新发送。
我只需确认我通过电子邮件将日志发送给 Lauren、因为我无法将日志上载到共享文件夹。
请确认您收到了这些邮件吗？
谢谢！
是的、我收到了。 会在一天内回来的
FW 日志不会显示任何过度延迟。 您是否也捕获了监听器日志？ 如果可以、请您将其发送给您吗？ 我想知道，对等堆栈之间的 ACL 事务是否运行缓慢。
我将尝试上传监听器日志或通过电子邮件将其发送给 Lauren。 我在 TI 记录器文件中注意到的平均时间：TI_U8I_NewPairFails 2.lgr
来自 TI 的连接请求似乎在时间戳14：42：07.238处发生
2366 14：42：07.238接收 LMP_SET_AFH (60)、TRANS_ID：主器件(0) <--这是否意味着 TI 正在发送连接请求？
如果上面的行显示连接请求已发送、则稍后、在时间戳14：43：58.622处、我们可以看到：
22936 14：43：58.622 0x00020C77 0x00017D9A <-- HCI_Link_Key_Request_Event
这两个事件之间的时间几乎为2分钟、这是延迟的原因吗？
感谢您的建议。
我只向 Lauren 发送电子邮件、其中包含一个空气跟踪文件：TI_U8I_filtered_3.BTT
我从这些日志中注意到、处于配对模式的耳机(U8I)仍然尝试连接到其最后一个配对的设备、即 TI。
但是、如前所述、TI 的 PDL 为空、TI 正在扫描器件、因此从 TI 的列表中、我们选择要连接的 U8I。
但 U8I 不断向 TI 发送重新连接请求、TI 以待验证的方式进行响应。
U8I 需要一段时间才能发送"LMP 身份验证随机数"、而 TI 拒绝了该随机数、最终会分离 U8I。
耳机发送 LMP 分离器后、TI 发送：
1921872：etAUD_Stream_Open_Confirmation 1921877：现状：3. 1921879：BD_ADDR：0x501901302879 1921884：链接密钥：0x00000000000000000000000000000000
因此、在我看来、发送'LMP Detach'的耳机需要花费太长时间、这可能是因为它正在努力尝试重新连接到 TI 并处理来自 TI 的连接请求。
如果正确、问题是 ：TI 能否取消/终止 TI 发起的连接请求、以便 TI 不必等待2min 即可发送响应？
谢谢你
您好、再说一次、
我能够将两个跟踪上传到共享文件夹中、文件的名称是：
TI_U8I_filtered_3.BTT
和
TI_U8I_CONNECT_TOW_TOUTLON_Tofail.BTT
再次查看空气迹线、我意识到 TI 何时开始页面耳机(当我从 TI 的找到的器件列表中选择 U8I 时)。 TI 最终可能不会向耳机发送连接请求、因为 TI 已从耳机接收到连接请求。
因此、我认为耳机需要很长时间才能确定要做什么、但您的见解值得赞赏。
原来的问题仍然是： TI 如何取消/终止 TI 发起的连接请求、以便 TI 无需等待2min 即可发送响应？
非常感谢您的建议。
可以、请在监听日志文件中提供事件的时间戳以供您观察。
监听器日志中的第一个时间戳(TI_U8I_NewPairFails _2.lgr) 为 14：42：07.238
2366 14：42：07.238接收 LMP_SET_AFH (60)、TRANS_ID：主器件(0) <--此时 TI 向 U8I 发送连接请求
同一监听器日志文件中的第二个时间戳是 14：43：58.622
14：42：07.238和 14：43：58.622之间的差值几乎为2分钟
谦逊 我不确定您是如何确定连接请求到达2366。 它不是 LMP 连接。 通过我的记录器查看，我看到下面的事件..
22935 -来自远程的身份验证请求
22936 -来自控制器的链路密钥请求
22937 -主机 NACK。
时间方面、看起来不错。。。
20248 05/15/19 16：43：44.607 0x0001E0B6 0x000151DA LMP_CHANNEL 分类--> AFH 通道分类= 55 55 ff 7f FD ff 7f 55 20480 05/15/19 16：43：46.268 0x0001E5E5 0x00015709 <-- LMP_SET_AFH AFH 即时= 175870、AFH 模式= 1、AFH 通道映射= 1f 00 c0 00 c0 03 00 c0 7f 21651 05/15/19 16：43：51.838 0x0001F758 0x0001687C LMP_CHANNEL 分类--> AFH 通道分类= ff ff 57 FD ff 7f FD ff 7f FF 7f 55 21694 05/15/19 16：43：52.276 0x0001F8A7 0x000169CB <-- LMP_SET_AFH AFH 即时= 185472、AFH 模式= 1、AFH 通道映射= 00 00 dc 03 00 c0 03 00 c0 7f 22935 05/15/19 16：43：58.622 0x00020C77 0x00017D9A <-- LMP_au_rand Random Number = 69 2c 5F db 99 AC B3 22 C9 EA 94 A5 C3 68 50 51 22936 05/15/19 16：43：58.622 0x00020C77 0x00017D9A <-- HCI_Link_Key_Request_Event 22937 05/15/19 16：43：58.637 0x00020C7C 0x00017D9F HCI_Link_Key_Request_Negative Reply -->
我知道 2366 14：42：07.238接收 LMP_SET_AFH (60)、TRANS_ID：主机(0)
是参考、因为此时我知道我使用： AUD_Open_Remote_Stream ()发送了来自 TI 的连接请求
但是、正如您提到的、我看不到指示连接请求的 LMP 消息、因此我询问该线路是否存在
也许 TI 的库实际上从未发送过 LMP 连接消息。
然后、从那时起、直到远程设备向 TI 发送身份验证请求、时间间隔几乎为2分钟。 这个差距就是问题所在。
一旦 TI 在22936接收到身份验证请求、一切都正常。 但问题是、接收身份验证请求几乎需要2分钟。
从中删除
2366 14：42：07.238接收 LMP_SET_AFH (60)、TRANS_ID：主器件(0)
更改为
在这2分钟内、TI 无法与任何其他器件建立新连接。 因此、我们要求使用一种方法让 TI 取消任何待处理的交易、以便 TI 重新启动。
BT 控制器对 ACL 连接透明。 它们从主机 BT 堆栈处理到对等器件堆栈。 因此、您可能看不到这些连接的任何控制器日志消息。
侦听 UART/HCI TX/Rx 线路可能会显示何时发送 ACL 连接请求。 这是一个相当复杂的过程、但如果您可以嗅探这些线路、请查看以下应用手册：
http://www.ti.com/lit/an/swpa234/swpa234.pdf
好的、我会尝试。
您是否有机会获取 HCI 监听器日志？ 我理解它有点复杂、可能需要一段时间。 如果是、请关闭此主题并在准备好时创建一个新主题。
