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

[参考译文] CC2530：ZNwkTable 填满后、ZNP 停止正常工作- ZSTACK3.0.2

admin
Guru**** 2578945 points
Other Parts Discussed in Thread: Z-STACK

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/958348/cc2530-znp-stops-working-properly-after-znwktable-full---zstack3-0-2

器件型号：CC2530
Thread 中讨论的其他器件：Z-stack

我使用 ZigBee-linux-sensor-to-cloud_1.0.1网关和 Z-Stack 3.0.2执行了新的调试会话。
我创建了这个相关问题、以便更轻松地了解我们所讨论的测试。


这一次关联起作用、但发生 NwkTableFull 时、系统再次出现功能障碍。

通过将此跟踪与父级相关(父级)问题进行比较、还可以了解为什么关联在此处工作、而不在父级问题中工作。

第一台设备可能重新加入，因为它是在未打开网络的情况下添加的。
第二个器件在无需用户干预的情况下启动关联。


[2020-11-20 14：28：22.193878][NWK_MGR/HNDL]调试：- 0xCCCCCCFFFE3A2F33上的附加设备完成
[2020-11-20 14：30：29.623221][NWK_MGR/HNDL]调试：-在0x70B3D5B13001011E 上添加设备完成
[2020-11-20 14：30：50.081206][NWK_MGR/HNDL]调试：-在0x00158D00047B8369上添加设备完成
[2020-11-20 14：32：16.614576][NWK_MGR/HNDL] debug：- 0x000D6F0012A0CCF8上的 AddDevice Complete
[2020-11-20 14：32：31.549518][NWK_MGR/HNDL]调试：- 0x00124B000760BB0A 上的附加设备完成
[2020-11-20 14：33：56.656909][NWK_MGR/HNDL]调试：- 0x70B3D5B13001011E 上的附加设备完成

然后、从下一个点开始(ZNwkTableFull)、ZNP 停止正常运行：

[2020-11-20 14：39：42.804931]>[ZDO/SRSP]** EXT_route_DIST** ZNWKTableFull (SYS：5/TYPE：60/CMD：45)(6)：FE 01 65 45 C7 E6.


虽然可以增加 NWKTable 大小、但表大小不足不应导致 ZNP 分段。

此外、我不了解在当前情况下如何填满 NWKTable、也不知道如何清除它。

我检查了源代码、发现表大小设置为常量"变量"、以便可以将它们传递到作为编译库提供的 NLME。 当然、我无法检查 NLME 源代码。

我没有看到如何为这些表分配内存、因此我假设这是在库中使用 osal_malloc 等完成的。

希望我们(=TI & I)可以解决这个问题。


日志照常加入。

e2e.ti.com/.../AssociateOkThenNwkTableFullBreaksSystem.zip

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

    您好、Mario、

    在一个或另一个点加入网络的设备总数是多少？  在清理表条目时、您可以尝试要求过时/不需要的项目离开 ZDO_Mgmt_leave Req、或使用 ZDO_SEC_DEVICE_REMOVE 和/或 ZDO_EXT_SEC_APS_REMOVE_REQ 在本地手动删除此信息。  以下是一些相关的 E2E 主题：

    https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/940819/
    https://e2e.ti.com/support/wireless-connectivity/zigbee-and-thread/f/158/t/892062/ 

    我可以在监听器日志中看到、ZNP 在看似随机的时刻停止通信、并且最近没有任何值得注意的网络操作。  这就增加了内存泄漏的可能性。  我还注意到、它从不响应来自 ZED 的重复 IEEE 地址请求。  一旦您能够调试 ZNP、最好在 ZDP_IncomingData -> zdpProcessAddrReq 内设置一个断点、并确定为何从未返回响应。  一旦 ZNP 被复位、您能提醒我该行为吗？

    此致、
    Ryan

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

    这是文本 UI 中显示的设备列表： 

    00：12：4B：00：10：22：82：77 0000 01组合接口<0501>| F2 0061 (A1E0)
CC：CC：CC：FF：FE：3A：2F：33 69F6 01 0301 (HA)<000a：0000><000A ><0020><0201：0000><0201：0012><0204><b0204>
70：B3：D5：B1：30：01：1E 8C47 0E 0053 (HA)<0b04><0702><0b01><000a>
00：15：8D：00：04：7B：83：69 79D8 01温度传感器 0402><0403：B5B2><0403：02B9><0403：0000><0403：02BC><0403>
00：0D：6F：00：12：A0：CC：F8 F2AB 01 IAS 区域<0001：B5B2><0001：02A4>、已注册/FIRST_SENSOR <0500>
00：12：4B：00：07：60：BB：0A Daba 01 IAS 区域<0000：0004><0000：0005><0000：0007>、未注册/区域未分配、空闲<0500>

    这对应于添加的器件总数。  其中一个被"添加"两次： 

    $ grep 'AddDevice Complete' AssociateOkThenNwkTableFullBreaksSystem.log
[2020-11-20 14：28：22.193878][NWK_MGR/HNDL]调试：-在0xCCCCFFFE3A2F33上完成 AddDevice
[2020-11-20 14：30：29.611-23221][NWK_MGR/HNDL]调试：-在0xCC0001120-020-01820-020-02020-020-020_6420-020_N 上

完成[1206420-0456_6420-0456_6420][N00020-0456_6420_N：N606420-020_N：N0006420_N：N000122020-020-020-020_N：202020202020202020_N：N606420_N：N606420-020_N 调试：0456_6420][在器件：N606420_N 上完成：N0006420_6420_6420_N：
- 0x00124B000760BB0A 上的 AddDevice Complete
[2020-11-20 14：33：56.656909][NWK_MGR/HNDL]调试：- 0x70B3D5B13001011E 上的 AddDevice Complete

    我仅对 ZNP 执行了复位，它仍然报告“无效参数”，更新其 ZNWKTableFull 消息，并在 route_disc 上返回一些 ZSuccessess 消息。

    我在日志中记录这种情况。

    可以看到复位是有效的： 

    [2020-11-20 20：50：31.790175]>[SYS/AREQ]** RESET_IND** EXTRST (1)协议2产品 ID 2 SWVer 2.7.2 (SYS：1/TYPE：40/CMD：80)(11)：FE 06 41 80 01 02 02 02 02 02 02 02 C1

    关于 ZNP 的调试、我要对其进行设置。

    e2e.ti.com/.../1563.AssociateOkThenNwkTableFullBreaksSystem.zip

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

    我成功设置了调试环境、但在"CC2531-Debug"配置文件中没有 SBL。
    由于 SBL 扇区保护、我不得不擦除整个存储器、但还无法重现问题。
    我还添加了一个配置、将 NWK_TABLE 减少为该器件设置中的原始设置。

    "TI"可能会建议仅为路由器和协调器修改这些值、而不是为终端设备修改这些值(因此应该有适当的#ifdef)。

    为了重现与 ZNWKTableFull 相关的问题、可以减小表的大小、以便更轻松地触发 TableFull 条件、并希望结果出现不必要的行为。

    现在、我们只需使用现有日志即可识别此问题。

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

    实际上，还有一个类似的情况，可以在先前作为  AssocNonReported_ZNP_KO 的日志中找到。

    在这两种情况下、通常情况是在复位后报告 ZNwkTableFull：

    这是另一个日志中的第一个 ZNwkTableFull: 

    [2020-11-08 17：37：38.924501]>[ZDO/SRSP]** EXT_route_DIST** ZNWKTableFull (SYS：5/TYPE：60/CMD：45)(6)：Fe 01 65 45 C7 E6.

     在这种情况 下，ZNwkTableFull 出现在复位后和 ZInvalidParameter 之前。

    在本主题中报告的情况下 ，首先显示 ZInvalidParameter，然后显示 ZNWKTableFull 。  但这是因为请求 AF_DATA_Request_EXT 和 ZDO_EXT_route_DISC 的顺序。

    因此，在复位时会发生这种情况，它会“立即”地执行 AF_DATA_Request_EXT 和 ZDO_EXT_route_DISC。 。  这将减少可能性。

    此处是此处 报告的日志链接：e2e.ti.com/.../5047.AssocNonReported_5F00_ZNP_5F00_KO.zip

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

    我确定了此问题的根本原因、该问题与 ZNP 的工作方式和网关限制有关、我必须加以改进。

    因此、您不再需要对此进行调查、您可以集中精力解决另一个仍处于打开状态的问题。