• 状态 Resolved
  • 已锁定 已锁定
  • 回复 56 回复
  • 订户 0 订户
  • 视图 7828 视图
  • 用户 0 会员在此处
选项
选项
相关

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.

[参考译文] CC2652R：OTBR-RCP：RadioSpinelNoResponse (无线电 TX 超时)

admin
Guru**** 2460850 points
Other Parts Discussed in Thread: SYSCONFIG, UNIFLASH, CC2652R, CC2652R7, LAUNCHXL-CC26X2R1, SYSBIOS, LP-CC2652R7

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1226166/cc2652r-otbr-rcp-radiospinelnoresponse-radio-tx-timeout

器件型号：CC2652R
Thread 中讨论的其他器件： 、SysConfig 、UNIFLASH、 LAUNCHXL-CC26X2R1、 SYSBIOS、

您好！  

我们在 Linux (版本  4.19.183)平台中使用 otbr-agent、通过 UART (115200)通信使用 CC2652R1。 OTBR 于2023年3月进行了同步、并 使用了 simplelink_cc13xx_cc26xx_sdk_7_10_00_98的最新 rcp 图像。

版本：
OPENTHREAD/；POSIX；2023年5月3日14:38:20

RCP 版本：(rcp_CC26X2R1_LAUNCHXL_tirtos7_ticlang_sdk_7_10_00_98.bin)
TI-OPENTHREAD/1.2.4.0；CC1352；2023年5月12日13：12：48

当我们添加更多线程传感器时，会出现此错误消息，并且 otbr-agent 崩溃。 看起来 TI-RCP 在一段时间后没有响应。

CRIT OTBR-AGENT[3315]：00:31:09.962 [C]平台----- : HandleRcpTimeout()在 radio_spinel_impl.HPP:2275：RadioSpinelNoResponse
WARN OTBR-AGENT[3315]：00:31:09.962 [W] Platform ----- ：无线电 TX 超时

如果我们有1-3个螺纹传感器、则问题频率较低。 当我们在大约10伏左右添加更多传感器时、就会更频繁地看到这一问题。  

我们在所有位置使用默认设置(UART 波特率115200)

otbr-agent -i wpan0 -B eth0 spinel+hdlc+uart：///dev/ttyH0 trel：//eth0

有什么建议吗？  

是否需要提高波特率？  如果是、那么建议值是什么？我们应该在哪里更改？ (RCP_CC26X2R1_LAUNCHXL_tirtos7_ticlang\platform\UART.C？)

谢谢

SEN

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

     我   在使用 LP-CC2652R7和 otbr (Raspberry PI)时遇到相同的问题

    + RCP 上的 LED 仍在闪烁。

    +出错时,otbr-agent 会在几秒钟后自动重新启动。 大约10秒后、它将成功重新启动。

    +长时间运行后(约3小时)，otbr-agent 无法启动。 按下 LP-CC2652R7上的 RESET 按钮、以便 otbr-agent 成功启动。

    我使用 ROV 监控 RCP 程序。

    任务堆栈内存是稳定的。

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

    您好、Quan：

    感谢您报告类似的行为。  软件开发团队将继续对此进行调查、您可以报告的任何其他发现都将被视为有用。

    此致、
    瑞安

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

    您好、Quan：

    TI 的软件开发团队对 TI OpenThread 解决方案的 UART 层进行了改进、以解决 SensorTag 观察到的 RCP 超时问题。 我已将解决方案离线提供给他们、但我们也提供了该解决方案、供您进一步评估使用。  请将现有的 platform/uart.c 文件替换为以下内容：

    e2e.ti.com/.../uart_5F00_v4.c

    此致、
    瑞安

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

    我尝试 新的 uart.c 代码。 但是、 它在运行大约 2小时后仍然出现错误。

    我的项目有5个节点。

    + 1x CLI_FTD (子网/路由器)

    + 1x CoAP 服务器/UI (路由器)

    + 2个传感器节点：每5秒发出一次带有有效载荷(大约80字节)的 CoAP 发布请求。

    + 1个 RCP (用于 OTBR)

    从 OTBR 机器对 CLI_FTD 节点执行 ping 命令 会导致错误更快出现。

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

    您好、Quan：

    感谢您提供问题的详细信息。  您是否能够仅通过 CLI_FTD 和 rcp 示例复制此行为，并且在增加流量时，复制速度是否比当前更快？ 在提供 UART 更新之前、您是否已经尝试了所有建议？

    此致、
    瑞安  

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

    我无法 重现此问题(使用新的 UART.c 代码)。 在我触发硬复位电路板后、它似乎可以长时间保持稳定。  如果问题再次出现、我将尝试重现此问题。

    如果我使用源代码(SDK：7.10.01.24、编译器：TI Clang、NCP 代码)、则在长时间运行后会出现此错误。

    我针对此错误编写了一个测试节点。

    github.com/.../ti-ot-rcp-bugtest