LAUNCHXL-F28379D: C2000Ware lpm_ex2_idlewake example current consumption not changing

Hi,

IDLE current on 3.3V supply is between 3mA - 10mA, also 1.2V supply is used for Clock, so Idd should change significantly like you indicated, 3.3V supply current does not change that much between IDLE and operational.

Also, I am not clear on why you are measuring current on JP1. Why don't you measure current separately on 3.3V or 1.2V supply?

Regards,

Nirav

Hi,

I don't see a spot on the LaunchPad which allows the 1.2V rail current

to be measured without cutting track so I measured it indirectly as it loads the 3.3V rail.

Any thoughts on why the current on the 1.2V rail isn't changing and in turn changing the 3.3V current? 

Hi,

Ok, thanks. Can you please confirm following:

Are you supplying power through USB?

How are you measuring current on JP1, are you using current probe?

3.3V current that you indicated includes VDD 1.2V current as well. 3.3V is regulated by TPS62080ADSGT which generates 1.2V for the device. If you want to isolate the USB supply you can directly supply 3.3V through external supply. You will have to change jumper configuration for that, please go through Launchpad user guide for that.

I am not sure what the issue is? Overall 142mA current during IDLE operation looks correct. If you look at the Datasheet, typical total 3.3V+1.2V current is 110mA, since you are not directly measuring device current it also includes current of different components on the board, so 142mA looks reasonable.

Regards,

Nirav

Hi,

Yes power is supplyed via USB as it passes through the header at JP1.  The jumper is removed and a wire loop and scope clamp is put in place.

No need to isolate the USB supply, it is as good a source of 3.3V as any other for this c2000ware example.

Are you simply adding the 1.2V rail current and the 3.3V rail current to arrive at 110mA?  The TPS62080ADSGT is a switching controller it has a much better efficiency than the 36% this addition implies.  Following through on this approach the Operational current should have risen to approximately 325mA + 30mA + other loads =  greater than 355mA.  It was 159mA, only a 17mA change.

The problem as stated is that the current difference between the IDLE and Operational state is not what it should be:

From the datasheet I expected Idd to change from 80mA to 245mA approximately.  Assuming a 85% efficiency in converting 3.3V to 1.2V I expected to see approximately a 71mA change at the 3.3V rail based on the following; (245mA -80mA) * 1.2V/3.3V /0.85 = 71mA .

Regardless of the other loads on the board the difference between IDLE and Operational should be seen (for a difference measurement the other loads cancel out).  Could you please consult with someone with a hardware background so the issue becomes clear.

Thank you.

Looking at this closer, the launchpad board should show an even greater difference between IDLE and Operational.  My numbers were from the "S" version on my target board.  The lanchpad board has the "D" version so the current difference should be (325mA-105mA) * 1.2V/3.3V /0.85 = 94mA.  The measured difference was only 17mA.

Hi,

How much current you see before entering IDLE mode? Also, what is the PLL configuration, meaning what is the PLL output frequency?

I am suspecting, that PLL is configured slower than 200MHz, hence currents are not corelating to DS numbers.

Regards,

Nirav

The c2000ware example doesn't wait to enter IDLE.  The possible measurements are IDLE followed by Operational after triggering XINT1.

Here are the c2000ware PLL details contained within the example for launchpads;

//

#define DEVICE_OSCSRC_FREQ 10000000U

//
// Define to pass to SysCtl_setClock(). Will configure the clock as follows:
// PLLSYSCLK = 10MHz (XTAL_OSC) * 40 (IMULT) * 1 (FMULT) / 2 (PLLCLK_BY_2)
//
#define DEVICE_SETCLOCK_CFG (SYSCTL_OSCSRC_XTAL | SYSCTL_IMULT(40) | \
SYSCTL_FMULT_NONE | SYSCTL_SYSDIV(2) | \
SYSCTL_PLL_ENABLE)

//
// 200MHz SYSCLK frequency based on the above DEVICE_SETCLOCK_CFG. Update the
// code below if a different clock configuration is used!
//
#define DEVICE_SYSCLK_FREQ ((DEVICE_OSCSRC_FREQ * 40 * 1) / 2)

Hi, 

PLL configuration looks correct, it is at 200MHz. Are you running CPU1 ONLY or both the CPUs? Also try running any other test case to see the current consumption?  You can also use the same test case, but comment out line in the code where it enters IDLE mode

// SysCtl_enterIdleMode();  --> Comment out this line

DS typical operating current numbers takes into account both the CPUs running, code executing from Flash, RAM read/write operation, all the peripherals turned ON etc. Basically it is actual application used case, so DS operating current numbers will be higher than what you are measuring using idle test case.

Regards,

Nirav

I am running the TI provided example noted in the subject, there is no CPU2 version.  Can you please try this example?  Shouldn't these work as is to provide an example of the benefits of the low power modes?

Here is the path in a typical install; C:\ti\c2000\C2000Ware_3_02_00_00\driverlib\f2837xd\examples\cpu1\lpm .

Did you see the part of the posting where I said the following?

By reducing the PLL multiplier the scope shows significant current savings.  I was hoping to see the same from IDLE since it gates the CPU clock.

The CPU is obviously using current with the TI provided example and this current can be reduced by lowing the clock rate.  IDLE, if it is working, is said to gate the CPU clock.  Therefore it should provide even more current reduction then what was observed by testing with reduced clock rates.  From what I am seeing the c2000ware example is unable to properly enter IDLE mode.  Could you please bring this issue back to the c200ware team for verification / clarification?

Hi Collin,

This example has been checked out, and is working at my end. By gating clock to the CPU alone does not save that much current. Please refer table "5.9.8.1 Clock-Gating Low-Power Modes" where it shows different LPM modes and clock gating.

SYSCLK gating gives biggest current savings, you can validate that by running STANDBY example.

I did see your post on scaling down the PLL multiplier reducing the current, that is expected as you are reducing SYSCLK frequency. 

In order to debug the issue at your end, and make sure if device is entering IDLE mode or not, please try following

Comment out the line in the code where it enters the IDLE mode (I mentioned earlier in the thread), this will give you actual operating current of this test case without entering low power mode. If this current is significantly greater than ~159mA, then your point is valid that device is not entering IDLE mode.

Regards,

Nirav

Thanks for checking out the example at your end.

• What was your measured current before asserting XINT1?
• What was the current after asserting XINT1?
• Where and how did you measure the current to find it is working at your end?
• Can you explain how you concluded that the above measurements indicates the example is working (please show your calculations as I have)?
• You now say that IDLE "does not save that much current" by gating the CPU and that STANDBY "gives biggest current savings".  Can you explain that in the context of datasheet table 5-1?

• You are suggesting the STANDBY example, what current savings does that example provide when measured as previously described?

I'm not near the Launchpad hardware and will have to try the recent suggestions later, in the mean time can you please answer the above questions?

Thanks.

I did not measure current, but ran the test case to make sure it executes IDLE instruction, and also got the Wake Up Interrupt INT1.8, which tells me that device is going in IDLE mode. So there is nothing wrong with the test case in C2000Ware. 

If you are looking for biggest current savings then you should use HALT mode, again please go through the Datasheet  and TRM, and you will see the difference in clock gating schemes between different Low Power Modes. Here is the order of current consumed in different low power modes (ascending, lowest to highest):

1. Halt

2. Stdby

3. IDLE

I dont think their is any problem with IDLE test case, and the currents you are measuring seems in the ball park of what I would expect. If you still suspect that device is not entering low power mode on your setup, then please run the experiment that I suggested when you get a chance. We can proceed further based on your findings. Also you can try STDBY/HALT testcase if you want to save more currents.

Regards,

Nirav

Hello Nirav,

From the beginning we know that the IDLE instruction was executed, current consumption reduced a bit but not the documented 225mA.  STANDBY only provides an incremental 75mA as per the table above and not usable in my case due to loss of peripherals.  As stated, GPIO1 was scoped as per the example documentation, so it is also already know that the XINT1 ISR had run.  Your test that IDLE executes and the ISR runs doesn't contribute any new information toward reproducing the datasheet documented current savings.  Thank you but I don't want your help any further.

I see that around 70 users are viewing this post.  May I ask if any of you have had experience with using IDLE in the Delfino family?

• Possibly someone has tried this with a different target board and have seen greater current reduction?  The Lauchpad I am using has a built in XDS100v2 which is nice but not being able to remove it might have something to do with proper low power mode operation.
• Possibly someone has low power mode test firmware that does more than an infinite loop such as the c200ware example?
• Since this is about current measurement and achieving datasheet results I'm wondering if anyone has a target board that allows the 1.2V rail to be measured directly?  At the risk of damaging my board I'm exacto knife in hand and desperate to get this measurement.

I'm sure the Delfino designers worked hard to achieve this low power mode and I would like to ensure that my product can benefit from this.

Thanks.

Hi Colin,

You will achieve 225mA of current saving by going in IDLE mode if your operational used case is consuming 325mA of current. IDLE test case that you are using from C2000Ware is not representative of Operational testcase that was used to compute datasheet current limits for Operational Currents. Datasheet operational current takes into account worst case numbers where device is running using all the resources (please refer foot note #4 of the table above in DS). 

Your comparison of currents after coming out of IDLE mode to the operational currents in the Datasheet is not a one-to-one comparison. Device is not suppose to consume 325mA current if not in Low Power mode, operational current varies with the used case condition, and what is reported in the DS is worst case used case numbers that can be used to design regulators.

Regards,

Nirav