• 状态 Resolved
  • 已锁定 已锁定
  • 回复 10 回复
  • 订户 0 订户
  • 视图 453 视图
  • 用户 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.

[参考译文] CC1352R：器件有时&#39；丢失#39；地址短且无法访问

admin
Guru**** 2554270 points


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

https://e2e.ti.com/support/wireless-connectivity/sub-1-ghz-group/sub-1-ghz/f/sub-1-ghz-forum/1020991/cc1352r-device-sometimes-looses-short-address-and-becomes-unreachable

器件型号：CC1352R

我们发现我们的器件节点存在一个相当难调试(难以重现)的问题。

有时、网络中的设备会完全断开与网关的连接。 该器件仍具有响应能力(对传感器输入做出反应)、但 我们无法通过网络获取任何数据。

由于它只会在一段时间(甚至几周)内发生一次、 因此调试是非常不可能的、因为您永远不知道网络中哪个器件会发生故障(网络中大多数为20-30个器件)。 复位器件是退出此模式的唯一方法、然后它再次正常工作。

现在、我今天尝试使用卡在该"模式"中的器件时、使用监听器查看网络流量、发现它仍在发送数据、但具有"无效"目标 PAN (0xFFFF)和无效短地址(0xFFFF)。 目的地本身仍然正确。 (请参阅 Wireshark 的屏幕截图)。 在发生这种情况之前、这些值当然是正确的(0x6833和0x0001)。

因此、它看起来像是 MAC 层或传感器应用程序释放了目标 PAN 和短地址的值。

我们的应用基于 具有 SDK5.10的 DMM 传感器 OAD、但 SDK4.30也是如此。

是否有人建议设备为什么可以"丢失"关联数据？

我在代码中找到的唯一两个设置了这些值的位置是：disassocCnfCb 和 disassocIndCb、但此时所有数据都会被复位、然后目标地址也会被清除、但情况并非如此。

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

    您好、Marjin、

    嗯、这很奇怪。 我知道您会发现这很难调试！

    由于您说这是在启用了 OAD 的设备上、您是否看到了与执行的 OAD 相关的任何信息？ (是否可以是 PAN ID 和短地址作为 OAD 的一部分被覆盖？)

    您能否将调试器连接到故障传感器器件并读取传感器统计数据？  

    谢谢、

    Marie

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

    您好、Marie、

    是的、一个思维方向确实是它被覆盖、但我甚至不能确定无效数据是在应用程序中、还是 MAC 层本身具有无效数据。 我的意思是、如果我意外覆盖 

    devInfoBlock.devShortAddr

    我甚至不认为只有在我看到的重新启动器件后、它才会更新到 MAC 层。

    因此、我怀疑 MAC 层本身可能存在问题。

    正如您提到 的、调试很困难、尤其是当我要连接调试器时、器件将重新启动、问题就会消失。 为了连接调试器、并且"希望"该问题将出现在该特定器件上、可能需要数周甚至数月的时间。 大多数设备从未显示此问题。

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

    您好、Marjin、

    可以在不复位的情况下将调试器连接到正在运行的目标。 请参阅以下内容。

    https://e2e.ti.com/support/wireless-connectivity/bluetooth-group/bluetooth/f/bluetooth-forum/882926/faq-ccs-cc2640r2f-cc26x2-how-to-connect-the-debugger-to-a-running-target

    我不确定我是否能帮助您找出根本原因、因为我无法重现。 发生这种情况时、您是否有一个变通方法允许您重置设备？

    谢谢、

    玛丽·H.

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

    您好！

    非常感谢、我能够使用此解决方案连接到正在运行的器件、但只能连接到非生产器件。 我们的所有生产器件都具有锁定的闪存、因此它不会有所帮助。  之前忘记提到过它。

    我现在找到了一个权变措施、它也指向错误的方向。

    现在、我使用以下命令在时间间隔内检查 Mac 层中的当前 PanId 和源地址： 

    	reqStatus = ApiMac_mlmeGetReqUint16(ApiMac_attribute_panId, &currentPANId);

    和： 

    	reqStatus = ApiMac_mlmeGetReqUint16(ApiMac_attribute_shortAddress, &currentShortAddr);

    当其中任何一个为0xFFFF 时、我会记录该信息并重新启动器件。

    从日志中、我已经看到 周末在一台设备上发生了该问题。 这至少指向 MAC 层的方向、因为这是我要检查的内容、除了关联过程之外、应用程序中的任何位置都不会更改。

    此致、

    Marijn

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

    您好、Marijn、

    感谢您发帖。

    设备是否显示任何其他奇怪的问题？ 这是否是一般内存损坏问题？

    谢谢、

    玛丽·H.

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

    您好、Marie、

    除此 MAC 问题外、器件针对所有功能正常运行、因此看起来不太可能发生一般的存储器损坏。  我认为 MAC RF 内核有自己的存储器、不是吗？

    如果我理解拓扑是正确的、那么如果 MAC 返回0xFFFF、 那么最终的存储器损坏将位于射频内核中？

    我在故障器件上注意到、一般无线电"特性"并不像其他器件那样好。

    它具有3个 macAckFailures、4个通道访问故障、2个 synclossIndications、 worstCaseE2EDelay (1032)等  

    所有器件都位于同一个房间(testlab)中、因此应具有相同的条件。

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

    您好、Marijn、

    TI 15.4-Stack 使用 M4 RAM、但正确的是、无线电内核具有自己的 RAM。 如果 TI 15.4-Stack 的 M4 RAM 中存在内存损坏、我不确定将错误地址读取到 RAM 需要多长时间。

    很高兴听到有关统计数据的信息。 设备似乎尝试进入孤立模式、但在整个过程中失败了一半？

    我需要从软件开发团队获得一些意见。 您能告诉我您使用的是信标模式、非信标模式还是 FH 模式吗？ 以及您正在使用的 SimpleLink CC13x2/26x2 SDK。

    谢谢、

    玛丽·H.

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

    您好、Marie、

    是的、我们使用 SDK5.10的信标模式。

    我还看到其他奇怪的网络行为。

    有时、如果器件不再响应传入的消息、也会进入某种"插入"模式。

    我使用监听器进行了检查、网关将地址放在待处理的消息列表中、但器件从未执行数据请求。  

    但是、它会正确地发送消息。

    这也可能指向器件未 能处理孤立模式的方向？

    我已经尝试了、而不是执行孤立扫描、只执行同步请求 、但没有改进。

    还有其他建议吗？

    谢谢、

    Marijn

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

    您好、Marie、

    好的、我 做了一些进一步 的调试、发现了一些有趣的东西。

    我在状态消息中添加了日志记录、以包括当前网络状态和自动请求的当前状态。

    这是因为正如我在前一条消息中提到的、当网络问题发生时、器件仍然能够传输数据。

    现在我发现 、当出现网络问题时、如果网络状态为"重新连接"、则 autoclest 的值为 false。 这当然不是很好、因为只有在执行同步请求时、这才应该是错误的。

    因此、我认为需要实施一些更好的检查、以更好地管理网络。 我将在该领域做一些进一步的测试。

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

    您好、Marjin、

    是否可以从监听器日志中查看在器件短地址和 PAN ID 更改之前或之后是否发生了 ACK 故障和同步损耗？ 正如您所说的、设备可能会尝试进入孤立模式、但在某种程度上无法100%成功。

    谢谢、

    玛丽·H.