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 -更新完成节能模式下的通信

Guru**** 1129500 points
Other Parts Discussed in Thread: CC2530, Z-STACK, CC2531
请注意,本文内容源自机器翻译,可能存在语法或其它翻译错误,仅供参考。如需获取准确内容,请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1284423/cc2530---newer-finishes-commisioning-in-power-saving-mode

主题中讨论的其他器件:CC2530Z-stackCC2531

硬件 :CC2530
软件 : Z-Stack 3.0.2
编译器 : IAR 10.30
协调器 :Zigbee2MQTT

基础知识
我使用一些用作终端器件并连接到 Zigbee2MQTT 提供的网络的 CC2530器件。 它们是带有两个按钮的简单开关:

P2.0用于调试。
P0.1用作开关。
两个引脚都使用中断。

案例
我使用 GenericApp 作为项目的基础、然后合并了 SampleSwitch 的部分以启用开关功能。 它运行得很好。 刷新闪存后、当我开始调试过程时、器件会成功连入网络、接受采访并进行配对。 它还会发送开/关命令、一切都很好。

static void zclGenericApp_HandleKeys( byte shift, byte keys )
{
  if ( keys & HAL_KEY_SW_1 )
  {
    bdb_StartCommissioning(BDB_COMMISSIONING_MODE_NWK_STEERING);
  }
  if ( keys & HAL_KEY_SW_6 )
  {
    if (isToggleSet1) {
        zclGeneral_SendOnOff_CmdOn( GENERICAPP_ENDPOINT, &zclGenericApp_DstAddr, FALSE, bdb_getZCLFrameCounter() );
    } else {
        zclGeneral_SendOnOff_CmdOff( GENERICAPP_ENDPOINT, &zclGenericApp_DstAddr, FALSE, bdb_getZCLFrameCounter() );
    }
    isToggleSet1 = !isToggleSet1;
  }  

  if ( keys & HAL_KEY_SW_5 )
  {
  } 
}

但是、终端设备由电池供电、需要进入节能模式。 为了实现这一点,我做了以下工作:

将 power_saving 作为编译器选项。
在 f8wConfig.cfg 中、RFD_RCVC_ALWAYS_ON 设置为 FALSE。

问题
使用这些设置对器件进行刷写并启动调试过程后、该过程会启动但突然停止。 根据日志,设备已加入网络,但未能通过访谈:

2023-10-24 19:38:15 Zigbee2MQTT started!
2023-10-24 19:38:36 Device '0x00124b00279e698d' joined
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00279e698d","ieee_address":"0x00124b00279e698d"},"type":"device_joined"}'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x00124b00279e698d"},"type":"device_connected"}'
2023-10-24 19:38:36 Starting interview of '0x00124b00279e698d'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x00124b00279e698d","ieee_address":"0x00124b00279e698d","status":"started"},"type":"device_interview"}'
2023-10-24 19:38:36 MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x00124b00279e698d"},"type":"pairing"}'
2023-10-24 19:40:54 Failed to interview '0x00124b00279e698d', the device has not been successfully paired.

我怀疑这个问题与 Zigbee2MQTT 有关、因为它在没有节能的情况下完美运行。 即使我使用的是具有极少定制的标准示例应用程序、该问题也必须在某处与我的代码相关。

我怀疑器件在调试过程完成之前会进入节能模式。 但是,我不知道为什么会发生这种情况。 我完全陷入了困境。

作为最后的手段,我恳请你的帮助。
请询问可以帮助确定问题的任何代码片段、文件等。 只是为了澄清一下、我没有机会接触到监听器。

指向此处可以看到源文件的链接:

https://1drv.ms/f/s!AtnMB8Vx3S_EhdcPuJy_ROEDifG8hw?e=1WZf66

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

    我建议您使用嗅探器来检查通过无线电发生的确切情况。

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

    您好,伊凯

    感谢您的答复。

    我将尝试让监听器启动并运行。 敬请期待!  

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

    您好,伊凯

    我现已购买作为监听器的 CC2531 USB 软件狗。 并计划使用 Wireshark。
    遗憾的是、交付将需要大约3周。

    在没有活动的情况下、该主题将会打开多长时间? 是否会在3-4周内自动关闭?
    如果是-我"只是"必须在一段时间内置一条评论以保持它的活力?

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

    尊敬的 Flemming:

    器件似乎已正确加入和连接、休眠 ZED 可能会按预期运行、但 ZC  Zigbee2MQTT 不希望与轮询器件进行通信。  如果面试过程通过广播消息或直接消息进行通信而无需等待来自 ZED 的数据请求、则通信将失败。  在器件加入时可以避免这种情况、因为有几条消息是如此连续的、但在 ZED 完全加入后速度会变慢、并且其轮询速率会降低。  您可以查看 Z-Stack 3.0.2\Documents\CC2530\Power Management 以获取 CC2530.pdf 文档、并联系 zigbee2mqtt 团队以获取其他想法(我知道 参与其中、有时在 E2E 上处于活跃状态)。

    E2E 主题帖会在处于静止状态四周(即没有新回复)后自动关闭。

    此致、
    瑞安

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

    您好、Ryan

    感谢您的反馈!

    这实际上是有道理的。 我 按照您的建议浏览了电源管理文档、其中首先给了我一些建议。

    如果失败、我将尝试联系 Zigbee2MQTT 团队以获取其观点。

    此致

    弗莱明

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

    您好、Ryan

    如前所述、在联系 Zigbee2MQTT 团队之前、我希望执行更多的测试。 我的目标是为他们收集尽可能多的信息。

    我计划测试如果器件正确配置为睡眠设备、但从不实际进入睡眠模式时会发生什么情况。 其理念是查看断电是否以某种方式影响与 Zigbee2MQTT 的调试通信、就像在调试过程中器件只是被关闭一样。

    我的测试方法是强制设备不进入睡眠模式、在 OSAL.c 中注释掉"osal_pwrmgr_powersecee ()"以实现这一点。

    OSAL.c

    #if defined( POWER_SAVING ) && !defined(USE_ICALL)
      else  // Complete pass through all task events with no activity?
      {
        //osal_pwrmgr_powerconserve();  // Put the processor/system into sleep
      }
    

    现在、设备未进入睡眠模式、但调试问题仍然存在。

    此行为是否会改变您对投票率的建议的看法?

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

    鉴于 ZC Zigbee2MQTT 日志中显示了 device_joined 和 device_completed、假设调试过程成功并已完成。  由于 您的权变措施并未由 TI 内部进行测试、您需要验证 ZED 是否接收并处理了 DEVICE_INTERMEASE_MEASING 和配对消息。  这可以通过监听器日志比较或通过 zcl_ProcessMessageMSG 进一步调试传入的消息来完成。   

    此致、
    瑞安

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

    好的-谢谢。

    我会等待监听器到达。 任何其他东西现在都只是猜来猜去的效果。

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

    正在等待监听器... 我按照你的建议查看了 zcl_ProcessMessageMSG、看看我能否在此期间弄清楚一些东西。
    问题是、我实际上让它正常工作!

    设备开始调试、我在此过程中收到这些响应 AF_INcoming_MSG_CMD / ZCL_PROC_SUCCESS、然后设备进入睡眠状态。 大获成功!

    目前、我仅使用这些保守的设置:
    -DRFD_RCVC_ALWAYS_ON=false
    -DPOLL_RATE=1000
    -DQUEUED_POLL_RATE=100
    DRESPONSE_POLL_RATE=100
    -DREJOIN_POLL_RATE=440

    但它仅在调试模式下工作。 当我创建十六进制文件并将其上传到器件中时、不起作用。 设备开始试运转、但没有 AF_INTING_MSG_CMD / ZCL_PROC_SUCCESS 响应(我对 LED 进行了一些检查)。


    什么原因可能导致在调试模式和芯片编程之间出现这种不同行为? 有什么建议可供参考?

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

    我感谢您提供最新消息。  您的 CC2530器件是否连接了正在工作且可靠的外部 LF 晶振?  这 对于低功耗待机操作而言可能是必要的、如果没有它、器件在尝试进入睡眠状态时会失败。  与调试模式的区别可能在于 JTAG 强制器件保持活动状态、因此它会像以前一样继续运行。

    此外、您是否会考虑在 SIMPLELINK-LOWPOWER-SDK 上升级到 CC2652RX 或其他类似器件? 这将为您提供最新、最可靠的 Z-Stack 解决方案、而且完成的任务远不止 CC2530。

    此致、
    瑞安

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

    感谢您的快速回复。

    遗憾的是、目前无法选择 CC2652RX 等 CC2530的替代产品。

    晶振:
    此器件基于 EBYTE 的 E18-MS1-PCB 模块。 该模块是众所周知的、可以在其他应用中进入睡眠模式。 所以,我不
    怀疑晶振有问题。 这对于这款久经考验的模块来说是不可能的。

    JTAG:(我使用'CC 调试器'进行调试)
    我不是很确定你的意思。 您是说它只在调试期间被强制保持激活状态吗? 因为该器件实际上在使用"CC 调试器"成功调试后进入睡眠模式。 我可以从 LED 关闭和降低的功耗中看到这一点。 另一件事必须发生。

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

    您是否在多个 EBYTE 模块上进行了测试?  可能是由于 ESD 或过压等外部因素造成的、特定电路板上的晶体出现故障。  此外、您有没有任何方法可以通过用户界面(您可能有一个可访问的 LED)或 Zigbee 消息来确认 CC2530器件 相对于捕获在 HAL 断言或冻结状态而言仍在积极处理应用和网络信息?  如果 ZED 连接到 TI ZC、例如 SampleLight 或 ZNP + Z-Tool、则进一步评估器件行为也会有所帮助、以比较行为。

    此致、
    瑞安

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

    您好、Ryan、

    我终于成功了!

    最后、我得出了这个解决方案:

    我在 f8wConfig.cfg 中使用这些设置启动了调试:

    DRFD_RCVC_ALWAYS_ON=false
    DPOLL_RATE=1000
    DQUEUED_POLL_RATE=100
    DRESPONSE_POLL_RATE=100
    DREJOIN_POLL_RATE=440

    这将使该器件能够成功加入 Zigbee2MQTT 或接受 Zigbee2MQTT。 但在完成这些设置后、器件不会进入深度睡眠状态。 因此、我在 zcl_genericapp.c 中添加了可在成功调试后触发的计时器事件:

    case BDB_COMMISSIONING_NWK_STEERING:
      if(bdbCommissioningModeMsg->bdbCommissioningStatus == BDB_COMMISSIONING_SUCCESS)
      {
        osal_start_timerEx(zclGenericApp_TaskID, GENERICAPP_EVT_1, 5000);
      }
    

    5秒后、轮询率设置为0、器件可以进入深度睡眠模式。

    if (events & GENERICAPP_EVT_1)
    {
      NLME_SetPollRate(0);
      NLME_SetQueuedPollRate(0);
      NLME_SetResponseRate(0);
      
      return (events ^ GENERICAPP_EVT_1);
    }
    

    感谢您的帮助和非常有用的建议。 这是非常值得赞赏的。

    此致、

    弗莱明