RTOS/CC2640R2F: PowerCC26XX_standbyPolicy() Sleep Functions

Hi Akash,

There is a significant difference between the first bullet and the other two. Starting with the PRCM calls, these will simply put the CPU into sleep (or deep-sleep) mode where it will be waiting for a wake up interrupt.

The Power_sleep() function is a high level API from the Power driver. This function will transition the whole device into standby if possible, shutting down power domains and disabling peripherals when possible among all the things.

Simply put, Power_sleep() will try to put the DEVICE into sleep, while the other two will put the CPU into sleep.

Hi Akash,

This is not exactly correct, while your understanding of the PRCM functions are correct, Power_sleep(PowerCC26XX_STANDBY) is more complicated. It will try to put the whole device into standby by shutting down as much as possible (CPU, Peripherals, Radio, etc.).
As there can be dependencies or constraints set in the system (typically done by drivers but sometimes also by user applications and stacks), it might not be possible to put the device into absolute standby (< 1uA current), instead the current will depend on what subsystems are left on.

As you are using TI-RTOS, going into sleep/standby is nothing you would have to actively control as this is handled by the Power policy and the system Idle task. As you observe that "Standby disallow" constraints are set on the system, the Power driver would not be able to transition into standby/sleep as the application explicitly asked it not to.

The fact that constraints are equal to "4" in your case means that the application in four different locations have set the constraint to keep the driver out of shutdown. For example, you might be using 4 different drivers that all request the device to be keep out of standby. This could be for example active serial communication, radio, ADC, Timers etc.

You could add "PowerCC26XX_module" to your expressions in CCS and observe what resources are active. resourceCounts reflect what peripherals and power domains are turned on by the Power driver, the index of the array can be mapped to a specific part by looking inside PowerCC26XX.h. This can give you a hint on what might be setting the constraints.

As I explain above, the current drawn (using any of these) depends on what else is active. As PRCM only related to the CPU part, the current consumption then depends on the rest of the system. When using the Power driver, again, the power consumption depends on what is active in the whole system or not.

In the datasheet you can see different values for standby and idle with an explanation on what parts that is active. Below you have a list of current consumption for individual peripherals. The actual current would be Icore + Iperh.
The definition for standby can be found in the technical reference manual.

Hi Akash,

There is no good way to say that "This is what causes it" but you can use the resourceCounts to track the cause of your problem.

For example, you can see that the RF_CORE, SERIAL and PERIPHERAL domain is all active (the later have 3 dependencies which means at least 3 drivers require this domain to be active). You also see that the UART0, TRNG, GPIO, CRYTPO, and XOSC_HF is turned on.

I would suspect either the RF or UART part of the code keeping you out of standby. Have you made sure there is no active UART_write/read calls (callback mode included) and that the Radio is not left active?