SimpleLink™Wi-Fi^®CC32XX电源管理框架

Welcome to the Power Management Framework tutorial

for the CC3220 wireless MCU.

The objective of this tutorial is

to understand various low power modes for the CC3220 device,

and to familiarize the user with the Power Management Framework.

After this tutorial, you will be able to understand

the various low power modes supported by the CC3220 MCU,

work with the Power Management Framework within TI Drivers,

configure the peripherals using TI Drivers,

initialize and enable the Power Management Structure,

specify I/O parking for low power modes, and finally,

debug the Power Aware application.

The CC3220 device supports the following power modes--

sleep mode-- which is a standard low power mode for the ARM

Cortex-M4 processor, low power deep sleep mode--

which I'll be referring to you as LPDS for this or tutorial.

In this mode, the functional clock and peripheral clocks

are gated--

to slow clock continues running in the background.

Lastly we have hibernate, which is an extremely low power

mode that shuts down both the application and network

processors.

The slow clock continues to run in this mode as well.

This diagram showcases the features

of each of these power modes, along with the relative current

consumption and wake-up time.

The arrows is on the right depict two things.

One, that the current consumption

decreases from sleep to hibernate, and also

conversely, that the wake-up time increases

from sleep to hibernate.

You can see how the retention of the RAM, CPU,

and peripheral Contexts are affected by the various power

modes and what wake-up sources can be used.

Let's go through each cities a little more detail.

In sleep mode, the processor clock

is stopped, which halts code execution.

The peripheral configurations are

retained although their clocks are gated,

which results in the stopping of any ongoing peripheral

transaction if the sleep clock is not enabled.

The contents of SRAM and the slow clock counter

are also retained in the sleep mode.

The wake-up time is very short in sleep mode,

and any interrupt can wake up the MCU.

Something to note here is that the debugger disconnects

when the MCU enters sleep mode.

Like sleep mode, low power deep sleep mode gates the processor

clock while the slow clock counter is retained.

Unlike sleep mode, the peripheral clocks

are also gated, resulting in configuration loss.

However, the SRAM can be retained either fully

or partially.

The 256 kilobytes of SRAM is divided into four blocks

of 64 kilobytes each.

Any number of blocks can be retained in low power deep

sleep, but a partial block cannot be retained.

This means the peripheral configuration can be retained

in RAM by the software before entering LPDS

and can be restored by retrieving

from RAM after waking up.

The wake-up time is around 3 milliseconds

executing software overhead.

In LPDS, not every interrupt can wake up the MCU.

Only a specified set of programmable wake sources

are available for this mode.

The available awake sources are--

an interrupt from the network processor, LPDS wake timer--

the duration of which can be specified in the application.

Also, one of a subset of GPIOs can be set

as an external wake-up source.

Like sleep mode, the debugger gets disconnected

when the MCU enters LPDS.

LPDS only affects the application MCU

and not the network processor, which essentially

means any networking configuration, including

the connection to an AP, and all internet socket connections,

will be retained across entry to and exit from LPDS.

With correct parking of the pins,

current consumption can be as low as 1 milliamp

with the device maintaining the connections

to the AP and the internet.

This mode is ideal for scenarios where the application

remains idle for a majority of the time,

but still needs to remain connected to the network

so that it can perform some action upon receiving

a signal from the network.

Hibernate, unlike LPDS and sleep,

affects both the apps and NWP processors,

resulting in extremely low current consumption.

It essentially shuts down the chip

with only a small number of registers retained.

The slow clock counter is kept alive across this mode.

Network configurations are also lost.

An interrupt from the slow clock counter

can wake the system from hibernate.

Also, a specified set of GPIOs can be set as a wake-up source

simultaneously.

Though the current consumption is extremely low in this case,

it has a relatively large wake-up time than LPDS.

This mode is ideal for the cases where the device

will be inactive for most of the time

and will only have to perform some action periodically,

or based on some GPIO activity.

So far, we have discussed the low power

modes and their features.

In the next slides, we'll discuss, from the software

perspective, how do you use low power functionality

in an application.

The Power Management Framework, which

will be referred to as PM Module, or PM Framework

in this tutorial, is part of the TI Drivers library,

and is responsible for exercising

the various low power modes.

Though it can be used alone without exercising

the peripheral drivers from this library,

it is highly recommended to use TI Drivers for the peripherals

as well.

The reason being, that all the drivers are power aware,

and register themselves with the Power Management Module.

This simplifies the management of peripheral configuration,

where the MCU is cycling through LPDS.

TI Drivers are a collection of easy to use interface drivers

for most of the peripherals.

The interface is similar with TI 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 make the drivers re entrant, which

means they can work with any RTOS or even without an RTOS,

provided a porting layer is provided.

The CC3220 SDK provides the porting layer

for TI RTOS, Free RTOS, and non-OS environments.

These drivers are power aware and are

supported for the following tool chains in the SDK--

Code Composer Studio, which is a free IDE

from Texas Instruments, IAR Embedded Workbench, and GCC.

Like previously mentioned, PM Framework

is integrated with TI Drivers.

Each device driver registers themselves with the PM Module

when opening the interface.

The application needs to initialize the PM Module

at the start, though it can be enabled

or disabled in the run time.

Typically, upon entering LPDS, the peripheral clocks are gated

and the peripheral configurations will be lost.

The PM Module takes care of enabling the clock

after coming out of LPDS.

It also restores the peripheral configuration to the state

that it was before entering LPDS.

If the pins are not parked properly before entering LPDS

it can lead to current leakage.

Therefore, it is necessary to park the pins.

PM Module takes care of pin parking

as per the parking structure, which

is specified when initializing the PM Module.

Although the PM Module takes care

of managing the peripheral configurations and pin parking,

it still allows for registration of hook functions

for various power events like entering LPDS, exiting LPDS,

and entering Hibernate.

If working in an RTOS environment, and PM Framework

is enabled, Power Management checks

with all the registered drivers to check if the MCU can

be put into LPDS.

Only after confirming that none of the peripherals

is currently active does it allow

the apps MCU to enter LPDS.

Also, it makes sure that it has sufficient time to cycle

through an LPDS cycle.

So if a task is about to be active again very shortly,

Sleep load is exercised instead of LPDS.

If working in a non-OS environment,

the Power Management Function must be called explicitly

by the application, after which, it

makes similar checks to decide if the app's MCU can

enter LPDS.

Unlike LPDS, a function call needs

to be made by the application to put the SOC into Hibernate.

Regardless of whether or not the PM Framework

is enabled, once its API is invoked,

the system will enter Hibernate.

The duration of time the device will remain in Hibernate

is passed as an argument to a function.

The device will enter Hibernate if the duration is

above a minimum amount, and will remain

so until either the timer has elapsed

or there is an external trigger event.

The GPIO wake-up source can be specified in the PM

Configuration Structure.

I/Os can be retained during Hibernate,

which are also specified in the PM Configuration Structure.

The developer needs to make sure of the following things

when using Hibernate mode--

stop the network processor before entering Hibernate,

disable the retention after waking from Hibernate,

the retention for SFlash pins, which are specified as group 1,

is already disabled by the boot loader.

For other groups, the retention must

be disabled by the application, but only

after reconfiguring the pins.

A sample Power Management Structure

and a brief explanation for each of these fields

is provided below.

The pin parking structure for LPDS

can be specified in PM Configuration Structure.

It is extremely important to park the pins

appropriately to get lower current consumption.

Following are the possible parking states for any pin.

I sample parking structure is as follows--

I/Os can be retained in hibernate mode as groups,

individual retention for the I/Os is not supported.

Shown here are the four groups which consume most of the I/Os.

Again, make sure to disable retention

after waking up from Hibernate.

The debugger will disconnect no matter which

low power the device enters.

It is possible to reconnect the debugger

once the device comes out of LPDS and stays in active mode.

Using settings which keep the debug interface alive in LPDS

and do not park JTag pins are necessary if it is wished

to reconnect to the debugger.

To reconnect the debugger after waking up from LPDS,

the application needs to make sure the app's MCU does not

enter LPDS again immediately.

The following can be used to do so--

disable the power policy and LPDS exit hook function,

or put a user controlled while loop

which can be broken after reconnecting back

from the debugger.

Most of the settings shown thus far

are used in the following SDK examples.

Idle Profile-- this exercises LPDS

and is an RTOS-based example with different RTOSs being

used per CCS and IAR.

Idle Profile Nonos exercises LPDS and is a nonon example.

Sensor Profile is an application that exercises Hibernate mode.

All of these examples are based on TI Drivers.

Welcome to the Power Management Framework tutorial

for the CC3220 wireless MCU.

The objective of this tutorial is

to understand various low power modes for the CC3220 device,

and to familiarize the user with the Power Management Framework.

After this tutorial, you will be able to understand

the various low power modes supported by the CC3220 MCU,

work with the Power Management Framework within TI Drivers,

configure the peripherals using TI Drivers,

initialize and enable the Power Management Structure,

specify I/O parking for low power modes, and finally,

debug the Power Aware application.

The CC3220 device supports the following power modes--

sleep mode-- which is a standard low power mode for the ARM

Cortex-M4 processor, low power deep sleep mode--

which I'll be referring to you as LPDS for this or tutorial.

In this mode, the functional clock and peripheral clocks

are gated--

to slow clock continues running in the background.

Lastly we have hibernate, which is an extremely low power

mode that shuts down both the application and network

processors.

The slow clock continues to run in this mode as well.

This diagram showcases the features

of each of these power modes, along with the relative current

consumption and wake-up time.

The arrows is on the right depict two things.

One, that the current consumption

decreases from sleep to hibernate, and also

conversely, that the wake-up time increases

from sleep to hibernate.

You can see how the retention of the RAM, CPU,

and peripheral Contexts are affected by the various power

modes and what wake-up sources can be used.

Let's go through each cities a little more detail.

In sleep mode, the processor clock

is stopped, which halts code execution.

The peripheral configurations are

retained although their clocks are gated,

which results in the stopping of any ongoing peripheral

transaction if the sleep clock is not enabled.

The contents of SRAM and the slow clock counter

are also retained in the sleep mode.

The wake-up time is very short in sleep mode,

and any interrupt can wake up the MCU.

Something to note here is that the debugger disconnects

when the MCU enters sleep mode.

Like sleep mode, low power deep sleep mode gates the processor

clock while the slow clock counter is retained.

Unlike sleep mode, the peripheral clocks

are also gated, resulting in configuration loss.

However, the SRAM can be retained either fully

or partially.

The 256 kilobytes of SRAM is divided into four blocks

of 64 kilobytes each.

Any number of blocks can be retained in low power deep

sleep, but a partial block cannot be retained.

This means the peripheral configuration can be retained

in RAM by the software before entering LPDS

and can be restored by retrieving

from RAM after waking up.

The wake-up time is around 3 milliseconds

executing software overhead.

In LPDS, not every interrupt can wake up the MCU.

Only a specified set of programmable wake sources

are available for this mode.

The available awake sources are--

an interrupt from the network processor, LPDS wake timer--

the duration of which can be specified in the application.

Also, one of a subset of GPIOs can be set

as an external wake-up source.

Like sleep mode, the debugger gets disconnected

when the MCU enters LPDS.

LPDS only affects the application MCU

and not the network processor, which essentially

means any networking configuration, including

the connection to an AP, and all internet socket connections,

will be retained across entry to and exit from LPDS.

With correct parking of the pins,

current consumption can be as low as 1 milliamp

with the device maintaining the connections

to the AP and the internet.

This mode is ideal for scenarios where the application

remains idle for a majority of the time,

but still needs to remain connected to the network

so that it can perform some action upon receiving

a signal from the network.

Hibernate, unlike LPDS and sleep,

affects both the apps and NWP processors,

resulting in extremely low current consumption.

It essentially shuts down the chip

with only a small number of registers retained.

The slow clock counter is kept alive across this mode.

Network configurations are also lost.

An interrupt from the slow clock counter

can wake the system from hibernate.

Also, a specified set of GPIOs can be set as a wake-up source

simultaneously.

Though the current consumption is extremely low in this case,

it has a relatively large wake-up time than LPDS.

This mode is ideal for the cases where the device

will be inactive for most of the time

and will only have to perform some action periodically,

or based on some GPIO activity.

So far, we have discussed the low power

modes and their features.

In the next slides, we'll discuss, from the software

perspective, how do you use low power functionality

in an application.

The Power Management Framework, which

will be referred to as PM Module, or PM Framework

in this tutorial, is part of the TI Drivers library,

and is responsible for exercising

the various low power modes.

Though it can be used alone without exercising

the peripheral drivers from this library,

it is highly recommended to use TI Drivers for the peripherals

as well.

The reason being, that all the drivers are power aware,

and register themselves with the Power Management Module.

This simplifies the management of peripheral configuration,

where the MCU is cycling through LPDS.

TI Drivers are a collection of easy to use interface drivers

for most of the peripherals.

The interface is similar with TI 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 make the drivers re entrant, which

means they can work with any RTOS or even without an RTOS,

provided a porting layer is provided.

The CC3220 SDK provides the porting layer

for TI RTOS, Free RTOS, and non-OS environments.

These drivers are power aware and are

supported for the following tool chains in the SDK--

Code Composer Studio, which is a free IDE

from Texas Instruments, IAR Embedded Workbench, and GCC.

Like previously mentioned, PM Framework

is integrated with TI Drivers.

Each device driver registers themselves with the PM Module

when opening the interface.

The application needs to initialize the PM Module

at the start, though it can be enabled

or disabled in the run time.

Typically, upon entering LPDS, the peripheral clocks are gated

and the peripheral configurations will be lost.

The PM Module takes care of enabling the clock

after coming out of LPDS.

It also restores the peripheral configuration to the state

that it was before entering LPDS.

If the pins are not parked properly before entering LPDS

it can lead to current leakage.

Therefore, it is necessary to park the pins.

PM Module takes care of pin parking

as per the parking structure, which

is specified when initializing the PM Module.

Although the PM Module takes care

of managing the peripheral configurations and pin parking,

it still allows for registration of hook functions

for various power events like entering LPDS, exiting LPDS,

and entering Hibernate.

If working in an RTOS environment, and PM Framework

is enabled, Power Management checks

with all the registered drivers to check if the MCU can

be put into LPDS.

Only after confirming that none of the peripherals

is currently active does it allow

the apps MCU to enter LPDS.

Also, it makes sure that it has sufficient time to cycle

through an LPDS cycle.

So if a task is about to be active again very shortly,

Sleep load is exercised instead of LPDS.

If working in a non-OS environment,

the Power Management Function must be called explicitly

by the application, after which, it

makes similar checks to decide if the app's MCU can

enter LPDS.

Unlike LPDS, a function call needs

to be made by the application to put the SOC into Hibernate.

Regardless of whether or not the PM Framework

is enabled, once its API is invoked,

the system will enter Hibernate.

The duration of time the device will remain in Hibernate

is passed as an argument to a function.

The device will enter Hibernate if the duration is

above a minimum amount, and will remain

so until either the timer has elapsed

or there is an external trigger event.

The GPIO wake-up source can be specified in the PM

Configuration Structure.

I/Os can be retained during Hibernate,

which are also specified in the PM Configuration Structure.

The developer needs to make sure of the following things

when using Hibernate mode--

stop the network processor before entering Hibernate,

disable the retention after waking from Hibernate,

the retention for SFlash pins, which are specified as group 1,

is already disabled by the boot loader.

For other groups, the retention must

be disabled by the application, but only

after reconfiguring the pins.

A sample Power Management Structure

and a brief explanation for each of these fields

is provided below.

The pin parking structure for LPDS

can be specified in PM Configuration Structure.

It is extremely important to park the pins

appropriately to get lower current consumption.

Following are the possible parking states for any pin.

I sample parking structure is as follows--

I/Os can be retained in hibernate mode as groups,

individual retention for the I/Os is not supported.

Shown here are the four groups which consume most of the I/Os.

Again, make sure to disable retention

after waking up from Hibernate.

The debugger will disconnect no matter which

low power the device enters.

It is possible to reconnect the debugger

once the device comes out of LPDS and stays in active mode.

Using settings which keep the debug interface alive in LPDS

and do not park JTag pins are necessary if it is wished

to reconnect to the debugger.

To reconnect the debugger after waking up from LPDS,

the application needs to make sure the app's MCU does not

enter LPDS again immediately.

The following can be used to do so--

disable the power policy and LPDS exit hook function,

or put a user controlled while loop

which can be broken after reconnecting back

from the debugger.

Most of the settings shown thus far

are used in the following SDK examples.

Idle Profile-- this exercises LPDS

and is an RTOS-based example with different RTOSs being

used per CCS and IAR.

Idle Profile Nonos exercises LPDS and is a nonon example.

Sensor Profile is an application that exercises Hibernate mode.

All of these examples are based on TI Drivers.