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

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 are gated-- 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 processors. 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 or partially. 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 simultaneously. 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 as well. 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 enter LPDS. 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 Configuration Structure. 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