Welcome to the PowerManagement Framework tutorial
for the CC3220 wireless MCU.
The objective ofthis tutorial is
to understand various low powermodes for the CC3220 device,
and to familiarize the user withthe Power Management Framework.
After this tutorial, youwill be able to understand
the various low power modessupported by the CC3220 MCU,
work with the Power ManagementFramework within TI Drivers,
configure the peripheralsusing TI Drivers,
initialize and enable thePower Management Structure,
specify I/O parking for lowpower modes, and finally,
debug the PowerAware application.
The CC3220 device supportsthe following power modes--
sleep mode-- which is a standardlow power mode for the ARM
Cortex-M4 processor, lowpower deep sleep mode--
which I'll be referring to youas LPDS for this or tutorial.
In this mode, the functionalclock and peripheral clocks
to slow clock continuesrunning in the background.
Lastly we have hibernate,which is an extremely low power
mode that shuts down boththe application and network
The slow clock continues torun in this mode as well.
This diagramshowcases the features
of each of these power modes,along with the relative current
consumption and wake-up time.
The arrows is on theright depict two things.
One, that thecurrent consumption
decreases from sleepto hibernate, and also
conversely, that thewake-up time increases
from sleep to hibernate.
You can see how theretention of the RAM, CPU,
and peripheral Contexts areaffected by the various power
modes and what wake-upsources can be used.
Let's go through eachcities a little more detail.
In sleep mode, theprocessor clock
is stopped, whichhalts code execution.
The peripheralconfigurations are
retained althoughtheir clocks are gated,
which results in the stoppingof any ongoing peripheral
transaction if the sleepclock is not enabled.
The contents of SRAM andthe slow clock counter
are also retainedin the sleep mode.
The wake-up time is veryshort in sleep mode,
and any interruptcan wake up the MCU.
Something to note here isthat the debugger disconnects
when the MCU enters sleep mode.
Like sleep mode, low power deepsleep mode gates the processor
clock while the slowclock counter is retained.
Unlike sleep mode,the peripheral clocks
are also gated, resultingin configuration loss.
However, the SRAM canbe retained either fully
The 256 kilobytes of SRAMis divided into four blocks
of 64 kilobytes each.
Any number of blocks can beretained in low power deep
sleep, but a partialblock cannot be retained.
This means the peripheralconfiguration can be retained
in RAM by the softwarebefore entering LPDS
and can be restoredby retrieving
from RAM after waking up.
The wake-up time isaround 3 milliseconds
executing software overhead.
In LPDS, not every interruptcan wake up the MCU.
Only a specified set ofprogrammable wake sources
are available for this mode.
The availableawake sources are--
an interrupt from the networkprocessor, LPDS wake timer--
the duration of which can bespecified in the application.
Also, one of a subsetof GPIOs can be set
as an external wake-up source.
Like sleep mode, thedebugger gets disconnected
when the MCU enters LPDS.
LPDS only affectsthe application MCU
and not the networkprocessor, which essentially
means any networkingconfiguration, including
the connection to an AP, andall internet socket connections,
will be retained acrossentry to and exit from LPDS.
With correctparking of the pins,
current consumption canbe as low as 1 milliamp
with the devicemaintaining the connections
to the AP and the internet.
This mode is ideal forscenarios where the application
remains idle for amajority of the time,
but still needs to remainconnected to the network
so that it can performsome action upon receiving
a signal from the network.
Hibernate, unlikeLPDS and sleep,
affects both the appsand NWP processors,
resulting in extremelylow current consumption.
It essentiallyshuts down the chip
with only a small numberof registers retained.
The slow clock counter iskept alive across this mode.
Network configurationsare also lost.
An interrupt from theslow clock counter
can wake the systemfrom hibernate.
Also, a specified set of GPIOscan be set as a wake-up source
Though the current consumptionis extremely low in this case,
it has a relatively largewake-up time than LPDS.
This mode is ideal forthe cases where the device
will be inactivefor most of the time
and will only have to performsome action periodically,
or based on some GPIO activity.
So far, we havediscussed the low power
modes and their features.
In the next slides, we'lldiscuss, from the software
perspective, how do youuse low power functionality
in an application.
The Power ManagementFramework, which
will be referred to as PMModule, or PM Framework
in this tutorial, is partof the TI Drivers library,
and is responsiblefor exercising
the various low power modes.
Though it can be usedalone without exercising
the peripheral driversfrom this library,
it is highly recommended to useTI Drivers for the peripherals
The reason being, that allthe drivers are power aware,
and register themselves withthe Power Management Module.
This simplifies the managementof peripheral configuration,
where the MCU iscycling through LPDS.
TI Drivers are a collection ofeasy to use interface drivers
for most of the peripherals.
The interface is similar withTI Drivers for other MCUs
from Texas Instruments.
It sits atop of driverlib,which is a low level
peripheral driver library.
Use of generic RTOS APIs makethe drivers re entrant, which
means they can work with anyRTOS or even without an RTOS,
provided a portinglayer is provided.
The CC3220 SDK providesthe porting layer
for TI RTOS, Free RTOS,and non-OS environments.
These drivers arepower aware and are
supported for the followingtool chains in the SDK--
Code Composer Studio,which is a free IDE
from Texas Instruments, IAREmbedded Workbench, and GCC.
Like previouslymentioned, PM Framework
is integrated with TI Drivers.
Each device driver registersthemselves with the PM Module
when opening the interface.
The application needs toinitialize the PM Module
at the start, thoughit can be enabled
or disabled in the run time.
Typically, upon entering LPDS,the peripheral clocks are gated
and the peripheralconfigurations will be lost.
The PM Module takes careof enabling the clock
after coming out of LPDS.
It also restores the peripheralconfiguration to the state
that it was beforeentering LPDS.
If the pins are not parkedproperly before entering LPDS
it can lead to current leakage.
Therefore, it is necessaryto park the pins.
PM Module takescare of pin parking
as per the parkingstructure, which
is specified wheninitializing the PM Module.
Although the PMModule takes care
of managing the peripheralconfigurations and pin parking,
it still allows forregistration of hook functions
for various power events likeentering LPDS, exiting LPDS,
and entering Hibernate.
If working in an RTOSenvironment, and PM Framework
is enabled, PowerManagement checks
with all the registereddrivers to check if the MCU can
be put into LPDS.
Only after confirming thatnone of the peripherals
is currently activedoes it allow
the apps MCU to enter LPDS.
Also, it makes sure that ithas sufficient time to cycle
through an LPDS cycle.
So if a task is about to beactive again very shortly,
Sleep load is exercisedinstead of LPDS.
If working in anon-OS environment,
the Power Management Functionmust be called explicitly
by the application,after which, it
makes similar checks todecide if the app's MCU can
Unlike LPDS, afunction call needs
to be made by the applicationto put the SOC into Hibernate.
Regardless of whetheror not the PM Framework
is enabled, onceits API is invoked,
the system will enter Hibernate.
The duration of time thedevice will remain in Hibernate
is passed as anargument to a function.
The device will enterHibernate if the duration is
above a minimumamount, and will remain
so until either thetimer has elapsed
or there is anexternal trigger event.
The GPIO wake-up sourcecan be specified in the PM
I/Os can be retainedduring Hibernate,
which are also specified inthe PM Configuration Structure.
The developer needs to makesure of the following things
when using Hibernate mode--
stop the network processorbefore entering Hibernate,
disable the retention afterwaking from Hibernate,
the retention for SFlash pins,which are specified as group 1,
is already disabledby the boot loader.
For other groups,the retention must
be disabled by theapplication, but only
after reconfiguring the pins.
A sample PowerManagement Structure
and a brief explanationfor each of these fields
is provided below.
The pin parkingstructure for LPDS
can be specified in PMConfiguration Structure.
It is extremely importantto park the pins
appropriately to getlower current consumption.
Following are the possibleparking states for any pin.
I sample parkingstructure is as follows--
I/Os can be retained inhibernate mode as groups,
individual retention forthe I/Os is not supported.
Shown here are the four groupswhich consume most of the I/Os.
Again, make sure todisable retention
after waking up from Hibernate.
The debugger willdisconnect no matter which
low power the device enters.
It is possible toreconnect the debugger
once the device comes out ofLPDS and stays in active mode.
Using settings which keep thedebug interface alive in LPDS
and do not park JTag pinsare necessary if it is wished
to reconnect to the debugger.
To reconnect the debuggerafter waking up from LPDS,
the application needs to makesure the app's MCU does not
enter LPDS again immediately.
The following canbe used to do so--
disable the power policyand LPDS exit hook function,
or put a usercontrolled while loop
which can be brokenafter reconnecting back
from the debugger.
Most of the settingsshown thus far
are used in thefollowing SDK examples.
Idle Profile--this exercises LPDS
and is an RTOS-based examplewith different RTOSs being
used per CCS and IAR.
Idle Profile Nonos exercisesLPDS and is a nonon example.
Sensor Profile is an applicationthat exercises Hibernate mode.
All of these examples