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.

[参考译文] LMX9838 -处理活动流上的断开连接

Guru**** 2553450 points


请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/574065/lmx9838---handling-disconnection-on-active-stream

您好!

问题:

远程端断开多个活动(4) SPP 通道中的两个。

当断开连接时、本地 UC 激活、向远程端发送数据。

本地 UC 不会为已启动的 SPP_SEND_DATA 命令获取 CFM、但会在远程端断开连接时获取 SPP_LINK_RELEASED IND 数据包。

发生这种情况时、UC 一直在等待 SPP_SEND_DATA 的 CFM。 有时在大约两分钟内、lmx9838会重置并发送 LMX9838 _READY IND 数据包。

在什么情况下可以触发 lmx9838上的复位? 该文档未提及看门狗、其他安全措施或可能触发这些安全措施的因素。

BRG

KD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好!

    您的查询已分配给相关的 LMX9838专家。 我们很快就会跟进。

    此致、
    Vihang
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    您好、Kari、

    当我找到更多信息时、我将调查您的问题并作出回应。

    同时、这是您在多个系统上看到的问题、还是您在一个系统上看到的问题?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    James、

    这种情况发生在多个器件上。

    BRG

    KD

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    模块0212 (补丁2)中的固件。
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    观察结果:
    我注意到、如果:
    1) 1)我为 LP A 和某个远程端发出 SPP_Establish_link 命令
    2) 2)等待 lmx9838发出 SPP_Establish_link CFM 消息
    3) 3)为 LP B 和某个远程端发出 SPP_Establish_link 命令
    两个连接问题都将失败。 即、第一条命令的 CFM 消息不足以发出进一步的连接命令。
    在继续建立连接之前、我必须等待第一个连接的 SPP_LINK_established IND 数据包。
    文档中未提及这一点。

    理论(问题):
    在发出 SPP_Establish_link 命令后等待 SPP_LINK_established IND 数据包时、是否应阻止所有其他命令?
    如果我不这样做、是否有可能、即等待 SPP_LINK_established IND 数据包、然后再发送更多这种命令
    触发 lmx9838芯片的崩溃?
    是否还有类似的其他情况、其中命令会触发 lmx9838中的某些内部处理、而 lmx9838会返回该命令的 CFM 数据包、但实际上尚未准备好接受其他命令?

    BRG
    KD
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    您好、Kari、

    我收到了一位蓝牙专家的回复。 我在下面复制了它。 这对您有何帮助?

    我使用3个 LMX9838加密狗模拟了这种情况。 其中一个作为主器件工作、创建与另两个作为从器件工作的连接。

    如果其中一个从器件断开连接、则在链路超时(默认值为20s)后、有关链路丢失的消息将发送到主机、该值等于0x7D00 (32000)插槽625us。 链接超时可 在0x0190–0xFFFF 时隙范围内设置。 如果在此超时期间仍通过断开的链路发送数据、则执行两个 SPP_SEND_DATA 时确认、但第三个命令没有确认:

     

    TX:CMD:发送数据、本地端口:01、有效载荷数据:54657374 [第一个带确认的命令]

    RX:事件:发送数据、状态:00、本地端口:01

    TX:CMD:发送数据、本地端口:01、有效载荷数据:54657374 [带确认的第二个命令]

    RX:事件:发送数据、状态:00、本地端口:01

    TX:CMD:发送数据、本地端口:01、有效载荷数据:54657374 [第三条命令、无需确认]

    RX:事件:ACL 终止、bdaddr:04778CE80010、原因:08 [通过链接超时、将链路断开的信息发送到 MCU ]

    RX:事件:链路已释放、原因:02、本地端口:01

     

    如果未确认 SPP_SEND_DATA 命令、MCU 应等待、并且在收到链路断开指示之前不会向 LMX9838发送任何其他命令。 发生这种情况时、LMX9838会清除在断开的链路上无法发送的所有数据。 这意味着在中断的端口超时期间发送到该端口的任何数据都应在链路恢复后重新发送。

    如果 MCU 未观察到握手(RTS 和 CTS)线路并在无法处理数据的情况下将数据发送到 LMX9838、则 LMX9838可能会复位

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    谢谢 James。

    我使用的是 RTS/CTS 流控制、根据文档、当不处于透明模式时、不需要该流控制。
    已授权、新命令只能在收到上一条命令的 CFM 数据包后发出。
    我非常小心、并验证了情况、即在收到 CFM 之前、我不会发出新命令。

    不管怎样、我对代码进行了重新编排、这样也会阻止新命令、直到收到 IND 数据包(SPP_Establish_link 命令之后的 SPP_LINK_Established 以及 SPP_RELEASE_LINK 命令之后的 SPP_LINK_RELEASED)。
    这似乎可以解决问题。 但是、由于 IND 数据包似乎并不总是发送、因此我在等待时确实有超时(针对1个链路超时)。

    因此、我的结论是、在收到 SPP_Establish_link 或 SPP_LINK_RELEASED 的 CFM 并收到相应的 IND 数据包后、在时间窗口中发出命令会出现问题。

    您可以确认这一点吗?
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    Kari、

    以下是我们专家的回答:

    LMX9838始终使用 RTS/CTS。 如果您将在模块仍忙于执行先前接收到的命令时继续发送命令、则在特定点会切换 RTS。 这同样适用于 CTS、因此如果 CTS 阻止通信、它不会向 MCU 发送任何内容。 通常、如果正确使用命令模式、并且在发出下一个命令之前等待命令的结果、则 RTS 将保持活动状态。

     

    所述代码的更改是正确的。 REQ_SPP_Establish_link 之后的 CFM 是有关理解和启动命令的确认。 但是、在 LMX9838发送 IND_SPP_LINK_established 之前、该链接不存在。 REQ_SPP_RELEASE_LINK 也是如此。

  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。
    James、

    不幸的是,我太快,无法报告成功。
    这仍然在发生…
  • 请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

    我们的 BT 专家提供的信息

     

    必须完成的两个基本操作:

    1.      使用硬件 RTS/CTS 握手线防止 LMX9838未就绪时进行传输。

    2.      对于所有以确认命令已执行的指示结束的命令(例如 REQ_SPP_Establish_link)、始终等待指示、然后再发送下一条命令。

     

    我认为这些条件现在已经得到满足,但我想再次明确地指出。

     

    我认为、当其中一条远程链路断开时、Kari 仍然有问题。 如果发生这种情况、主器件将在默认值为20s 的超时后被告知链路正在被释放。 如果在此期间发出了发送数据命令、则可能会发生锁定。

     

    我再次使用3个 LMX9838模块对其进行测试。 我的主设备使用本地端口1和2 (MLP1、MLP2)与从设备1 (S1RP1)上的远程端口1和从设备2 (S2RP1)上的远程端口1通信。 主机将事件过滤器设置为0x00以报告所有事件。

    在这两种情况下、我都会复位从器件2以断开链路、从而模拟错误条件。 到从器件1的链路始终处于活动状态。 下面的列表显示了从器件2复位并断开其链路后的 SB Commander 主器件日志。

     

    场景1–在超时期间、数据仅发送到从器件2。

    Slave2复位

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374

    RX:事件:发送数据、状态:00、本地端口:02 [已确认但未传输]

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374

    RX:事件:发送数据、状态:00、本地端口:02 [已确认但未传输]

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374 [由于 LMX9838中的两个内部缓冲器已满、因此未确认、MCU 必须在此处等待]

    RX:事件:ACL 已终止,bdaddr:04778CE80010,原因:08 [ACL link broken (ACL 链接断开)]

    RX:事件:链路已释放、原因:02、本地端口:02{SPP 链路断开]

     

    在场景1中、如果我再次连接到从站2、则链接工作正常。

     

    场景2–在超时期间、数据 被发送到 slave2、从器件1和从器件2。

    Slave2复位

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374

    RX:事件:发送数据、状态:00、本地端口:02 [已确认但未传输]

    TX:CMD:发送数据、本地端口:01、有效载荷数据:54657374

    RX:事件:发送数据、状态:00、本地端口:01 [已确认和已传输]

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374

    RX:事件:发送数据、状态:00、本地端口:02 [已确认但未传输]

    TX:CMD:发送数据、本地端口:02、有效载荷数据:54657374 [由于 LMX9838中的两个内部缓冲器已满、因此未确认、MCU 必须在此处等待]

    RX:事件:ACL 已终止,bdaddr:04778CE80010,原因:08 [ACL link broken (ACL 链接断开)]

    RX:事件:链路已释放、原因:02、本地端口:02{SPP 链路断开]

     

    在方案2中、如果我尝试重新连接到从站2、则 LMX9838不会确认该命令、并且尽管存在到从站1的实际链接、该命令仍保持锁定状态。 它看起来主设备的无线电传输路径已锁定。

     

    如果链路丢失、我的建议是在接收到链路释放后立即向主器件发出重置命令、等待链路超时过期并重新连接到两个从器件。

    TI LMX 网站上的一组文档中包含一个应用手册(随附)、介绍了模块的内部缓冲器。 我发现一些数字(如缓冲器大小)与测试结果不完全匹配、但我认为、一般而言、它显示了模块的内部结构。

     

    e2e.ti.com/.../SB_5F00_UART_5F00_AN.PDF