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

[参考译文] CC2652R：数据传输后器件无法休眠

admin
Guru**** 2952510 points

Other Parts Discussed in Thread: CC2652R, SYSCONFIG, Z-STACK, CC2652RB

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

https://e2e.ti.com/support/wireless-connectivity/zigbee-thread-group/zigbee-and-thread/f/zigbee-thread-forum/1028363/cc2652r-device-does-not-sleep-after-data-transfer

器件型号：CC2652R
Thread 中讨论的其他器件： SysConfig、 Z-stack、

CCS：  版本：10.3.1.00003  

SDK： simplelink_cc13x2_26x2_sdk_5_10_00_48

硬件：CC2652R1F Launchpad

我的项目基于 zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs
任务很简单、按下按钮后、会从 multistate_input 群集发送报告、并每小时从电池组发送一次报告。

待机 μA 下的平均电流消耗为1 μ A。 对我来说没关系。

但是、我的器件会定期(按下10-30按钮后)不会进入待机模式。 功耗保持在大约3.2mA。 我需要按几次该按钮、器件才能进入待机状态。 没有依赖关系，它是偶然发生的。
如果我在5分钟内未触摸设备、则只需按一下按钮即可使设备返回待机状态。

接收器似乎保持开启状态。 此时内部直流/直流持续工作。

设置标志会阻止进入待机模式：PowerCC26XX_disallow_shutdown 和 PowerCC26XX_disallow_standby。
power_getConstraintMask()返回6。

当 μA 进入睡眠模式(消耗1 μ A)时，调用 OsalPort_pwrmgrTaskState()函数和条件 

if(pwrContraint == 1) {
  Power_releaseConstraint(PowerCC26XX_SD_DISALLOW);
  Power_releaseConstraint(PowerCC26XX_SB_DISALLOW);
  pwrContraint--;
}

如果出现问题并且消耗量变为3.2mA，则在尝试进入待机状态之前，将调用 OsalPort_pwrmgrTaskState()函数，并且只满足条件 

if(pwrContraint == 0) {
  Power_setConstraint(PowerCC26XX_SD_DISALLOW);
  Power_setConstraint(PowerCC26XX_SB_DISALLOW);
  pwrContraint++;
}

屏幕截图显示了问题的时刻。 从大约6秒开始、器件应该已经处于睡眠状态、但没有发生这种情况。

是否有解决此问题的方法？

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

    您好、Egor、

    您是否在该错误状态下调试了项目、以进一步确定它是否停留在会阻止器件进入睡眠模式的应用状态？    要在 zed_genericapp 上重现此问题、需要进行哪些更改？

    此致、
    Ryan

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

    您好、Ryan！

    我在调试时遇到了这个问题。 此时未执行任何自定义函数。 处理器仅进入 WFI。
    器件仍在执行其功能、按下按钮时会显示报告、电池状态每小时发送一次。 电池报告(计时器每小时一次)解决了问题、处理器进入待机状态。

    我能否提供一些调试信息来了解具体情况？

    我向 generic_app 添加了 OTA。
    我将尝试将我自己的函数添加到清理工程中、并监控器件的行为。 但我仍然没有看到任何可能损害 ZigBee 堆栈的违禁行为。
    我需要几天时间来完成此操作、我将提供最少的更改来重复此问题。

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

    eGor、

    感谢您的回答。  目前很难分辨 CC2652R 为何保持工作状态。  器件轮询数据的频率如何？  您是否有任何激活的应用定时器？  您是否有监听器设备和日志 来查看无线数据包？  我将等待您提供的任何进一步调试信息或代码。

    此致、
    Ryan

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

    您好、 Ryan Brown1

    一些附加数据。

    监听器日志：

    按钮按压 ID 注释
    0 1-21. 设备进入睡眠状态
    1 28 - 46 设备进入睡眠状态
    2. 153-171. 设备未进入睡眠状态
    3. 176 - 194 设备未进入睡眠状态
    4. 201 - 218 设备未进入睡眠状态
    5. 234 - 251 设备未进入睡眠状态
    6. 274 - 291 设备进入睡眠状态

    日志看起来不错、我没有看到任何问题。

    e2e.ti.com/.../ok_5F00_fail_5F00_ok_5F00_ti_5F00_forum_5F00_0.zip

    比较了具有和没有问题的存储器部分。 可以看出、大多数差异都在射频部分。
    希望这对您有所帮助。 

      address   fail     ok
0x20001b40 00000002 00000000		RF_core
0x20001b44 0000125D 00017041		RF_core
0x20001b84 000159BD 00026C95		RF_hwiCpe0Obj
0x20001d00 200050A0 00000000		RF_ratModule
0x20001d04 0002DD55 00000000		-
0x20001d08 00020001 00000000		-
0x20001d10 0005000A 00000000		-
0x20001d14 A8266F00 00000000		-
0x20001d20 200050A0 00000000		-
0x20001d24 0002C7E1 00000000		-
0x20001d28 00020101 00000100		-
0x20001d30 0006000A 00000000		-
0x20001d34 A8266F00 00000000		-
0x20001d60 00020004 00000007		RF_ratModule
0x20002030 00000006 00000000		PowerCC26X2_module
0x20002048 00000000 00000001		-
0x2000215c 00000001 00000002		-
0x2000216c 00000201 00000000		-	
0x20002180 01000301 00000301		PowerCC26X2_module
0x200021fc 00000000 00000001		ROM_stateStruct
0x20002218 00000000 00000001		ROM_stateStruct 
0x20002ce4 000100FF 00FEFEFF		lastRatChanA lastRatChanB
0x20002e14 00010030 01010030		macRadioYielded
0x200037d4 00019765 200037F8		stackTaskCallStack, zclGenericApp_Input1_OutClusterList, zclGenericApp_Input2_OutClusterList
0x200038e8 00000000 20001B20		stackTaskCallStack, zclGenericApp_Input1_OutClusterList, zclGenericApp_Input2_OutClusterList
0x20004a20 00000020 00000000		rreqCounter  	
0x20004a2c 61000000 00000000		-
0x20004a30 00000000 50004FAC		-
0x20004a34 00000000 10000080		-
0x20004a38 00000000 20002028		-
0x20004a3c 00000000 50004FAC		-
0x20004a44 00000000 100001B8		-	
0x20004a48 00000000 100001B8		-
0x20004a4c 00000000 0001701D		-
0x20004a50 00000000 0000000C		-
0x20004a54 00000000 100001B8		-
0x20004a58 00000000 00000004		-
0x20004a60 00000000 00000001		-
0x20004a68 00000000 20002028		-
0x20004a6c 00000000 0000D555		-
0x20004a70 00000000 00000240		-
0x20004a74 00000000 0000000A		-
0x20004a78 00000001 20002034		-
0x20004a80 00000000 00033F10		-
0x20004a84 00000000 10000000		-
0x20004a88 10000000 FFFFFFFF		-
0x20004a8c 0002CF1B FFFFFFFF		-
0x20004a90 100001D8 FFFFFFFF		rreqCounter       
0x20004a94 00019B65 00019B2D		ti_sysbios_knl_Task_Instance_State_0_stack__A
0x20004af8 00000001 00000000		taskTbl    conservePower	unsigned char	0 '\x00'	0x20004AF8	
0x200061d4 0400080A 04000809		RF_ratSyncCmd		CMD_SYNC_START_RAT
0x20006428 02060B06 02060006		RF_powerConstraint = 0x0B   RF_PowerConstraintCmdQ RF_PowerConstraintRatCh1 RF_PowerConstraintRatCh0
0x20006440 14000001 14000000		macSymbolTimerImpending

    在存档中、存储器转储：
    after_ok.dat -器件再次进入睡眠状态(出现问题后)
    fail_2.dat -设备未进入睡眠状态(有问题)
    before_ok.dat -设备进入睡眠状态(问题发生前)

    Zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs.map  

    e2e.ti.com/.../dump_5F00_mem_5F00_map.zip

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

    已稍微解析内存转储。 

      address   fail     ok
0x20001b40 02 		00				RF_core.status
0x20001b44 0000125D 00017041		RF_core.fxn

0x20001b84 BD 		95				RF_hwiCpe0Obj.data[8]
0x20001b85 59 		6C				RF_hwiCpe0Obj.data[9]
0x20001b86 01 		02				RF_hwiCpe0Obj.data[10]

0x20001d00 200050A0 00000000		RF_ratModule.channel[0].pClient
0x20001d04 0002DD55 00000000		RF_ratModule.channel[0].pCb
0x20001d08 01 		00				RF_ratModule.channel[0].mode
0x20001d0A 02 		00				RF_ratModule.channel[0].status
0x20001d10 0005000A 00000000		RF_ratModule.channel[0].chCmd
0x20001d14 A8266F00 00000000		-
0x20001d20 200050A0 00000000		RF_ratModule.channel[1].pClient
0x20001d24 0002C7E1 00000000		RF_ratModule.channel[1].pCb
0x20001d28 01 		00				RF_ratModule.channel[1].mode
0x20001d2A 02 		00				RF_ratModule.channel[1].status
0x20001d30 0006000A 00000000		RF_ratModule.channel[1].chCmd
0x20001d34 A8266F00 00000000		-
0x20001d60 04 		07				RF_ratModule.availableRatChannels	
0x20001d62 02 		00				RF_ratModule.numActiveChannels		

0x20002030 06 		00				PowerCC26X2_module.constraintMask
0x20002048 00 		01				PowerCC26X2_module.clockObj.data[20]
0x2000215c 01 		02				PowerCC26X2_module.state
0x2000216c 0201     0000			PowerCC26X2_module.constraintCounts[2]  PowerCC26X2_module.constraintCounts[1] 
0x20002183 01 		00				PowerCC26X2_module.resourceCounts[17]

0x200021fc 00000000 00000001		ROM_stateStruct->ti_sysbios_knl_Swi_Module__state__V.locked
0x20002218 00000000 00000001		ROM_stateStruct->ti_sysbios_knl_Task_Module__state__V.locked	

0x20002ce5 0100 	FEFE			lastRatChanB lastRatChanA
0x20002e17 00		01				macRadioYielded

0x200037d4 00019765 200037F8		stackTaskCallStack, zclGenericApp_Input1_OutClusterList, zclGenericApp_Input2_OutClusterList
0x200038e8 00000000 20001B20		stackTaskCallStack, zclGenericApp_Input1_OutClusterList, zclGenericApp_Input2_OutClusterList

0x20004a20 00000020 00000000		ti_sysbios_knl_Task_Instance_State_0_stack__A  	
0x20004a2c 61000000 00000000		-
0x20004a30 00000000 50004FAC		-
0x20004a34 00000000 10000080		-
0x20004a38 00000000 20002028		-
0x20004a3c 00000000 50004FAC		-
0x20004a44 00000000 100001B8		-	
0x20004a48 00000000 100001B8		-
0x20004a4c 00000000 0001701D		-
0x20004a50 00000000 0000000C		-
0x20004a54 00000000 100001B8		-
0x20004a58 00000000 00000004		-
0x20004a60 00000000 00000001		-
0x20004a68 00000000 20002028		-
0x20004a6c 00000000 0000D555		-
0x20004a70 00000000 00000240		-
0x20004a74 00000000 0000000A		-
0x20004a78 00000001 20002034		-
0x20004a80 00000000 00033F10		-
0x20004a84 00000000 10000000		-
0x20004a88 10000000 FFFFFFFF		-
0x20004a8c 0002CF1B FFFFFFFF		-
0x20004a90 100001D8 FFFFFFFF		-       
0x20004a94 65 		2D				ti_sysbios_knl_Task_Instance_State_0_stack__A

0x20004af8 01 		00				taskTbl[0].conservePower = 1 (OsalPort_PWR_HOLD)
0x200061d4 080A 	0809			RF_ratSyncCmd = CMD_SYNC_START_RAT
0x20006429 0B 		00				RF_powerConstraint (RF_PowerConstraintCmdQ | RF_PowerConstraintRatCh2 | RF_PowerConstraintRatCh0)
0x20006440 01 		00				macSymbolTimerImpending

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

    您好！

    这些更改足以产生错误。

    我在连接外部而不是3V3跳线的情况下测量电流

    闪存 MCU
    2.连接到 ZigBee 网络
    3.设备正在休眠。 电流~ 20uA
    4.等待15分钟
    5.按 BTN-1。 将发送1个数据请求。 消耗电流3.4mA。 设备无法休眠。
    6.等待3分钟。 按 BTN-1。 设备进入睡眠状态。

    第4点很重要。 您需要等待10-15分钟。 如果您按较早的键，则不会出现问题。

    e2e.ti.com/.../gen_5F00_changes_5F00_bug.zip

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

    由于对 NwkPollReq (0)函数的调用、它看起来像是一个问题；
    我可以通过我的代码使用此函数吗？

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

    感谢您提供所有这些附加信息。  我 注意到您也使用了 NwkPollReq 、我不建议使用它、因为它可能会干扰轮询控制模块。  是否可以尝试调用  OsalPort_setEvent (NWK_TaskID、NWK_AUTO_POLL_EVT)？  OTA_CLIENT.c 中还有一些实例、其中 RxOnIdle 设置为 true 以加快轮询、您将需要进一步监视此应用实例、因为它肯定会影响您的电流消耗。

    此致、
    Ryan

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

    谢谢你

    问题不是 NwkPollReq。
    我将 NwkPollReq (0)替换为 OsalPort_setEvent (Nwk_TaskID、Nwk_AUTO_POLL_EVT)、但器件仍无法进入睡眠状态。

    我在干什么：
    安装了 CCS 的最新版本(版本：10.4.0.00006)
    2.安装了最新的 SDK 版本(simplelink_cc13x2_26x2_sdk_5_20_00_52)
    导入了项目 zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs
    在项目中、只更改了轮询周期(ms)= 3600000 (1小时)
    以及按下 BTN-1按钮的操作 

    static void zclGenericApp_processKey(Button_Handle _btn)
{

.......

        else if (ZG_BUILD_JOINING_TYPE && ZG_DEVICE_JOINING_TYPE)
        {
            if ( !bdbAttributes.bdbNodeIsOnANetwork) { //BDB_DEFAULT_NODE_IS_ON_A_NETWORK
                zstack_bdbStartCommissioningReq.commissioning_mode = BDB_COMMISSIONING_MODE_NWK_STEERING | BDB_COMMISSIONING_MODE_FINDING_BINDING;
                Zstackapi_bdbStartCommissioningReq(appServiceTaskId,&zstack_bdbStartCommissioningReq);

             } else {

                 //NwkPollReq(0);
                 OsalPort_setEvent(NWK_TaskID, NWK_AUTO_POLL_EVT);
             }
        }

.......

}

    每次都出现问题。
    您需要将器件连接到 ZigBee 网络、等待10-15分钟、按 BTN-1按钮(我看到监听器正在发送数据请求)、器件不会进入待机状态。 几分钟后、我再次按下按钮、器件进入待机状态。

    您可以自己检查一下吗？

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

    嗨、Egor、

    感谢您的直接说明、我已经能够像您所描述的那样直接重现此问题。  我正在与软件开发团队沟通、以进一步确定对此行为可能负责的方面。  同时、您是否考虑暂时更改默认轮询率或使用应用程序内的轮询控制群集来确保通过无线方式发送数据请求？  供参考 的 SimpleLink Academy 实验。  您还可以尝试发送启用 默认响应的 ZCL 消息、以便在父 MAC ACK 期间拾取其他帧暂挂位。

    此致、
    Ryan

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

    我将尝试更改轮询时间以解决该问题。
    感谢您关注我的问题。 我希望有一个解决方案。

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

    到目前为止、我已经确认 这也适用于超过某个值的默认轮询周期、而不仅仅是手动轮询。  因此，我将收集更多数据，并将尽快提供更多信息。

    此致、
    Ryan

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

    感谢您的耐心等待。  我只能通过将 SysConfig 中的轮询周期值增加到等于或大于540000 ms (9分钟)的数字来在 SDK 5.20上复制此问题。  我已经尝试调试了该问题，但发现在正常和故障运行期间，调用堆栈和任务/信标状态完全相同。  我发现 v5.10和 v4.40 Z-Stack 示例也存在此问题、但无法使用15.4-Stack 2.4GHz 传感器和收集器示例进行复制。  我已经向 Z-Stack 软件研发团队提交了一个 TT 来解决该问题。

    此致、
    Ryan

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

    我在 CC2652RB SDK 5.20上遇到相同的 Z-Stack 问题。 减少轮询周期很有用、但有一个警告：当器件失去网络(状态为 NWK_ALOADD)时、它不 会轮询父级、问题再次发生。   如果对讲机 关闭超过9分钟、 则设备在  下次使用对讲机时无法正确进入深度睡眠模式。

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

    感谢 Alexander 提供的更多信息。  请注意、在 NWK_ALLOAD_ALOADED 状态下、ZED 应用程序将从  zcl_[application].c 中执行 zcl[application]_ProcessCommissioningStatus 中的 BDB_commoning_lost case、默认情况下将启动 EndDeviceRejoin 计时器(SampleApp_end_device_rejoin_delay 默认值为1秒)、以设置 SampleApp_end_evt_device 超时后的 End_evt。  这反过来将尝试网络恢复、包括通道上的信标请求、即 IEEE MAC 级无线电活动。

    此致、
    Ryan