Tiva Sleep mode - some enlightenment required

Luis Afonso

Guru 20670 points

Other Parts Discussed in Thread: ENERGIA, TM4C123GH6PM

Hi everyone

So first - yes I know the Tiva is not indicated for low power, I should get a MSP430 or MSP432 or other low power directed MCU.
Well in one part of the project I probably will, the code is in energia and the MSP432 will do and has the advantage of Energia MT for power saving. But the other requires the Tiva for sure - still there are dead times where saving power would help. Note that both the parts of the project are battery powered.
Basically it's a remote controlled car and I want the controller to save power - again not the best use for a Tiva but the second part requires the Tiva and I want it to have power save features too (so just transport the code.

Second - I am not interested in the hibernation module, according to the power consumption table, Sleep and Deep Sleep modes will be enough - not only that but although the interrupt I require could probably use the RTC, it's extra work than using the sleep/deep sleep modes (at least it seems, correct me if I am wrong).

So some clarifications.
First, I have no idea about wake up times. There's mentions of longer or faster wake up times but what's even the slowest time? <- most important question

Second, what are the wake up sources? According to the datasheet it seems Sleep mode can be awoken from any interrupt. The same seems to hold true for the Deep Sleep - I am correct, right?

Now clocks and sleep modes implementation and getting to my problem.
So in Sleep I used it with no clock gating, no problem. Ok, clock gating - awesome. I did this by

Setting up wide timer 4 to generate a periodic interrupt
SysCtlPeripheralClockGating(1);
SysCtlPeripheralSleepEnable(SYSCTL_PERIPH_WTIMER4);
Then when I needed I would enable the timer counter and entered sleep mode.
The interrupt handler would then disable the timer (probably should set the counter value to the load value again but I was just testing it.

Tried the same with Deep sleep mode.
Clock gating on - nope, noting. But wait, maybe I should listen to the warnings on the datasheet. Took it of debug and did a power cycle. But something is wrong with how the 2 parts work together, there's "hiccups" - here is why I asked about the wake up time!
So apparently the wake up time is over 30 milliseconds or something like that? I haven't measure it precisely, just a estimation considering the 40 millisecond sleep time and the fact that the "car" requires a transmission every 70 milliseconds.

So again, can I get an idea on Tiva wake up times from the different sleep modes?
Again I probably can use the MSP432 for the remote but the "car" I require the Tiva.

over 10 years ago

0 Luis Afonso over 10 years ago

Guru 20670 points

well, I was blind to the fact that in the consumption table for deep sleep mode, there are only 2 working frequencies...
It was actually the tivaware peripheral library that gave me a heads up in the description of the system control API - the info is also in the datasheet, I just glanced over it somehow in the middle of that text. Maybe it could be a bit more clear and evident, that part at least. Like instead, "If the PLL is running at the time of the WFI instruction, hardware powers the PLL down..." and so on, how about just, "When in deep sleep mode there are only 2 possible clocks, the PIOSC at 16Mhz or the input crystal (at 30Khz)." and of course the stuff about the use of the PIOSC on communication peripherals and how the USB PLL works, that seemed alright.

Still, I would like some more info on the wake up times to satisfy my curiosity.

edit:
So since I didn't know the clock would be the 30Khz external clock, I used the value of 80Mhz for the timer load value math.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis Afonso said:
would like some more info on the wake up times

At least to me - it's unclear if you've seen the following: (this from our LX4F MCU manual)

Thus - when in "deep sleep" it appears that (well less) than 1mS (chart shows 350µS as typ.) is your desired "wake up" time. I'd ask if you (really) have the (typical) 32KHz (external) xtal installed?

MCU manual shows (poor) power savings when in "sleep" mode - greatly improved when in "deep sleep."

Your listing of ~30mS to "wake" may deserve some explanation - I can't see it from good, several minutes read/review of manual... Indeed if using the "main oscillator" (see the "c" listing, above) you incur the potential (max) wake "penalty" of 18mS, additional - that's dreadful... [edit] Note: it appears this 18mS may be avoided by running under PIOSC and internal ~30KHz oscillator - it is (my belief) primarily caused by the external xtal.

We note that you (properly) avoided the over-use of "punctuation marks" to "gain attention" - instead relying upon a detailed description of your issue & efforts. Bravo!

0 Luis Afonso over 10 years ago in reply to cb1_mobile

Guru 20670 points

Oh wow thanks cb1. I didn't search for the times in the electrical characteristics. In the TM4C123GH6PM it's table 24-23.

The 30ms was explained in my "answer". I overlooked the fact that the PLL does not work in Deep sleep mode so for the timers the source clock is the external crystal (yes 32Khz, not 30Khz) - so the math 80Mhz/25=a 40millisecond delay does not work because in deep sleep mode this would mean a long, long delay. The delay was actually 106 milliseconds.

I noticed sleep mode wasn't that big of an improvement, but maybe it's mostly because sleep mode runs always with a slower clock, while sleep mode allows 80Mhz. If you check sleep mode at 16Mhz or 30Khz, the difference between it and Deep Sleep mode is not that big.

The 360us will do just fine - the car actually has enconders but they are "after the gearbox" and the "ticks" are far apart enough - meaning it can sleep between motor speed updates since the QEI can read itself the ticks... and I just realized that that would require for dynamic ajust of the QEI timer values (because of the varying clock source).
Well I'll see if I'll figure something nifty, for now at least the controller is lower power, that's what was most important for me.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

You're welcome, Luis. Again - good detailed (caring) post from your pen.

That said - let's NOT (yet) "drink that 350µS wake-time" Kool-Aid! Why's that - look carefully at "c" - at the base of the timing chart.

"If" using the master oscillator - it appears that a "penalty" of (up to) 18mS is extracted! (I added that to my post as you were composing your response) That's horrendous - I don't believe that same (significant) time penalty lands @ other ARM MCUs... You may wish to "clarify" the full meaning of "master oscillator" - to see how damning this may be...

[edit 23:48] Upon my 3rd read - it now appears that this ~18mS (max) time penalty is only inflicted when an external xtal is employed with the main oscillator. Thus - if you "run" w/PIOSC and w/MCU's "internal" (very roughly) 30KHZ oscillator - you AVOID that horrendous time penalty! And - in fairness to this vendor - that time loss is primarily caused by the external xtal - not an MCU weakness!

(as a result of this above edit - statement below has declined (greatly) in value...)

Your avoidance of "hibernate" may deserve a "re-think" as it may prove a superior alternative; if this ~18mS (dead-time) cannot be some way/how escaped...

0 cb1_mobile over 10 years ago in reply to cb1_mobile

Guru 117855 points

Hi Amit,
If by chance you "wander" here - might you confirm my (now) belief that this potential 18mS "wake-delay" occurs "only" when an external xtal is employed w/the main oscillator? Thank you...

0 Amit Ashara over 10 years ago

TI__Guru**** 244400 points

Hello cb1,

The 18ms penalty when using external oscillator is correct. However there are other ways of getting to 18ms based on the LDO setting in deep sleep and the clock divider in deep sleep, it is possible to get the same time with the internal oscillator as well.

Regards
Amit

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

Wait what so this applies with how I am using it?
So Table 24-24. seems to give further clarification. So how I think I was using it would mean a 19ms delay to wake up (run mode = 80Mhz with PLL and Deep Sleep = external crystal) - right?

So let's analyze this. Apparently Energia already configures some stuff (hidden startup configs is why I usually don't use Energia mixed with Tivaware).
Energia sets the LDO voltage to 1,0V instead of the max 1,2V, the Ram and Flash to low power mode and actually sets the low power mode to use the PIOSC with 16x division (1Mhz).
So with this I should expect, according to the table 145.64us wake up time.
I will edit the code to my liking.

Now I ask, because I am using the main oscilator to power the PLL in run mode, do I have to always add the 18ms to any value of the table?
If so I will try to instead use another source to power the PLL

0 cb1 over 10 years ago in reply to Luis Afonso

Guru 47900 points

This plot thickens - especially with Amit's recent, " there are other ways of getting to 18ms based on the LDO setting in deep sleep and the clock divider in deep sleep..."

Oh my head - simple answer - not in the cards here (one fears) Luis...

What appears necessary - and most helpful - is the "exact" requirement listing to, "AVOID the dreaded 18mS time add-on to "escape" deep sleep!" MCU manual - spec section - appears to have "ducked" the (apparent) "other ways" of incurring dreaded 18mS time eater! And - worse still - this appears NOT the fault of external xtal demand! (my head hurts even more)

0 Luis Afonso over 10 years ago in reply to cb1

Guru 20670 points

Yes there seems to be cb1, you can basically shut down everything like RAM and Flash, lower the voltage to 0,9V and that will give you long wake up times.

The Table 24-24 really seems to be missing both Tready time for the PLL and Tstart time of the main oscillator. Amit Ashara, can you confirm?
I'm just gonna use the PIOSC as the PLL source, set the power saving features to minimum (flash and ram normal as well the LDO) and also the PIOSC as the deep sleep mode source. This should give me a wake time of 66.47, with 64us being the Tready time of the PLL starting up.

Hibernation is not an option because of the possible wake up sources :/
And enough time was given into this I think as it is not top priority for the device to work.

0 cb1 over 10 years ago in reply to Luis Afonso

Guru 47900 points

T(start) is listed for our past LX4F - I saw that last night! (look again - search on Tstart)

0 Amit Ashara over 10 years ago in reply to Luis Afonso

TI__Guru**** 244400 points

Hello Luis,

The Table does not have the main oscillator start up time due to variations in startup time from crystal manufacturer to another.

Regards
Amit

0 cb1 over 10 years ago in reply to Amit Ashara

Guru 47900 points

Hello (both) Amit & Luis,

May I note that the equivalent of our past LX4F (TM4C123AH) does include Tstart. (see below)

We note that (any) external xtal is avoided via use of the PIOSC - thus "blame" cast toward xtal maker seems misplaced. Multiple other MCUs are able to "wake" far faster than the 18mS - thus far - reported here.

Is not the use of PIOSC (perhaps w/out PLL) and the internal ~30KHz LF osc - one method to "escape" the dreadful 18mS "wake penalty?"

0 Luis Afonso over 10 years ago in reply to cb1

Guru 20670 points

Well I went ahead and measured the current.

I was actually quite stupid, well the laptop is not connected to the outlet so no problem in powering the tiva by USB and measure the voltage drop with the oscilloscope right? Wrong! I am using a external monitor so the ground is common by the VGA cable... Let's just say my finger really hurt right now.

With nothing connected to the tiva e used a 2.2R resistor 10% of 11W rating. The values we're really high (like 100mV in sleep mode = about 50mA). I assumed it was either a faulty resistor or because the voltage drop was too low (I will have a class starting next week about these type of things).

So I used a 22R resistor also 10% and 11W. So now in sleep mode the average voltage drop is 9,86mV! With a 22R resistor that means less than 1mA? That's can't be right. Even in run mode it says something like 2mA.
So failure to read it again...

Tried with the anmeter just to read the current consumption in Deep Sleep mode and it gave me 48mA.

So I feel supid now.

About the wake up time my setup is:
Flash and Ram normal
Run mode at 80Mhz using the PLL which uses the PIOSC as source
Sleep mode uses the PIOSC with 16x division.
While sleeping only GPIOF and Watchdog timer 4 enabled

Did a small test just to get a general idea of the wake up time. I have a 40ms sleep time between sending data to the RF transceiver. Meaning that I should have more or less 40ms between chip select cycles (it works by SPI). Well ok, let's measure it with the scope.
The result is 40,06ms. I would say the 18ms is not present.

0 cb1 over 10 years ago in reply to Luis Afonso

Guru 47900 points

Luis Afonso said:
with the anmeter just to read the current consumption in Deep Sleep mode and it gave me 48mA.

Pardon - but ~50mA is listed w/in our LX4F manual as consumption - when Running - at/around 50MHz.

Thus two conclusions may be drawn:

your measurement technique is (still) faulty
you have not (properly/fully) placed the MCU into "deep sleep."

Other ARM MCUs which we use are well able to drop (consumption) to sub 100µA when in "deep sleep." And then "wake" far faster than the (pardon) mish-mash of convoluted if/then/when "spec reads" apparently required - to learn (maybe...potentially) what's what - here!

None of this registers as Amit's fault - he appears caught (almost) as off-guard as we humble users. The "wake/sleep/deep sleep" spec is, "clear as mud" (unkind to mud) and this cascade of posts seems not to have led to any (usable) wake time. (as you originally requested)

0 Luis Afonso over 10 years ago in reply to cb1

Guru 20670 points

Hi cb1,

Kinda gave up for now on the sleep mode. Been having fun, finally with the rest of the parts in hand I've been having fun.

The part seems to go into sleep mode. It doesn't do anything until the timer wakes it up - but for some reason the consumption does go down? I dunno want to think of it :/

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

Amit Ashara ,

Well as I said, I measured with the ammeter the current while the tiva was in deep sleep mode and it did lower a bit... from like 55 to 48mA.
The device seemed to be sleeping since it did nothing until I pressed a button connected to a pin with a interrupt.

I did test this with a Energia sketch in CCS so maybe one hidden setup that I don't know about (there are some that I caught) could be causing this.
I'm gonna try to attempt the same test later with TI compiler with a clean project (no Energia sketchs), but only when I get access to the ammeter and have finished most of what's left to do in the project.
If you have a ready to go example to test it with I would appreciate it to serve as a basis to know it's my programming's problem. I didn't find anything in the Tivaware folder besides about the hibernation module.

No examples... seems like something I could easily add to the blog later in a slow day.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis Afonso said:
I measured...the current while the tiva was in deep sleep mode and it did lower a bit... from like 55 to 48mA.

Pardon - but at best you've entered "vanilla" sleep - surely NOT "deep sleep!" That said - if your time w/in, "Deep Sleep" is brief - your "ammeter" may be unable to detect and display that "Deep Sleep" current! Have you considered that?

A scope - placed across a properly sized current sense resistor - feeding 3V3 to the MCU - is far better equipped to detect & measure (any) Deep Sleep current...

0 Luis Afonso over 10 years ago in reply to cb1_mobile

Guru 20670 points

The ammeter is not a portable one. It's a big desktop from UNI-T. It has not only mA range but also uA range. The uA range was always over the maximum value.

The scope I will have to see better but the values seemed completely wrong...

cb1_mobile said:
but at best you've entered "vanilla" sleep - surely NOT "deep sleep!"

I should have said - I used the Deep sleep function and the tiva did enter some sort of sleep mode.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis - understand that you've (earlier) and (repeatedly) stated that you "transition" your MCU between RUN and Deep Sleep modes. Now - if the time w/in "Deep Sleep" is brief - your ammeter (even a Big, Desktop, Bench ammeter) may not properly display so brief a transition into, "Deep Sleep." (and that is likely true whether your ammeter is digital or analog)

What's critical here (and perhaps not (yet) recognized) is the "Duty Cycle" of your MCU's time w/in "Deep Sleep!." If that duty cycle is small/brief - you (almost surely) will MISS it - unless you've got a scope - which may capture such "transient" events! Your ammeter (even Big, Desktop, Bench) ones - is unlikely to display such transient events...

Now - it is "within the realm" that you've (for now) abandoned your earlier report of regularly transitioning your MCU from RUN to Deep Sleep. Recall that you did that so that you'd reduce power consumption AND (still) be able to detect your regularly arriving, QEI pulses. (law school enables one to recall - and recite - such "facts in evidence")

Have we entered the same page? Have you made operational changes - yet not described them (yet) - at all - here?

0 Luis Afonso over 10 years ago in reply to cb1_mobile

Guru 20670 points

Yes, yes. I wasn't clear enough in how I tested.

I used the scope first just because of that reason.
But then to check with the ammeter I checked with the MCU always in some sort of sleep (whatever it was, supposedly it was deep sleep), maybe I wasn't clear in my first post today.

The MCU was in deep sleep. Only to wake up when I pressed a button. But... maybe there was something with the energia sketch, I don't know. So I want to test with just using Tivaware (one of the reasons why I usually don't use Energia - hidden configs).

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis Afonso said:
Yes, yes. I wasn't clear enough in how I tested.

True that - not to "beat" you - yet you/I "squawk" (endlessly) when "Unguided Posters" are guilty - of just that! (although heralded vendor sees, "No Need" for such guidance!)

So - as logic suggested - you've abandoned (for now) your regular transitioning between RUN and Deep Sleep. Yet - in my review of the MCU's Sleep/Deep Sleep consumption - Sleep reduced consumption by LESS than 10mA (likely to ~40mA) - but Deep Sleep reduced consumption to UNDER 1mA (perhaps even 10x lower!).

Thus - you've (rather clearly) determined that:

you're NOT in Deep Sleep (or)
MCU manual is wildly inaccurate in listing < 1mA as current draw while in Deep Sleep

The addition of (famed) Energia to this mix has NOT proved helpful. There exists a "great" lake bordering Chicago (cb1 current location) and (I'm told) it beckons "Energia!"

0 Luis Afonso over 10 years ago in reply to cb1_mobile

Guru 20670 points

I do try to follow that but sometimes still fail to follow those guidelines unfortunately.

Well, Energia was to save time and effort on the use of some parts like the LCD (I have it working perfectly fine in Tivaware but I intend to use another one) and the transceiver.

Power saving was a nifty feature and a convenience but just that. If it slows down the project then it's not worth. Now as something to add after all is done, that I will think about it. But the current measuring with the scope I have to check again... was the resistors damaged, the scope or the probe or maybe I had the wrong settings or setup? I must know.

I will come back here with a more detailed test later.

0 cb1_mobile over 10 years ago in reply to Luis Afonso

Guru 117855 points

Luis - even w/the "hiccups" you've provided a great service for many here. The concept of "Deep Sleep" (not so much "vanilla Sleep" as it's insignificant, IMO) has great value - why "burn battery power" when that may be avoided?

Years past we employed LX4F (similar to TM4C123) and it (allegedly) contained both Sleep & Deep Sleep. I will try to "carve the time" tomorrow - and monitor one of our (past) BLDC Control boards - minus the FET power stage. If all goes well - I'll be able to measure current drawn while in RUN, SLEEP & DEEP SLEEP. I'll then post those Tek Storage Scope Caps.

Truth in advertising: while I won't be able to make a "pure, MCU only" current measurment - I should be able to detect (and present) the board's variation in current draw - when in RUN, SLEEP & DEEP SLEEP. Possible "fly in the ointment" years have passed since I've last done this - I may not recall (exactly) how to transition into SLEEP & DEEP SLEEP.

Again - should Amit (land) here - if he (or others) can provide the appropriate calling functions (recall we only use StellarisWare - in compliance with our clients' wishes) such should ease, speed & enhance my report...

0 Amit Ashara over 10 years ago in reply to Luis Afonso

TI__Guru**** 244400 points

Hello Luis

Even with PIOSC, the deep sleep current of 48mA is way too high. Are you sure that the debugger is disconnected?

Regards
Amit

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

"So let's do this without powering by USB to monitor the current..."
God dam it, I forgot to remove the jumper XD.

Still, the variation in current itself wasn't that great. I really have to test it out again more thoroughly.

0 Amit Ashara over 10 years ago in reply to Luis Afonso

TI__Guru**** 244400 points

Hello Luis

What is the platform you are using to run the application code for deep sleep?

Regards
Amit

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

It was Energia sketches in Code Composer Studio.

PS: Note that as I said before, Energia sets deep sleep modes to use Flash and Ram to 0x21 config, I set it to 0x00 in the source files since the tabled power consumption was good enough and I wanted fast wake up times.

0 Amit Ashara over 10 years ago in reply to Luis Afonso

TI__Guru**** 244400 points

Hello Luis,

I meant the LaunchPad Platform being used. Also what are the configuration calls for deep sleep other than Flash and Ram Configuration?

Regards
Amit

0 Luis Afonso over 10 years ago in reply to Amit Ashara

Guru 20670 points

Launchpad: TM4C123

Configs:
Clock - 80Mhz
Source - PLL which itself was using the main oscillator or the PIOSC (tried both)
Flash and Ram set to normal power usage
The clock while in deep sleep is the PIOSC divided by 16 = 1Mhz.
A system tick interrupt native to Energia is disabled while in Deep sleep mode to avoid waking up
Clock gatting is set to 1 - only the wide timer 4 and GPIOF should be enabled when deep sleeping (I used the Deep sleep function to set them)

0 cb1 over 10 years ago in reply to Luis Afonso

Guru 47900 points

Luis,

Believe that Amit (instead) is seeking the, "Function Calls" employed to place the MCU into, "Deep Sleep."

Under (past) StellarisWare: SysCtlDeepSleep() was employed.

Note too that (multiple) other function calls may be required to maximize current reduction!

SysCtlPeripheralDeepSleepEnable() and SysCtlPeripheralClockGating() (for sure) and possibly SysCtlDeepSleepClockSet().

We've not used this in years - but I do recall substantial "power savings" via this method. (as was your thought...)

0 Luis Afonso over 10 years ago in reply to cb1

Guru 20670 points

Ah sorry,

I can't give you those ones now, I'm not in my laptop (which now is a desktop thanks to my faulty screen)

Arm-based microcontrollers

Arm-based microcontrollers forum

Tiva Sleep mode - some enlightenment required