RTOS/CC1310: big difference of sleep current consumption between IAR & CCS compiler

Hi,
I just tried the pinStandby example project in the non-RTOS mode using IAR, and can get the correct sleep current consumption, almost the same as CCS .
but, now, why in IAR, in RTOS example project, it gives so high current consumption in sleep mode on the same board?

B/R,
Shaowei

Hi Shaowei,

If the current consumption is 3 mA the device is not going to Standby mode. Can you see if there is anything in your IAR project that would hold the device in Active mode?

Cheers,
Fredrik

Dear Fredrik,

Thanks for the attention.

anyway, we just use IAR to import the official example project in the package, and test it.

we didn't make any changes on the codes.

as I mentioned in the last post, when we  test the same TI-RTOS project in CCS, it's ok; or, when go non-RTOS project for the pinStandby project in IAR, the measurement also shows OK.

only the TI-RTOS pinStandby project in IAR compiler , the measurement shows NG.

as our earlier development on a CC1310 project used IAR and based on TI-RTOS. basically the frame works. now we need to add the sleep functions.

but faced some issues. so we test the standard pinSandby project, and got the above result.

can you help to figure it out?

or, is there any simple command to force the chip CC1310 to enter standby mode, regardless the power policy setting? think this might give more help on many project.

B/R,

Shaowei

Hi,
today, we do further test.
and, we import an another project from the example of TI-RTOS- simplelink_cc13x0_sdk_1_50_00_08 package: rfPacketRx .

to simplify the test, we just mask some code , and insert there a few piece of sleep codes.
in CCS, it works;
in IAR, it DOES NOT.

so, think there should be something error there in IAR setting, but i don't know. ..

and, here is the test code :
in the project file: rfPacketRx.c
....
#if 0
/* Enter RX mode and stay forever in RX */
RF_EventMask terminationReason = RF_runCmd(rfHandle, (RF_Op*)&RF_cmdPropRx,
RF_PriorityNormal, &callback,
RF_EventRxEntryDone);

switch(terminationReason)
{
case RF_EventCmdDone:
// A radio operation command in a chain finished
break;
case RF_EventLastCmdDone:
// A stand-alone radio operation command or the last radio
// operation command in a chain finished.
break;
case RF_EventCmdCancelled:
// Command cancelled before it was started; it can be caused
// by RF_cancelCmd() or RF_flushCmd().
break;
case RF_EventCmdAborted:
// Abrupt command termination caused by RF_cancelCmd() or
// RF_flushCmd().
break;
case RF_EventCmdStopped:
// Graceful command termination caused by RF_cancelCmd() or
// RF_flushCmd().
break;
default:
// Uncaught error event
Assert_isTrue(false, NULL);
}

uint32_t cmdStatus = ((volatile RF_Op*)&RF_cmdPropRx)->status;
switch(cmdStatus)
{
case PROP_DONE_OK:
// Packet received with CRC OK
break;

// .......

default:
// Uncaught error event - these could come from the
// pool of states defined in rf_mailbox.h
Assert_isTrue(false, NULL);
}
#endif

while(1){
RF_flushCmd(rfHandle, RF_CMDHANDLE_FLUSH_ALL, 0 );
RF_yield(rfHandle);

Task_sleep(5000L*100);
};
}

hope, you can help us to solve the issue.

B/R,
Shaowei

Hi, I tested the IAR pinStandby example with IAR 8.11 (as is, without modifications), and I see a average power consumption of 1.1 uA:

I used the CC1350Launchpad_433 project as I encountered some issues with importing the files with the CC1310Launchpad project.

Since you are measureing  correct numbers with CCS, we can exclude any board settings.

Can you try to import the above mentioned project as described in the IAR information center (Creating SimpleLink SDK applications in IAR Embedded Workbench) and (After the initial setup, browse example applications)?

Hi, FredG ,

Thank you for the details.

yes. and we tried to test the example project in CC1350Launchpad_433, and seems no problem; we download it to CC1310_launchpad board, still ok.

then we back to the example on  CC1310_launchpad project folder, re-import it, built it, and run it, problem still there. very strange.

and then, after 3 days tired testing, we decide to give it  a try: reinstall the CC1310 SDK ( simplelink_cc13x0_sdk_1_50_00_08 ).

and then do the same procedure,  seems the problem disappeared. even the previous problem example now becomes ok.

I still don't know what cause this issue. anyway, now seems program runs ok.

maybe, you can have us some hints  which can cause the sleep function failed. 

hope this kind of fail didn't come up again.

B/R,

Shaowei

A bit off topic, but I what equipment did you use to make those measurements?

I'm about to enter the "energy" phase of a project, and would like to know what's the best/cheapes/most cost efficient way to measure the consumption in my devices. Any tips are welcomed.

Thanks

Hi, Caio Alves ,

for general purpose measurement, a normal multi-meter with current measurement ability will do the job.

normally it can give the accuracy at uA somewhere.

think it's enough for most application.

and, it can give the indication the device is sleep or not.

we can just insert the meter's input probe into the power supply line to get the current reading.

cheers,

Shaowei

Hi Caio,

Due to how the device runs in Standby, which you can read about here: www.ti.com/.../swra478, a regular multimeter may not be able to measure the current consumption accurately. A dedicated power ananlyzer is often required.

Regards,
Fredrik