LAUNCHXL-CC2640R2: Making sense of "real" power usage

Loading the drivers/empty project yields the following power usage.

I assume the RF core is switched off?

At the bottom you can see the RED LED line toggling with jumper obviously remove.

I assume a timer is running since the sleep of 1 sec, but the power "spike" seems excessive?

And the results seems the same as in opening post.

All of this makes no sense because. 

ULP advisor give the following output:

Description Resource Path Location
#10371-D (ULP 1.1) Detected no uses of low power mode state changing instructions empty_CC2640R2_LAUNCHXL_tirtos_ccs

Hi Jan,

I suggest you refer to this document.

https://www.ti.com/lit/an/swra478d/swra478d.pdf

Also, the POWER_SAVING symbol needs to be always set.

If you have properly modified the example program like simple peripheral to beacon mode, you should see advertising peak current of around 7mA if TX Power is set to 0 dBM

-kel

Thanks Markel

I did not mention that document, but I have it as well.

The projects I'm testing are stock standard and POWER_SAVING is set.

My problem is I don't see the expected behaviour as those documents suggest, and that is my issue.

I'm trying to mimic those results.

I'm using a Nordic Power profiler II, which we use on ST-WB55, ST-BlueNRG & ESP32.

They all have quirks to work as expected, on the BlueNRG for instance it was the watchdog causing issues if left unconfigured.

I can see the BLE Advertising current spike, but there is a lot of other unexpected behaviour which I'm trying to work as those document suggest.

And more testing...

Created a new TI-RTOS project from SYSBIOS examples and implement only 4 I/O lines for testing.

The main only configures Power, Pins and BIOS_start(), that is all it does.

I made a copy of the stock standard  PowerCC26XX_standbyPolicy -> PowerCC26XX_customPolicy

And added for I/O lines to go low as it enter that state to debug:

1. ENTER Policy

2. DeepSleep

3. Sleep

4. Power_Sleep(Power_Standby)

Essentially these are the important steps in this routine where the processor will sleep.

Below is a graph of my results

This is only the first 100ms after boot and you can see how the routine works.

And all of this is expected, although the current consumption is high, but explainable at least.

The power peaks happen when not sleeping and the current consumption seems as expected.

From the lower I/O we can learn the processor has entered Power_sleep(PowerCC26XX_STANDBY);

Therefor the processor is forever in this state and then I see the unexplainable happen of quick 8mA+ peaks.

I'm guessing this must be the radio which is unconfigured?

I have tried to explicitly disable advertising, but the current peaks are the same.

Hi Jan,

I suggest you test with just the launchpad and without sensor connected to it. Also remove all jumpers. You should see something like this at your current consumption profiler. In between advertising there should be a dc to dc recharge pulse. 

Click the pic to enlarge.

-kel

Thanks again for helping Markel!

I have ordered new kits that supports EnergyTrace, the CC2640R2 and CC1310 does not have it.

New kits on the way for CC2642 and CC1312, which is what was used for testing in those documents.

But just to add I don't even have any BLE configured now.

Yes everything is removed from the board, I'm powering from 2x AA battery pack via the power profiler.

Nothing else, just the launch kit and all jumpers off.

But we see same results on our end product.

Jan Zwiegers said:

Created a new TI-RTOS project from SYSBIOS examples and implement only 4 I/O lines for testing.

The main only configures Power, Pins and BIOS_start(), that is all it does.

I suggest you test with a BLE example program like simple peripheral. After power on the simple peripheral will advertise, but the program is not optimized for low power consumption so expect higher base current consumption.

At simple peripheral you do not need to change anything at main(). Just keep in mind that what adds to base current consumption are external peripherals, open UART, and XDS110 circuitry.

-kel

This is where my project started, everything works without POWER_SAVING defined.

My application is already working with sensor controller app that triggers the main CPU, but I'm trying to achieve <30uA when idle.

The beacon advertises 2x on every sensor controller notification and works perfectly.

So the power peaks are correct when not using POWER_SAVING, but idle current is around 600 to 800 uA.

As soon as I enable POWER_SAVING it breaks and the undefined behaviour starts.

So I'm trying to work from the basic application parts to understand what is wrong and how to fix it.

My conclusion is the processor is in Power_sleep routine inside Powercc26CC.c and the next part to debug.

From my I/O debugging I can see it sits forever inside that routine.

i.e no UARTs configured for debug output tracing.

Again I'll extract that function and implement a test version.

OK that done...

The only power dependency is this

if (Power_getDependencyCount(PowerCC26XX_DOMAIN_PERIPH)) {
   poweredDomains |= PRCM_DOMAIN_PERIPH;
}

Not sure what that is, but the processor runs up to PRCMDeepSleep()

And then the weirdness starts.

For for now for me it seems like a silicon fault.

I'll wait for my new kits and test on different MCU's but this is where it ends now unless I get new ideas.

So just for the record, since our local FAE queried this, you graph shows exactly the problem.

Look closely, you are idling at 600-800uA, which is the same result what I got before I started this thread.

When you create a new project from the examples, POWER_SAVING gets undefined, look under, Arm Compiler Settings -> Predefined Symbols -> Undefine

If you take this out and re-run you will get the results I got.

You never went into full power down mode.

Please see my last post, I found an explanation for this.