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:终端设备在暂停10分钟后恢复需要很长时间

Guru**** 2943030 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/1060039/cc2652r-end-device-takes-very-long-to-resume-after-pause-for-more-that-10-minutes

器件型号:CC2652R
Thread 中讨论的其他器件:Z-stack

客户正在测试 Zstackapi_puseResumeDeviceReq API、以便暂停和恢复终端器件。 他们能够使用此 API 暂停器件、如果器件暂停后立即调用 Zstackapi_puseResumeDeviceReq、器件将顺利重新加入网络。 但是、 如果器 件暂停约12-13分钟、则在调用 Zstackapi_puseResumeDeviceReq 后、终端器件将需要18分钟才能重新加入。

根据监听器登录附件、当问题发生时、终端设备可以发送信标请求、协调器以信标:NwkClosed 进行响应。 但之后、终端设备不会立即发送重新加入请求、并且设备状态会保持在 UART UI 的"发现"状态。 大约18分钟后、终端设备最终会发出重新加入请求、并能够成功重新加入。

正常暂停和恢复:

当问题发生时:

我正在尝试对此进行调试、但对 Zstackapi_pauseResumeDeviceReq 的 工作原理了解有限。 请帮助您了解从何处开始调试此问题。 SDK 5.30中的 zc_light 和 zed_SW 示例可能重现此问题、并进行了一些修改、以便能够使用 LaunchPad 上的按钮调用 API:

static void zclSampleSw_processKey(uint8_t key, Button_EventMask buttonEvents)
{
    if (buttonEvents & Button_EV_CLICKED)
    {
        if(key == CONFIG_BTN_LEFT)
        {
            // Use left button for pause
            zstack_pauseResumeDeviceReq_t zstack_pauseResumeDeviceReq = { 0 };
            zstack_pauseResumeDeviceReq.pause = true;
            Zstackapi_pauseResumeDeviceReq(appServiceTaskId, &zstack_pauseResumeDeviceReq);
        }
        if(key == CONFIG_BTN_RIGHT)
        {
            // Right button for resume
            zstack_pauseResumeDeviceReq_t zstack_pauseResumeDeviceReq = { 0 };
            zstack_pauseResumeDeviceReq.pause = false;
            Zstackapi_pauseResumeDeviceReq(appServiceTaskId, &zstack_pauseResumeDeviceReq);
        }
    }
}

谢谢。

此致、

水阳

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

    您好、Shuyang、

    通常不建议使用此 Z-Stack API、因为它通常不被典型 Z-Stack 操作使用、也不包含在默认情况下的任何应用示例中。  我不知道软件开发团队上次测试/验证的时间。  无论如何、如果您想进一步调试、请注意、此 API 最终会  根据 暂停值调用 ZDUP_PauseNWK 或 ZDUP_ResumeNWK。  您可能需要特别注意 bdb_parentLost 的行为、并可以进一步考虑改用 SysCtrlSystemReset 来简单地重新启动器件。  虽然不是直接相关的、但此问题可能与 另一个 E2E 主题中注意到的行为有些相关 、目前正在调查此问题的解决方案是否涉及低级 MAC。  使用这些 API 时、功耗是否会受到影响?应用的轮询速率是多少?

    此致、
    Ryan

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

    您好、Ryan、

    我针对此问题进行了一些调试,发现 在问题发生时,永远不会调用 ZDO_NetworkDiscoveryConfirmCB。 由于问题仅在暂停命令的特定时间后发生、是否可能关闭 RX 并且在特定的超时后无法正确重新打开?

    在示例代码中、电源策略和轮询速率保持为默认值。

    此致、

    水阳

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

    您好、Shuyang、

      应用 ZDUP_ResumeNWK 后、会应用 bdb_parentLost、然后应用程序负责尝试重新加入网络。  这是通过器     件从*_CommissProcessingStatus 进入 BDB_commissioning_parent_lost case 来实现的,该 case 最终会从 zclSampleSw_process_loop 调用 Zstackapi_BdbRecoverNWKREQ 进入 SampleApp_end_device_resist_EVT。  这将转而使用 processBdbRecoverNWKREQ -> bdb_recoverNWK -> ZDOInitDevice。  您能确认所有这些都在发生吗?  您是否可以测试是否从  ZDApp_ResumeNwk 中删除 NWK_SetCurrentPollRateType (POLL_RATE_DISABLED,FALSE);因为这将是器件进入 bdb_parentLost 时的预期行为。  否则、逻辑与 ZED 非常相似、因为其父级停止响应、因此应立即重新加入网络

    此致、
    Ryan

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

    您好、Ryan、

    所有步骤都已执行。 该器件能够发送信标请求、但绝不会进入信标响应的回调。

    我还尝试删除 了 NWK_SetCurrentPollRateType( POLL_RATE_DISABLED,FALSE );它不起作用。

    此致、

    水阳

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

    您好、Shuyang、

    感谢您继续帮助调试此问题、因为我目前由于其他问题无法复制此行为。  我相信您是正确的、因为通过在 bdb_parentLost 内调用 ZMacSetReq 来关闭 RX 可能会导致问题。  接下来、我想让您 尝试将 bdb_parentLost 替换为 bdb_rejoinNWK、或在 ZDApp_ResumeNWK 中将其完全删除、并查看它如何影响器件的性能。

    此致、
    Ryan

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

    您好、Ryan、

    如果 将 bdb_parentLost 替换为 bdb_rejoinNWK、则终端设备在恢复后不会发送定期数据请求。 但是、完全删除 bdb_parentLost 似乎可以正常工作。

    我还进行了测试、并在   bdb_parentLost 内部注释掉了 ZMacSetReq 调用、这似乎也解决了问题、因此终端设备能够在13分钟后正常重新加入。 我认为您对 ZMacSetReq 很正确、尽管我不理解它的确切原因、也不理解它为什么仅在 ZDApp_PauseNWK 调用的特定时间段之后发生。

    此致、

    水阳

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

    您好、Shuyang、

    因此、您认为删除 bdb_parentLost 和/或 ZMacSetReq 完全 可以解决客户的问题?  我怀疑自从孤立进程和数据轮询管理发生变化以来、这些 API 已经过评估。  我将与此软件开发团队跟进以解决此 API 问题。  正在不断改进 IEEE MAC、这可以改善暂停时序的依赖性

    此致、
    Ryan

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

    您好、Ryan、

    我无法执行全面测试来验证此更改的潜在风险、我只能观察到在进行此更改后、终端设备能够重新加入网络并向协调器发送开/关命令。 如果您可以跟随研发团队来完全解决问题、那就非常好、非常期待错误修复、谢谢!

    此致、

    水阳