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

[参考译文] LAUNCHLL-CC26X2R1：重新启动zigbeeHAgw (&amp；start_application)脚本使Zed无法加入网络。

admin
Guru**** 2467600 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/1089028/launchxl-cc26x2r1-re-start-zigbeehagw-start_application-scripts-makes-zed-cannot-join-network

部件号：LAUNCHTXL-CC26X2R1
主题中讨论的其他部件：Z-stack

我使用CC2652R1 LaunchPad作为金色的Zed，它以zed_temperaturesensor (5_20_00_52)编译闪存。

我下载的Zigbee Linux Gateway是Zigbee_3_0_Linux_Gateway_1_0_1.ru。 我已经在 x86 PC主机上进行了本机构建，并与另一 台CC2652R1 LaunchPad (通过USB使用标准ZNP FW刷新)进行了交谈。

使用两个脚本文件(zigbeeHAgw和start_application)运行并成功测试Zed加入网络。

但是，当我退出并重新启动两个脚本时，Zed不能在没有拔下USB的情况下加入。 拔下USB并再次运行时，情况正常。

下面列出了正常和异常情况下的缺口日志：

===正常大小写===

[15:03:01.CMT] 89.0776万 [Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x8 #<="ZStack_CMD_IDS__SYS_Nwk_INFO_READ_REQ"
[15:03:01.NPISR/MAIN] 89.0872万 ：#PETER#接收消息...
[15:03:01.UNMSKBL][NPISRVR/MAIN ] 89.0905万 ：#PETER# NPI_UART_SendSynchData: cmdId:80#
[15:03:01.KPI][NPISRVR/MAIN ] 89.0938万 ：#PETER# NPI_Sendframe：：37，cmdId：80确定。 #
[15:03:01.NPI][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，89.5052万 ：0x65，Cmd ID：0x50，长度：24 <= NPI识别此帧！
[15:03:20.Cbcb: 93.945万 subsystemID:0x31, cmdId:0x43 #<="ZStack_CMD_IDS__ZDO_Mgmt_permit_join_Req"([15:03:20.Cb][Z_stack/LSTN]] UNMSKBL：#PETER# zstackpb zspbHandlePbHandlePbCb：subsystemID:0x31，cmdId:0x43
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 93.9538万 ：#PETER#接收消息...
[15:03:20.UNMSKBL][NPISRVR/MAON] 93.957万 ：#PETER# NPI_UART_SendSynchData: cmdId:80#
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 93.9603万 ：#PETER# NPI_sendframe：：37，cmdId：80确定。 #
[15:03:20.NPI][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，94.3672万 ：0x65，Cmd ID：0x50，长度：24 <= NPI识别此帧！
[15:03:20.NPI] 94.3854万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：0x5，cmdID：0x36，len：：：5
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 94.3931万 ：#PETER#接收消息...
[15:03:20.UNMSKBL][NPISRVR/MAON] 94.396万 ：#PETER# NPI_UART_SendSynchData: cmdId:54#
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 94.3985万 ：#PETER# NPI_sendframe：：37，cmdId：54确定。 #
[15:03:20.NPI][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，94.7575万 ：0x65，Cmd ID：0x36，长度：1 <= NPI识别此帧！
[15:03:20.UNMSKBL][Z_STACT/LSTN] 94.7724万 ：#PETER# zstackpb processZdoMgmtPermitJoinRequest：duration：60 #
[15:03:20.NPI] 94.7746万 [Z_STACT/LSTN] UNMSKBL：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：0x5，cmdID：0x36，len：：：5
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 94.7811万 ：#PETER#接收消息...
[15:03:20.UNMSKBL][NPISRVR/MAON] 94.7838万 ：#PETER# NPI_UART_SendSynchData: cmdId:54#
[15:03:20.UNMSKBL][NPISRVR/MAIN ] 94.7874万 ：#PETER# NPI_sendframe：：37，cmdId：54确定。 #
[15:03:20.NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCE帧，子系统：0x45，94.8437万 ID：0xB6，长度：3 <= NPI找到Cmd ID：0xB6 (RSP)
[15:03:20.UNMSKBL][Z_STACT/HNDL] 94.8578万 ：#PETER# ZNP_MISC handle：Subsys:5, cmdID:0xb6#
...

===异常情况===

[15:06:39.Cbcb][Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb 17.8873万 ：subsystemID：0x31，cmdId：0x8 #<="ZStack_CMD_IDS__SYS_Nwk_INFO_READ_REQ"
[15:06:39.UNT][NPISRVR/MAIN ] 17.9034万 ：#PETER#接收消息...
[15:06:39.Syntc][NPISRVR/MAIN ] 17.907万 ：#PETER# NPI_UART_SendSynchData: cmdId:80#
[15:06:39.KPI][NPISRVR/MAIN ] 17.9107万 ：#PETER# NPI_Sendframe：：37，cmdId：80确定。 #
[15:06:39.NPISR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，18.3141万 ：0x65，Cmd ID：0x50，长度：24 <= NPI识别此帧！
[15:06:56.CMB] 35.3052万 [Z_STACT/LSTN] UNMSKBL：#PETER# zstackpb zspbHandlePbCb：subsystemID：0x31，cmdId：0x43 #<="ZStack_CMD_IDS__ZDO_Mgmt_permit_join_Req"
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 35.3144万 ：#PETER#接收消息...
[15:06:56.UNMSKBL][NPISRVR/MAON] 35.3179万 ：#PETER# NPI_UART_SendSynchData: cmdId:80#
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 35.321万 ：#PETER# NPI_sendframe：：37，cmdId：80确定。 #
[15:06:56.NPISR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，Subsys：0x65，35.7287万 ID：0x50，长度：24 <= NPI识别此帧！
[15:06:56.UNMSKBL][Z_STACT/LSTN] 35.746万 ：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：0x5，cmdID：0x36，len：：：5
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 35.7532万 ：#PETER#接收消息...
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 35.7559万 ：#PETER# NPI_UART_SendSynchData: cmdId:54#
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 35.7584万 ：#PETER# NPI_sendframe：：37，cmdId：54确定。 #
[15:06:56.NPISR/U_RX] UNMSKBL：#PETER#[UART] NPI_procframe，36.0318万 ：0x65，Cmd ID：0x36，长度：1 <= NPI识别此帧！
[15:06:56.UNMSKBL][Z_STACT/LSTN] 36.0463万 ：#PETER# zstackpb processZdoMgmtPermitJoinRequest：duration：60 #
[15:06:56.UNMSKBL][Z_STACT/LSTN] 36.0487万 ：#PETER# ZNP_MISC sendNPIExpectDefaultStatusZNP：Subsys：0x5，cmdID：0x36，len：：：5
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 36.0548万 ：#PETER#接收消息...
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 36.0576万 ：#PETER# NPI_UART_SendSynchData: cmdId:54#
[15:06:56.UNMSKBL][NPISRVR/MAIN ] 36.06万 ：#PETER# NPI_sendframe：：37，cmdId：54确定。 #
[15:06:56.RMS][NPISRVR/U_RX] UNMSKBL：#PETER#[UART] NPI_PROCframe，36.3693万 ：0x65，Cmd ID：0x36，长度：1 <=无RSP...

下面列出了一些症状：  

1.超帧内的关联位设置不正确。 第二次测试显示的值为0，而不是值1。 (注意：其他位与首次测试相同)

2.对于两个案例的最后“NPIVR/U_RX”日志，其子系统值不同。

两 个问题：

1.在脚本重新启动时，如果不拔下USB或重新启动ZNP FW以使其正常运行，我是否需要执行额外的步骤？

2.如何解释 Subsys？

此致，

彼得。

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

    您好，Peter，

    请告诉我以下E2E帖子中的任何一个是否可以解决您的问题：

    https://e2e.ti.com/f/1/t/85.0677万 
    https://e2e.ti.com/f/1/t/93.8713万 
    https://e2e.ti.com/f/1/t/94.0644万 
    https://e2e.ti.com/f/1/t/102.4945万 

    无论如何，在 Zigbee网关主机上实施的几项改进都是很好的。

    subsystemId是 在 hal_rpc.h中定义的RPC命令字段类型和子系统的组合  

    此致，
    Ryan

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

    您好，Ryan：

    感谢您的反馈。 我在检查了你提供的上述帖子后，有以下暂定评论：

    - e2e.ti.com/.../85.0677万 ：GW初始化失败。 不是我的情况。
    - e2e.ti.com/.../93.8713万 ：Z-Stack相关。 我的问题应该发生在NPI与ZNP FW之间(由于没有0xB6 RSP)？
    - e2e.ti.com/.../94.0644万 : so_reset_required settings. x86设置为0。 应该可以。
    - e2e.ti.com/.../102.4945万 通过路由的配对问题。 不是我的情况。 我正在测试Zed to Coordinator Case。

    我使用"软重置"进行了测试，这也会重新启动服务器。 在这种情况下，我可以重新加入Zed。 所以我的问题是：

    软重置将发送CMD："Nwk_Mgr_CMD_ID_T__Nwk_ZigBee_system_reset_Req"。 在ZNP FW方面，软重置和重新启动zigbeeHAgw脚本之间的命令区别是什么？ 或者告知我可以在哪里检查？

    顺便提一下，有两个hal_rpc.h文件(./projects/ZStack/linux/srvwrapper/hal_rpc.h &./projects/ZStack/linux/RemoTI-linux-master/projects/tools/LinuxHost/ipclib/common/hal_rpc.h)。 但这两种情况有一些细微的差别。 我认为我们应该对包括NPI服务器在内的所有服务器代码使用"./projects/ZStack/linux/srvwrapper/hal_rpc.h"。 我对吗？

    此致，

    彼得。

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

    软重置将导致ZNP固件的软件重置命令，而重新启动zigbeeHAgw脚本仅影响主机软件操作。

    您可以使用srvwrapper版本，因为 RPC_SYS_PROTOBUF通常被其他源文件引用。

    此致，
    Ryan

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

    您好，Ryan：

    对于软重置测试，我与zigbeeHAgw进行了检查，发现它将等待网络管理器停止，如“Wait $NETWORK_Mgr_PID && EXIT_CODE=$?”中所说。 当 我设置软复位命令时，zigbeeHAgw将调用stop_all。 因此，软重置也将首先停止所有服务器。 但是，在x86 PC主机环境中，我发现返回代码为0而不是2。 由于返回代码为0，zigbeeHAgw  仍将调用START_ALL (& HW_RESET_SOC)。 三 个问题：

    1.它应该有返回代码2 (NWKMGR_Soft_reset_code)，但我得到 了调试值0。 在哪里设置网络管理器的返回值？

    2.变量 NWKMGR_RESTART_FLAG的用途是什么？  

    3. HW_RESET_SOU()的用途是什么？ 是通用代码还是依赖于平台？

    此致，

    彼得。

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

    1.这是一个意外的退出代码，可能意味着NWKMGR或其他网络服务器已经退出。

    2.它可以在start_netmgr上得到响应，以便用户知道重新启动的原因。 https://e2e.ti.com/f/1/t/94.0644万 

    3.这 用于硬件重置，即保持RST引脚处于低位，然后松开。 SOC_RESET_HOLT/SOC_RESET_RELEASE可根据USB重置要求的平台而定。

    此致，
    Ryan

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

    您好，Ryan：

    谢谢。 稍后进行软重置时，我将调查有关返回代码问题的更多信息。 症状是：我在ARM平台上得到了值2，但在PC x86上得到了值0。

    我的最后一个问题是：为什么手动重新启动(重新启动zigbeeHAgw脚本和start_application脚本)会导致允许联接失败？ 请参阅软重置，允许再次加入是可以的。 其步骤可分解为三个步骤：STOP_ALL，HW_RESET_SoC和START_ALL。  "软重置"和"手动重新启动"之间的区别仅为HW_RESET_SoC。 我对吗？  因为x86没有对HW_RESET_SoC执行任何操作。 我很困惑。

    此致，

    彼得。

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

    在zigbeeHAgw中 ，对于x86，SOC_RESET_required设置为零。  您可以更改此设置以强制在START_ALL上使用HW_RESET_SoC。  我建议重置ZNP MCU以允许系统之间的同步。  请参阅 此E2E帖子 ，了解有关由于从网关删除ZDO端点而导致的允许加入失败的已知问题。

    此致，
    Ryan

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

    您好，Ryan：

    我认为您误解了我的问题。 我测试的平台是x86 PC，我正在询问第二次重新启动问题。

    用于首次启动，使用zigbeeHAgw和start_application手动运行。  SOC_RESET_REQUIRED 设置为零。 联接测试正常。

    第二次，有两种方法：一种是"手动终止zigbeeHAgw和start_application并重新启动"；另一种是"使用软重置命令"。

    对于"manually kill zigbeeHAgw and start_application and re-start again"， SOC_RESET_required为值零。 但对于"使用软重置命令"， SOC_RESET_required设置为值1，该值将调用 HW_RESET_SoC。  现在，HW_RESET_SoC对x86不执行任何操作。

    我对测试结果感到困惑： "Manually kill zigbeeHAgw and start_application and re-start again"，Join test is not OK，but "using soft reset command" way，join test is fine (手动终止zigbeeHAgw和start_application并重新启动)。

    此致，

    彼得。

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

    可能 HW_RESET_SoC会导致ZNP在 重新启动后与应用程序正确同步所需的延迟，否则我不理解如何解决此问题，并建议您实施已知有效的解决方案。

    此致，
    Ryan