|
|
|
SimpleLink MCU SDK Driver APIs
tidrivers_msp43x_3_01_01_03
|
Power global configuration (MSP432-specific) More...
#include <PowerMSP432.h>
Data Fields | |
| Power_PolicyInitFxn | policyInitFxn |
| The Power Policy's initialization function. More... | |
| Power_PolicyFxn | policyFxn |
| The Power Policy function. More... | |
| unsigned int | initialPerfLevel |
| The initial performance level to be established during Power Manager initialization. More... | |
| bool | enablePolicy |
| Boolean specifying if the Power Policy function is enabled. More... | |
| bool | enablePerf |
| Boolean specifying if performance scaling is enabled. More... | |
| bool | enableParking |
| Boolean specifying if pull resistors should be automatically applied to input pins during PowerMSP432_DEEPSLEEP_0 and PowerMSP432_DEEPSLEEP_1. More... | |
Power global configuration (MSP432-specific)
| Power_PolicyInitFxn PowerMSP432_ConfigV1::policyInitFxn |
The Power Policy's initialization function.
If the policy does not have an initialization function, 'NULL' should be specified.
| Power_PolicyFxn PowerMSP432_ConfigV1::policyFxn |
The Power Policy function.
When enabled, this function is invoked in the idle loop, to opportunistically select and activate sleep states.
Two reference policies are provided:
PowerMSP432_sleepPolicy() - a simple policy that will put the device in either the PowerMSP432_SLEEP state (unless there is a constraint prohibiting this), or CPU wait for interrupt (WFI)
PowerMSP432_deepSleepPolicy() - a more agressive policy that checks constraints and optionally chooses PowerMSP432_DEEPSLEEP_1, PowerMSP432_DEEPSLEEP_0, PowerMSP432_SLEEP, or WFI, in that order of preference.
Custom policies can be written, and specified via this function pointer.
In addition to this static selection, the Power Policy can be dynamically changed at runtime, via the Power_setPolicy() API.
| unsigned int PowerMSP432_ConfigV1::initialPerfLevel |
The initial performance level to be established during Power Manager initialization.
The performance level is identified by a numeric index into the table of available performance levels.
This performance level will be activated during initialization only when performance scaling is enabled (below, via specification of enablePerf).
| bool PowerMSP432_ConfigV1::enablePolicy |
Boolean specifying if the Power Policy function is enabled.
If 'true', the policy function will be invoked once for each pass of the idle loop.
If 'false', the policy will not be invoked.
In addition to this static setting, the Power Policy can be dynamically enabled and disabled at runtime, via the Power_enablePolicy() and Power_disablePolicy() functions, respectively.
| bool PowerMSP432_ConfigV1::enablePerf |
Boolean specifying if performance scaling is enabled.
If 'true', the performance scaling feature will be enabled for the application. And, the initial performance level (specified above, via initialPerfLevel) will be established during Power Manager initialization.
If 'false', performance scaling is disabled for the application.
| bool PowerMSP432_ConfigV1::enableParking |
Boolean specifying if pull resistors should be automatically applied to input pins during PowerMSP432_DEEPSLEEP_0 and PowerMSP432_DEEPSLEEP_1.
Leaving an input pin floating during a device deepsleep state will result in an increase in power consumption. The Power Manager provides an option to automatically apply pull resistors to input pins during deepsleep, so that none are left floating. The type of pull (pull-up or pull-down) is determined by the current state sensed for each input pin, as the device is transitioning into deepsleep. This feature is referred to as 'automatic pin parking', and is enabled with this enableParking configuration parameter.
If 'true', before completing a transition into deepsleep, pull resistors will be applied to all pins configured as input, with General Purpose I/O (GPIO) function (as configured in the PxSEL1 and PxSEL0 registers). On wake from deepsleep, the pull resistor settings will be restored to those in effect prior to deepsleep.
If 'false', pull resistors will not be automatically applied during deepsleep states.
SPECIAL NOTE: When auto pin parking is enabled special attention must be paid to the interrupt trigger selection for GPIO pins that are expected to wake the device from deepsleep. Specifically, the interrupt should be triggered on the leading edge of the signal transition.
As an example, consider a pin that is connected via a debounced button switch to ground. An internal pull-up resistor is used versus an external pull-up resistor. The GPIO driver is used to manage this pin, with the following entry in the pin configuration array:
..., GPIOMSP432_P1_1 | GPIO_CFG_IN_PU | GPIO_CFG_IN_INT_FALLING, ...,
Note that the "FALLING" edge is specifically selected so that the interrupt triggers immediately upon a button press.
If instead the "RISING" edge were selected, in certain situations there may be a problem with this pin being able to trigger a wakeup from deepsleep. For example, consider the case where there is an additional mechanism to wake the device from deepsleep, for example, the watchdog timer is programmed in interval timer mode, to periodically wake the device every 250ms. If the button is not pressed, when the device goes to deepsleep the pin state is sensed as high, and a pull-up resistor is automatically applied by the Power driver. At some point the button is pressed, and the pin is pulled to ground. But since "RISING" edge was configured for the interrupt, the interrupt request has not yet been sent to the CPU. Now, while the button is still low, the interval timer wakes the device, the necessary work is done, the power policy runs in the idle loop again, and puts the device back to deepsleep. On this transition to deepsleep, the auto pin parking code runs again, but this time the button pin level is sensed as low (since the button is depressed); so this time, a pull-down resistor is applied to the pin. The device goes to deepsleep, and then eventually the button is released... but the pin is still held low by the internal pull-down resistor, so no rising edge occurs, no interrupt is signalled to the CPU, and the device stays in deesleep.
The above is a hypothetical example, but illustrates the importance of selecting the appropriate interrupt trigger configuration for GPIO pins when auto pin parking is enabled. If a pin is being driven by an external circuit (versus floating with weak pull resistors as in the above example), as long as the external circuit can sufficiently drive the pin to counteract the weak pull resistor, there won't be a similar issue.
