RTOS/CC1350STK: CC1310 Cannot get to Low Power Mode

spanky

Part Number: CC1350STK
Other Parts Discussed in Thread: CC1350, , CC1310, UNIFLASH, OPT3001

Tool/software: TI-RTOS

I'm working with a custom board that is loosely based on the sensortag with a number of sensors removed and the MPU9250 moved to pins that are accessible via the sensorcontroller. The MPU power is driven by a GPIO line like in the sensortag. I never managed to get the sensortag into truly low power mode, so this is a continuation of that struggle.

My application has 2 main tasks, one to handle radio stuff and the other to trigger the sensorcontroller and wakeup the radio task. Its pretty straightforward and simple. Both tasks are blocked by Event_pend() for about 60 seconds, followed by a few seconds of sensorcontroller and a single transmit.

When the tasks are both blocked on Event_pend() for ~60s, I assume the device should enter low power mode, but it is drawing ~10mA. Is Event_pend() the same as sleep and semaphore pend, from a power perspective?

The screwy thing is when I'm reading the sensor controller, the power draw drops to ~3mA. When I'm not doing anything, the power draw is high, when I'm actually doing something the power drops?

My sensor controller code uses the same eventloop to wakeup and notify the main task once a second. I am using a mooshmeter for power tracing, so I might be missing some high frequency power spikes. I also realize I need to disconnect the debugger.

I've also tried just executing the sensorcontroller code in SCS, and the power draw is similar. High power when the sensorcontoller is not running, low power (or inline with my expectations, given the MPU power draw) when the sensor controller is executing.

I'm clearing the MPU power pin in the SCS termination code.

I'm using easylink, and from what I've read, the radio should enter low power mode when inactive (correct?)

I don't have an external flash, but CC1350_LAUNCHXL_shutDownExtFlash() is called. I should also say, I'm basing the code off the rfWsnNodeExtFlashOadClient example.

Power_init() is also called. PowerCC26XX_config is defined in CC1350_LAUNCHXL.c, but I cant see where it is actually used. Could that be the issue?

Any thoughts or hints would be appreciated.

over 7 years ago

0 Siri over 7 years ago

TI__Guru* 86731 points

When you are running custom code on custom HW it is almost impossible to give you any general advice as to where the problem is.
I supported you on the following case a while back, when you were working with our HW and SW:

e2e.ti.com/.../659420

Are you saying that even if you used the same SW as I did on the same HW, you were not able to get the correct current consumption?

Unfortunately I do not know what the problem could be but I would strongly advice to do your development in "smaller" steps so you do not end up in the situation you are in now when we have no idea if the problems are HW or SW related:

1) start with one of TIs simplest examples for our CC1350STK, an example that we know will take the chip into standby, and make sure that you are able to receive the correct current consumption at this stage. At this point you know that the HW is OK, SW is OK and that your measuring setup is OK

2) port the simple example to your custom HW by changing board files etc. and verify that you are still measuring the correct current. At this stage you will be able to confirm that your HW is OK.

3) when you know that your HW is OK and that your measuring setup is OK, you can proceed with your code development. If you at this stage you are not able to get into standby, we know that the problem is SW related.

I am sorry that I could not be of any more help at this point.

BR

Siri

0 spanky over 7 years ago in reply to Siri

Expert 2710 points

Hi Siri,

Thanks for your help on the other topic. Unfortunately I dropped the ball getting the sensortag into low power mode and focused more on the custom hardware (hoping that would eliminate some of the vagaries in the sensortag design). That thread would probably be an ideal place to continue this discussion, but I guess I waited too long and now its locked. For the sake of simplicity in this thread, lets work from the stock sensortag1350 and continue the other issue.

I took the pinStandby_CC1350STK_tirtos_ccs example from 2.20.00.38, loaded it onto the sensortag1350, and hooked up my power monitor with the debugger physically detached. The current draw is all over the place from about 12mA to 15mA depending on if the LED is on or not (this example toggles the LED and sleeps for 5 seconds, so that period is recognizable). The current draw is slightly erratic, which indicates, as in the previous thread, that the example is (despite its name) never entering low power mode. I suspect this power draw is from the sensors (which are not addressed in the example), but I was unsuccessful in my previous attempts to shut them all down.

>>start with one of TIs simplest examples for our CC1350STK, an example that we know will take the chip into standby

Can you please clarify which example this is, because it is definitely not the one that has standby in the name.

Incidentally, when I take the same example pinStandby_CC1310_LAUNCHXL_tirtos_ccs for my custom board, the power cycles are much more consistent, although never below about 5mA. The only reason I point that out is because I'm almost positive the many sensors on the sensortag are preventing the standby. I was previously unsuccessful in modifying the pinStandby_CC1350STK example. My custom board eliminated the majority of the sensors and I am pretty sure I am disabling the remaining sensors... but still cant get below a few milliamps.

0 spanky over 7 years ago in reply to spanky

Expert 2710 points

I found the ULP Advisor in the project properties. When I compile with #1 checked, it says

(ULP 1.1) Detected no uses of low power mode state changing instructions null: (ULP 1.1) Detected no uses of low power mode state changing instructions

Can you explain what this means? It sounds like it might be limited to the 430?

0 Siri over 7 years ago in reply to spanky

TI__Guru* 86731 points

I took the pinStandby example for the CC1350STK from simplelink_cc13x0_sdk_2_20_00_38. I noticed that the complete mw folder with all the sensor code has been removed from this SDK (I have files a Jira ticket for that) so I took these files from the previous SDK. I have attached all files for you.

I included all the sensor files into the pinStandby example, and added code to turn off the sensor.

My code is below:

/*
 *  ======== pinStandby.c ========
 */
#include <unistd.h>

/* Driver Header files */
#include <ti/drivers/PIN.h>
#include <ti/drivers/pin/PINCC26XX.h>

/* Example/Board Header files */
#include "Board.h"

#include "SensorBmp280.h"
#include "SensorTmp007.h"
#include "SensorUtil.h"
#include "SensorI2C.h"
#include "sensorHdc1000.h"
#include "SensorMpu9250.h"
#include "SensorOpt3001.h"

/* Led pin table */
PIN_Config LedPinTable[] =
{
    Board_PIN_LED0    | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
    Board_PIN_LED1    | PIN_GPIO_OUTPUT_EN | PIN_GPIO_LOW | PIN_PUSHPULL | PIN_DRVSTR_MAX, /* LED initially off */
    PIN_TERMINATE                                                                          /* Terminate list */
};

/*
 *  ======== mainThread ========
 */
void *mainThread(void *arg0)
{
    PIN_State   pinState;
    PIN_Handle  hPin;
    uint32_t    currentOutputVal;
    uint32_t    standbyDuration = 5;

    /* Allocate LED pins */
    hPin = PIN_open(&pinState, LedPinTable);

    if (SensorI2C_open())
    {
        /* Put unused external sensors and flash into Sleep */
        SensorBmp280_init(); // Pressure Sensor
        SensorBmp280_enable(false);
        SensorTmp007_init(); // Infrared Thermopile Sensor
        SensorTmp007_enable(false);
        SensorHdc1000_init(); // Humidity
        SensorMpu9250_init(); // Gyroscope and accelerometer
        SensorMpu9250_enable(false);
        SensorMpu9250_powerOff();
        SensorOpt3001_init();
        SensorOpt3001_enable(false);
    }

    /*
     * Repeatedly sleeps for a duration, to allow repeated entry/exit
     * from standby. The LED states are toggled on each iteration
     */
    while(1) {
        /* Sleep, to let the power policy transition the device to standby */
        sleep(standbyDuration);

        /* Read current output value for all pins */
        currentOutputVal =  PIN_getPortOutputValue(hPin);

        /* Toggle the LEDs, configuring all LEDs at once */
        PIN_setPortOutputValue(hPin, ~currentOutputVal);
    }
}

sensors.zip

I measured then a standby current consumption of 3.6 uA (in the period where the LED is off:

Not sure you are able to get below this on this HW. This is not because the chip itself is not in standby (it is, you can tell by the recharge pulses), but because of the HW.

Siri

0 spanky over 7 years ago in reply to Siri

Expert 2710 points

Apologies for the delay. I finally got around to testing this again.

With the sensortag, and the above code modifications to pinStandby, I get a low current draw of 9mA. Substantially higher than your 3.6uA.

I don't have a scope, but have used both an analog ampmeter, and a mooshimeter that can graph some low frequency samples. This is unattached from the debugger, run from a stable voltage source. I dont fully understand the charging pulses, but I don't think those would cause such a high reading on either of my meters.

0 Siri over 7 years ago in reply to spanky

TI__Guru* 86731 points

If you , with the exact same code, get a power consumption of 9 mA while I am measuring 3.6 uA you either have hardware that is not working as it is supposed to, or problems with your measurement setup. Not an HW expert, so I cannot answer if you will be able to measure these low currents with the instruments you are using.

When I am doing my measurements, I use an Agilent N6705B DC Power Analyzer.
I connect the SensorTag to the SmartRF06EB board via the 10-pin ARM Cortex Debug Connector, and then I power the SmartRF06 board from the power analyzer.

the standby current I am measuring is also measuring the recharge pulses. You can find more info about the recharge pulses here:

e2e.ti.com/.../496700

What you can do is to send info on your exact measurement setup and also details on the meters you are using and how they are connected, and maybe I can get some of our HW experts to take a look at it.

You can also make some test code and set the radio in continuous RX and/or TX and see if you are able to measure data sheet numbers then, or if you still are measuring a 9 mA offset from what you should expect.

0 Tom Allen over 7 years ago in reply to Siri

Prodigy 120 points

Hi Guys,

I am working on a similar problem and had started a thread when this one was highlighted as a solution.

Siri,
I took your code and flashed it to a sensor tag and I get 86uA in standby mode with the led off. I am using a power supply of 3.1V connected to the battery tabs on the board with an ammeter in series. The sensor tag is running standalone with no debugger connected. I have tried it on 2 sensortags and get the same result. I am also powering the microphone and the flash via the CC1350STK_shutDownExtFlash() function.

0 spanky over 7 years ago in reply to Tom Allen

Expert 2710 points

My power setup is basically the same as Tom's. Power leads hooked to the "POS & NEG" slots on the sensortag, amp meter in series. The debugger is physically disconnected.

It appears the CC1350STK_shutDownExtFlash() is called as part of the init process (via CC1350STK_initGeneral() and then Board_initHook()). I stepped through the sensor init blocks and they seem to all be executed.

I wondered if there might be another program somewhere, so I erased the entire flash via uniflash. Still same results.

If Tom can get into the uA range, and Siri can get down to 3.6uA, I would think I have a bad board.... but when I try my custom board (based of the sensortag, just with a bunch of sensors removed), I am still running in the milliamp range. I suppose it could be my power meter, but I get the same values on an analog meter and a digital graph (mooshimeter). That's with the pinstandby example.

The thing that is driving me bonkers is in my custom code, I am using the sensorcontroller, and the power drops substantially when the sensor controller code is running (accessing the mpu9250) and then rises significantly when everything should be sleeping? That's the exact opposite of what should happen (low draw during sleep, high draw during activity).

The sleep current is ~10mA, which is pretty similar to what I'm seeing on the stock sensortag. If my meters were reading incorrectly, how would you explain the current drop to about 3mA when the sensorcontroller is running? When the sensor controller is running, the mpu9250 is powered, so 3mA is a reasonable power draw.

Is there any way to tell what is drawing 10mA when it should be sleeping?

0 spanky over 7 years ago in reply to spanky

Expert 2710 points

I think I might have figured out the idle power on my custom board (there might be a draw on one of the bmp280 lines). I’ll try removing that sensor entirely.

I’m still at a loss on the sensortag power usage.

0 Tom Allen over 7 years ago in reply to spanky

Prodigy 120 points

It might makes sense that the sensor controller draws less power when running, if the main processor is sleeping at that point. 10mA is way higher than the specs for any power domain outside of transmitting.
The Sensor controller takes about 650uA and the main cpu about 2.5mA when running according to the data sheet.
If it was a H/W problem its odd that its the replicated on both sets of H/W.

What happens if you assert the reset pin when its consuming the 10mA? Short pins 9&10 on the jtag connector (the 2 pins nearest the battery holder). I get about 47uA if I power up the board in reset and about 37uA when its reset while the pin-standby program is running.

0 TER over 7 years ago in reply to Tom Allen

TI__Guru**** 317180 points

spanky, you write "I’m still at a loss on the sensortag power usage." Do you mean sensortag or sensorcontroller? Also, you write "My power setup is basically the same as Tom's. Power leads hooked to the "POS & NEG" slots on the sensortag, amp meter in series. The debugger is physically disconnected." Do you use both a sensortag and your custom board for the current measurements are they giving the same result?

- Are you able to run your code in a launchpad (no external sensors that could increase the power consumption) to see if the current draw is as expected then?

0 spanky over 7 years ago in reply to Tom Allen

Expert 2710 points

I figured out my power draw on the custom board. I tried to drive the BMP280 power similar to the way the sensortag drives the MPU9250 power. My application sleeps the majority of the time, so even though the BMP280 is pretty light on power consumption, it seemed appropriate to "completely" disable it. Unfortunately, my pinout led to a case where power was drawn through another pin of the BMP280 when the main power was cut. That appears to have been the culprit for the high idle power since I was able to modify the board to constantly power the BMP280. Now the behavior is as expected (~1mA during activity, dropping significantly during sleep time). So in other words, that one is my fault.

On the sensortag, I'm still getting 9-11mA (depending on the LED state) on the pinstandby with the code posted by Siri and copying the sensors folder from the previous sdk. Since I found the issue on my custom board, this sensortag is no longer a priority. I'll just assume there is some flaw in this specific board since I appear to be in the minority. I haven't stepped through the sensor code to ensure its not failing somewhere.

Incidentally, when I tried shorting the pins next to the battery holder, the power draw shot way up (~40mA).

0 Siri over 7 years ago in reply to spanky

TI__Guru* 86731 points

I am glad you were able to figure out what was wrong with your custom board and are able to continue your development. Since you are measuring the correct current consumption there we can conclude that your setup is OK. We know that my code is OK since I get the correct current consumption, so I guess it is fair to say that there must be something wrong with the sensorTag that you have.

Good luck with your project.

BR

Siri

0 Tom Allen over 7 years ago in reply to Siri

Prodigy 120 points

Hi Siri,

Do you have any thoughts on the 86uA idle current consumption and the 35uA when held in reset, that I am seeing on the CC1350 sensor tag?

I can probably live with this but I am curious if I am doing something wrong as its way off from your current reading

Spanky,

It would appear there's an issue with your sensor tag since shorting the 2 pins (9&10) should only reset the processor by holding reset low

0 spanky over 7 years ago in reply to Tom Allen

Expert 2710 points

Yeah, I'm not sure how or why the current shot up just by jumping those pins, but a bad board would answer a lot of these questions. It seems to work fine otherwise.

0 TER over 7 years ago in reply to spanky

TI__Guru**** 317180 points

Tom, I haven't read through the full thread. The post I found where you described the testing you reset the unit in the middle of the program. But I assume this is the current consumption of the full board? If so, you need to check that all sensor is in the lowest possible power state before you pull the reset low.

0 Tom Allen over 7 years ago in reply to TER

Prodigy 120 points

Hi Ter

There are 2 of us on this thread Spanky and I. Our questions are similar so I jumped on his thread rather than duplicating a post.

I ran Siri's program first then pulled the reset line low which is where the 86uA to 35uA figure came from. To me this suggests the quiescent current of the board is somewhere around 35uA, when the sensors are in low power mode, because the CC1350 current is negligible in reset. (Unless pulling the reset pin somehow causes a sensor to draw more current). I have some work to do as even assuming the board takes 35uA, when my program is in standby it takes 51uA. I was just asking the question so I have a know minimum power consumption to target for the CC1350 sensortag board. I am a complete noob to TI processors and I have read through various threads and have seen various values of current consumption mentioned.so a baseline current consumption for the CC1350 sensor tag measured at the battery terminals when in the lowest power mode would be helpful.

I know there is something wrong with my code as it is. I took Siri's power down codes and integrated it with my own. I am using the sensor controller to collect values from the OPT3001 every second and then transmit a packet. The spikes below where the sensor controller wakes up to take the measurement are about 1.7mA which is a lot higher than I would expect. So I have some work to do...

0 TER over 7 years ago in reply to Tom Allen

TI__Guru**** 317180 points

"I took your code and flashed it to a sensor tag and I get 86uA in standby mode with the led off.": If you use an ampere meter, how do you measure only when the device is in sleep? Or did you remove the LED?

I would try to do measurements without setting the CC1350 in reset since I'm not sure if this could impact the sensors.

0 Siri over 7 years ago in reply to TER

TI__Guru* 86731 points

This thread is closed due to inactivity.

0 Tom Allen over 7 years ago in reply to TER

Prodigy 120 points

Thanks Ter,

I am making the assumption that between the transmission peaks (which I can observe without the led) that the device is in sleep mode.

I toggled the reset after the device has made a transmission when it should be asleep. I'll check the default IO pin settings perhaps there is something to be gained here to make up the difference between 86uA and the 38uA in reset. If you power up the board in with the reset held low i.e with no power down sequence being sent to the sensors you get close to 1mA so the sensor power down code from Siri does reduce current consumption significantly significantly.

Sub-1 GHz

Sub-1 GHz forum

RTOS/CC1350STK: CC1310 Cannot get to Low Power Mode