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.

LP-CC2652RB: Shutting down the board and waking it again periodically, programmatically

Part Number: LP-CC2652RB
Other Parts Discussed in Thread: CC2652RB, , SIMPLELINK-CC13XX-CC26XX-SDK, SYSCONFIG

Hello There,

We try to save power and shutdown/wake-up a CC2652RB (developing with launchpad and custom board, too), final product should be CC2652RB based running on a battery.  The current implementation discharges one battery per day so it is not feasible to use meaning power consumption must be drastically reduced.

The idea was shutting down the processor using Power_shutdown(PowerCC26XX_ENTERING_SHUTDOWN, 10000); so that the processor goes down for about 10s, then it wakes up, does its job and then gets shut down again .The final application would not reboot like every 10s, rather like every 5 minutes or so.

I looked into the document titled as SimpleLink SDK Power Management and read that CC26XX has three sleep states: WFI, IDLE and STANDBY.  So, by calling the actual Power_shutdown I was hoping to get into STANDBY state and then get rebooted after a given time from the second function parameter.  The standby state is initiated properly but the LP-CC2652RB LaunchPad never wakes up to restart/reboot the application.

The documentation of Power.h mentions that some device families support the second parameter: shutdownTime while others do not. Does actually CC2652RB support it and should it wake up after the time is expired? 

If yes, is there a common issue what it can cause the processor not to wake up?  If CC2652RB would not support that feature then probably the Sensor Controller could: Is the Sensor Controller able to trigger a complete reboot based on a timer or is it only able to wake it up from Task_sleep?

So, the ideal solution for us would be stopping the cortex core completely and restart only on a timer after which it stops itself and awaken by a timer again.

What do you think, what is the best approach to get this behavior working - and is Power_shutdown supposed to use the reboot timer for CC26XX?

Thank you,\

Sandor

  • Hello Sandor,

    Are you using a TI RF Stack, which version of SIMPLELINK-CC13XX-CC26XX-SDK are you evaluating, and what code example did you start from?  Can you please review these E2E threads and let me know whether they answer your questions?

    https://e2e.ti.com/f/1/t/1094315 
    https://e2e.ti.com/f/1/t/1095906 
    https://e2e.ti.com/f/1/t/1064828 

    Regards,
    Ryan

  • The code was started from the zed-sw example code.  The first suggestion has a button involved in the procedure.  I would like to see an automatic reboot after some time spent, no user interaction.  The second forum entry just tries to use a 0 timer and is hooked back into the first one, so no for that one, too.  The third thread is also about a button, so the answer is no.

    I keep CCS updated to the last version, so the current and most recent version is used: 11.2.0 and the SimpleLink version looks to be 6.10.

    Just to summarize what I look for: restart a CC26XX unit from standby power mode without user interaction, on a timer as documented in power.h.  What I look at:

    unsigned int  Power_shutdown (unsigned int shutdownState, uint32_t shutdownTime)

    but the LP-CC2652RB does not restart after shutdownTime is expired.  Only creating a new debugging session or power off-on restarts the code execution.  I have the feeling that shutdownState should be something like standby and using PowerCC26XX_ENTERING_SHUTDOWN might be not the right one - so the functionality might work just it should be properly parametrized - not sure what needs to be used or where power support is documented in that detail for CC13XX/CC26XX.

  • Zigbee End Devices are already optimized for low power consumption using standby mode and have been estimated to operate several years on a single coin cell battery design.

    https://www.ti.com/lit/swra625 
    https://www.ti.com/lit/swra478 
    https://www.ti.com/lit/swra636 
    https://dev.ti.com/tirex/content/simplelink_cc13xx_cc26xx_sdk_6_10_00_29/docs/zigbee/html/zigbee/power_configuration.html 
    https://dev.ti.com/tirex/explore/node?node=AIVXLmiDi3itQCPgZ1incA__BSEc4rl__LATEST 

    Thus if your current implementation discharges one battery per day then there is a significant flaw in the hardware setup or the ZED is being prevented from entering standby mode as intended.  Make sure to disconnect the XDS110 debugger when evaluating power on the LP-CC2652RB and ensure that SysConfig Zigbee/Power modules retain Standby Mode settings.

    Regards,
    Ryan

  • Thank you for the answer Ryan.

    Basically the main loop is a for(;;) just like in the example code what locks on a Semaphore and activated only when the user pushes a button or when a zigbee communication event happens, pretty much like the UI example, using a queue to be processed. This is exactly same as the zed_sw example: Semaphore_pend(appSemHandle, BIOS_WAIT_FOREVER ). Based on that, zed_sw and this custom code should have about the very same power consumption.  I was thinking that maybe some zigbee keep-alive or something similar is going on.  There is only one extra in the code what may change power consumption, a new timer what runs a battery check every 30 seconds by calling AONBatMonNewBatteryMeasureReady().  Can this make a significant difference?

    There are other interesting parts of your answer, namely that the custom board might be the reason for high power usage.  Are you aware of typical design flaws that can cause this issue?  Does it make any sense trying to externally power the LP-CC2652RB and measure its consumption and compare?  And one last - as I mostly do software and the other person who does hardware complained to me and told that ZC drained the battery flat in one night and not very sure if he tried with ZED too - I will ask him now.  Is it normal that ZC (and routers) use much more power than actually ZED so should we expect to see a significantly lower power consumption of ZED setups?  In my understanding: yes, it would be great to have that confirmed if you are aware of that.

    Kind Regards,

    Sandor

  • You can increase the zed_sw SysConfig -> Zigbee -> Power Management -> Poll Period to keep the device asleep for longer and thus improve the power consumption.  The timer interval for AONBatMonNewBatteryMeasureReady will also have an effect, and should be quickly serviced as infrequently as possible for your application.

    Poor pin wiring and additional external components contribute to additional power.  It is optimal to measure the CC2652RB current without being connected to the LaunchPad's on-board XDS110 debugger.  ZC and ZR nodes consume much more current since they are routing devices which must stay active to receive/transport packets at any time and thus are not allowed to enter low-power states.  Conversely, ZEDs are configured to be sleepy devices and are the only viable option for battery-powered operation.

    Regards,
    Ryan