Jump to content
Forum sending old emails Read more... ×
Sign in to follow this  
tripwire

CC2650 SensorTag: Low power checklist

Recommended Posts

Here's a list of things to check for if you're getting excessive power consumption on the CC2650 SensorTag - particularly when using TI-RTOS:

  • [3.0mA constant] If you're not using the MPU, has it been powered off? By default the Board_MPU_POWER pin is set to output high during startup (TI-RTOS 2.1).
  • [2.9mA when idle] Do you have a power policy set up in the TI-RTOS .cfg file, and is it correctly configured to run when tasks are idle?
  • [0.5mA when SPI inactive] Are the SPI bus pins set to pulldown when the SPI driver is inactive? If they're left floating the serial flash inputs can draw excessive current.
  • [0.27mA constant (?)] Has the TMP007 been placed in shutdown? By default it powers up in 4x oversampling mode with a typical current of 270uA.
  • [0.20mA when alert active (?)] If you're using the TMP007 alert pin function, have you disabled pullup on Board_TMP_RDY? There's an external pullup on the board already...
  • [0.01mA constant] Has the external serial flash been powered down? It takes a typical current of 10uA in standby, which drops to 1uA in power-down.

The ones marked (?) are unconfirmed, and are just based on specifications/schematics.
 
Further to the two TMP007 items on the list: is your TMP007 working at all? If you can't get it to respond to I2C traffic it's possible that it has been damaged. Mine was, and it resulted in additional wasted current of 4mA until I removed the chip. Being a bare die makes it quite vulnerable to damage.
 
If you're not using SPI then the following code fragment will resolve points 1 and 3:

    static const PIN_Config unusedPinTable[] =
    {
        Board_MPU_POWER | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, // MPU power off

        Board_SPI0_MOSI | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus
        Board_SPI0_CLK  | PIN_INPUT_DIS | PIN_PULLDOWN, // disable input, enable pulldown to give a defined level on the bus

        PIN_TERMINATE
    };

    // Open unused pins to set correct default state
    // Define unusedPinHandle and unusedPinState somewhere, either static or global
    unusedPinHandle = PIN_open(&unusedPinState, unusedPinTable);

If you are using SPI you'll need to set up a pin table/handle/state for just the SPI pins, then use PIN_open after SPI_close and PIN_close before the next SPI_open. Alternatively you can just keep the SPI open... but that seems to take an extra ~100uA. I think that's because the uDMA forced to stay powered up.
 
For point 2, the easiest way to be certain that the power policy is correctly set up is by calling it from a user-defined idle function. That way you can breakpoint the function and be sure that it is called when all tasks are idle.
 
First you'll need to turn off the option that automatically runs the power policy when tasks are idle:
 
post-30355-0-62304700-1441060423_thumb.png
 
Now add the following code to your project:

#include <ti/sysbios/family/arm/cc26xx/Power.h>

void idleFxn()
{
    Power_standbyPolicy(); // Breakpoint this line to check that the policy is getting called on idle
}

Finally set up the idle function:
 
post-30355-0-46714400-1441062759_thumb.png
 
Now run the program in the debugger and check that a breakpoint placed in idleFxn is hit during runtime. You can also step in to the Power_standbyPolicy code and see which low power mode it is able to use; sometimes it's prevented from going into full standby due to constraints set by active peripheral drivers.
 
Removing the user-defined idle function and rechecking the "Invoke power policy when all threads are blocked" should give the same result, but it's harder to confirm that it's working correctly.
 
The tiny saving from putting the flash into power-down for step 5 is barely worth the effort. You need code to initialise the SPI driver, get the flash into a known state from a potentially unknown one and then put it to sleep. The MCU can be reset without the external flash being power cycled, and JTAG blocks SPI traffic making the code untestable in the debugger. I only did this because I'm using the flash in my project already.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×