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: Device does not sleep after data transfer

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

CCS:  Version: 10.3.1.00003 

SDK: simplelink_cc13x2_26x2_sdk_5_10_00_48

HW: CC2652R1F launchpad

My project is based on zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs
The task is simple, when the button is pressed, a report is sent from the multistate_input cluster and a report is sent from the battery cluster once an hour.

Average current consumption in standby mode is 1 μA. That's fine for me.

But, periodically (after 10-30 button presses), my device does not go into standby mode. Consumption remains at about 3.2 mA. I need to press the button several times for the device to go into standby. There is no dependence, it happens by chance.
If I do not touch the device for 5 minutes, then one press of the button is enough for the device to go back to standby.

The receiver appears to remain on. Internal DC/DC at this time works constantly.

The set flags prevent entering standby: PowerCC26XX_DISALLOW_SHUTDOWN and PowerCC26XX_DISALLOW_STANDBY.
Power_getConstraintMask() returns 6.

When entering sleep mode correctly (with 1 μA consumption), the OsalPort_pwrmgrTaskState() function is called and the condition

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

if a problem occurs and the consumption becomes 3.2 mA, then before trying to go to standby, the OsalPort_pwrmgrTaskState() function is called and only the condition is met

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

The screenshot shows the moment of the problem. From about 6 seconds the device should have been asleep, but this did not happen.

Is there a solution to this problem?

  • Hello Egor,

    Have you debugged your project during this error state to further determine whether it is stuck in an application state which would prevent the device from entering a sleep mode?  What changes are necessary to replicate this issue on zed_genericapp?

    Regards,
    Ryan

  • Hi, Ryan!

    I got this problem while debugging. No custom functions were executed at this time. The processor just goes to WFI.
    The device still performs its functions, there is a report at the press of a button, the battery status is sent once an hour. It happens that the battery report (on a timer once an hour) solves the problem and the processor goes into standby.

    Can I provide some debugging information to understand what's the matter?

    I added OTA to generic_app.
    I will try to add my own functions to a clean project and monitor the behavior of the device. But I still don't see any prohibited actions that could harm the zigbee stack.
    I need a few days to do this and I will provide minimal changes to repeat the problem.

  • Egor,

    Thanks for the response.  It's difficult to tell at the moment why the CC2652R is staying in an active state.  How often does the device poll for data?  Do you have any application timers active?  Do you have a sniffer device and log to review over-the-air data packets?  I will wait for any further debug information or code you can provide.

    Regards,
    Ryan

  • Hi, Ryan Brown1

    Some additional data.

    Sniffer log:

    Button presses ID Comment
    0 1 - 21 device went to sleep
    1 28 - 46 device went to sleep
    2 153 - 171 device did NOT go to sleep
    3 176 - 194 device did NOT go to sleep
    4 201 - 218 device did NOT go to sleep
    5 234 - 251 device did NOT go to sleep
    6 274 - 291 device went to sleep

    The log looks fine, I didn't see any problems.

    ok_fail_ok_ti_forum_0.zip

    Compared part of the memory with and without problems. It can be seen that most of the differences are in the RF part.
    Hope this helps.

      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
    

    In the archive, memory dumps:
    after_ok.dat - device went to sleep again (after the problem)
    fail_2.dat - device did NOT go to sleep (with a problem)
    before_ok.dat - device went to sleep(before the problem)

    zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs.map 

    dump_mem_map.zip

  • Parsed the memory dump a little.

      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

  • Hello!

    These changes are enough for an error.

    I measure the current with an external connected instead of the 3V3 jumper

    1. Flash MCU
    2. Connect to the zigbee network
    3. The device is sleeping. Current ~ 20uA
    4. Wait 15 minutes
    5. Press BTN-1. 1 data request will be sent. Consumption current 3.4 mA. The device does not sleep.
    6. Wait 3 minutes. Press BTN-1. The device falls asleep.

    Point 4 is important. You need to wait 10-15 minutes. If you press earlier, then the problem does not happen.

    gen_changes_bug.zip

  • It looks like a problem because of the call to the NwkPollReq(0) function;
    Can I use this function from my code?

  • Thank you for providing all of this additional information.  I noticed your usage of NwkPollReq as well, I would not recommend it as it could interfere with the poll control module.  Could you please try calling OsalPort_setEvent( NWK_TaskID, NWK_AUTO_POLL_EVT) instead?  There are also instances in ota_client.c where RxOnIdle is set to TRUE for faster polling, you will want to further monitor this application instance as it will definitely affect your current consumption.

    Regards,
    Ryan

  • Thank you

    The problem isn't NwkPollReq.
    I replaced NwkPollReq(0) with OsalPort_setEvent(NWK_TaskID, NWK_AUTO_POLL_EVT), but the device still does not go to sleep.

    What am I doing:
    1. Installed the latest version of CCS (Version: 10.4.0.00006)
    2. Installed the latest SDK version (simplelink_cc13x2_26x2_sdk_5_20_00_52)
    3. Imported the project zed_genericapp_CC26X2R1_LAUNCHXL_tirtos_ccs
    4. In the project, changed ONLY Poll Period (ms) = 3600000 (1 hour)
    and handling of pressing the BTN-1 button

    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);
                 }
            }
    
    .......
    
    }

    the problem appears every time.
    You need to connect the device to the zigbee network, wait 10-15 minutes, press the BTN-1 button (I see with a sniffer that a data request is being sent) and the device does not go into standby. After a couple of minutes, I press the button again and the device goes into standby.

    Could you check it yourself?

  • Hey Egor,

    Thank you for the straightforward instructions, I've been able to directly replicate the issue as you've described it.  I'm communicating with the Software Development Team to further determine what could possibly be responsible for this behavior.  In the meantime, have you considered temporarily changing the default poll rate or using the poll control cluster inside your application to ensure that a data request is sent over-the-air?  SimpleLink Academy Lab for reference.  You could also try sending a ZCL message with default response enabled to pick up additional Frame Pending bits during the parent MAC ACKs.

    Regards,
    Ryan

  • I will try to change the polling time to work around the problem.
    Thank you for your attention to my problem. I hope there is a solution.

  • So far I've confirmed that this also applies to default poll periods which exceed a certain value, not just manual polling efforts.  Thus I am collecting more data and will provide more information as soon as possible.

    Regards,
    Ryan

  • Thank you for your patience.  I’ve been able to replicate this issue on SDK 5.20 solely by increasing the Poll Period value in SysConfig to a number equal or greater than 540000 ms (9 minutes).  I’ve tried to debug the issue but have found that the call stack and task/semaphore states are the exact same during both good and faulty operation.  I found that this issue exists on the v5.10 and v4.40 Z-Stack examples as well, but could not replicate with the 15.4-Stack 2.4 GHz sensor & collector examples.  I have filed a ticket with the Z-Stack Software R&D Team to address the issue.

    Regards,
    Ryan

  • I have the same issue with Z-Stack on CC2652RB, SDK 5.20. Reducing Poll Period helps, but there is one caveat: when device loses network (state NWK_ORPHAN), it does not poll the parent and issue happens again. It seems like if radio is off for more than 9min then device does not go to deep sleep properly the next time radio is used.

  • Thanks for the additional information Alexander.  Please note that in the NWK_ORPHAN state, the ZED application will execute the BDB_COMMISSIONING_PARENT_LOST case in zcl[application]_ProcessCommissioningStatus from zcl_[application].c which by default will start the EndDeviceRejoin timer (SAMPLEAPP_END_DEVICE_REJOIN_DELAY default is one second) to set the SAMPLEAPP_END_DEVICE_REJOIN_EVT after timeout.  This in turn will attempt network recover, including a Beacon Request on the channel which is IEEE MAC-level radio activity.

    Regards,
    Ryan