Power Module for C6748 and OMAP-L138

Overview

Power is a SYS/BIOS module that enables you to reduce the power consumption of your C6748 or OMAP-L138 application. Power provides the following functionality:

CPU Idling – You can configure Power to automatically idle the CPU in the Idle loop while waiting for an interrupt to trigger new processing. This is a “static” application configuration step, versus runtime API calls to Power.

Resource Tracking – You can make runtime calls to Power to dynamically specify the power-manageable resources (for example, the functional clock for a UART) that your application is dependent upon. With this knowledge of required resources, Power can aggressively idle resources that have no active dependencies.

Scaling Voltage and Frequency - You can dynamically change the operating voltage and frequency of the CPU domain and the peripheral domain. This is called V/F scaling, and can result in significant power savings.

Sleep Modes - You can dynamically activate CPU and device sleep modes to save power during inactivity.

Coordinating Sleep and Scaling - You can coordinate sleep modes and V/F scaling with other software components (e.g., drivers, componentized software ‘stacks’, etc.) using registration and notification mechanisms provided by the Power module.

Power is a Derivative of PWRM

The Power module is a “port” of the DSP/BIOS Power Manager (PWRM module) to SYS/BIOS. [PWRM is described in the DSP/BIOS User’s Guide (http://www.ti.com/lit/ug/spru423h/spru423h.pdf).] Power provides the same basic functionality that PWRM did for the C6748 and OMAP-L138, but follows SYS/BIOS naming and configuration conventions. The one exception to the feature set is the load monitoring feature of PWRM – it was not ported forward to Power. SYS/BIOS provides a Load module (in the package ti.sysbios.utils) that can be used as an alternative, to collect basic CPU load information.

Module Layering

As with PWRM, Power sits on top of two interface layers: the Power Scaling Library (PSCL) for voltage/frequency scaling logic and configuration, and the Power Management Interface (PMI) hardware control layer.

Both PSCL and PMI are “straight C” code, provided in source form, in the ti.sysbios.family.c674.pscl and ti.sysbios.family.c674.pmi packages.

With DSP/BIOS, the PSCL and PMI libraries were each broken into a common library, and a set of board-specific companion libraries. With SYS/BIOS, this is done differently – each PSCL library, and each PMI library now contains all the code and data necessary for a particular board configuration. In other words, the shared, common libraries have been eliminated. This was done to simplify the build process for users creating custom PSCL or PMI libraries.

Theory of Operation

CPU Idling

In many applications, while the CPU is waiting for an interrupt (signaling new work is to be done, e.g., when an I/O operation is complete), the CPU simply spins continuously in an idle loop. Rather than spinning continuously, the CPU’s “idle” instruction can be invoked to reduce power consumption during the wait interval. Depending upon how much time is spent in this idle loop, the savings from idling might be significant.

The Power module provides a configuration parameter, “idleCpu” , that can be set to tell Power to automatically insert a function into the SYS/BIOS Idle loop, to idle the CPU while waiting for the next interrupt. When the “idle” instruction is invoked, the CPU will stop execution of new instructions, and will resume execution when the next enabled interrupt occurs. After the interrupt has been serviced, and any threads that have been readied have run, the CPU will return to the Idle loop, at the instruction after “idle”. The loop will then continue, making one pass through any other configured Idle functions, and then returning to “idle”, where the CPU will wait until the next interrupt occurs.

Resource Tracking

A typical SYS/BIOS application uses a set of peripherals—timers, serial ports, etc.—to accomplish its purpose. Typically device drivers manage low-level peripheral accesses, but sometimes applications access peripherals directly. In both these scenarios, the SYS/BIOS kernel itself does not "know" which peripherals are being used. This information is distributed across the application code and drivers, and is not stored within the kernel. As a consequence, SYS/BIOS does not know what resources are actually required by an application at any given instant, so it cannot aggressively idle resources without possibly "breaking" the application.

The Power module provides a "resource tracking" feature to allow more aggressive power management. Applications, drivers, and other SYS/BIOS modules can call a Power API to declare dependencies upon specific resources, when those resources are actually needed. When resources are no longer needed—for example, when a serial port is closed, or when there is no work for an audio driver to do—a companion Power API call can be made to release the resource dependency. Power counts the "set" and "release" dependency calls, and automatically enables a resource when the first "set" operation occurs, and automatically disables that resource when the last "release" call occurs.

For the C6748 and OMAP-L138, Power supports the following enumerated resources:

   enum Resource {
      RSRC_EDMA3_CC_0   = 0, /*! EDMA3_0 Channel Controller 0 */
      RSRC_EDMA3_TC_0   = 1, /*! EDMA3_0 Transfer Controller 0 */
      RSRC_EDMA3_TC_1   = 2, /*! EDMA3_0 Transfer Controller 1 */
      RSRC_EMIFA        = 3, /*! EMIFA */
      RSRC_SPI_0        = 4, /*! SPI0 */
      RSRC_MMCSD_0      = 5, /*! MMC/SD0 */
      RSRC_AINTC        = 6, /*! ARM Interrupt Controller */
      RSRC_RSVD1        = 7, /*! RESERVED */
      RSRC_UART_0       = 8, /*! UART0 */
      RSRC_RSVD2        = 9, /*! RESERVED */
      RSRC_EDMA3_CC_1   = 10, /*! EDMA3_1 Channel Controller 0 */
      RSRC_USB0         = 11, /*! USB0 */
      RSRC_USB1         = 12, /*! USB1 */
      RSRC_GPIO         = 13, /*! GPIO */
      RSRC_UHPI         = 14, /*! HPI */
      RSRC_EMAC         = 15, /*! EMAC */
      RSRC_DDR2         = 16, /*! DDR2/mDDR */
      RSRC_MCASP_0      = 17, /*! McASP0 */
      RSRC_SATA         = 18, /*! SATA */
      RSRC_VPIF         = 19, /*! VPIF */
      RSRC_SPI_1        = 20, /*! SPI1 */
      RSRC_I2C_1        = 21, /*! I2C1 */
      RSRC_UART_1       = 22, /*! UART1 */
      RSRC_UART_2       = 23, /*! UART2 */
      RSRC_MCBSP_0      = 24, /*! McBSP0 */
      RSRC_MCBSP_1      = 25, /*! McBSP1 */
      RSRC_LCDC         = 26, /*! LCDC */
      RSRC_EHRPWM       = 27, /*! eHRPWM0/1 */
      RSRC_MMCSD_1      = 28, /*! MMC/SD1 */
      RSRC_UPP          = 29, /*! uPP */
      RSRC_ECAP         = 30, /*! eCAP0/1/2 */
      RSRC_EDMA3_TC_2   = 31, /*! EDMA3_1 Transfer Controller 0 */
      RSRC_END          = 32
  };

These resources correspond to the Local Power Sleep Controllers (LPSC) for individual circuit modules. When a resource dependency is initially set, the module will be put into the ENABLE state (if it wasn’t already). When the last dependency for a module is released, the LPSC module will be put into the DISABLE state.

Note that the resources listed above are applicable for the C6748 or OMAP-L138. If Power is used on a C6746 or C6742 device, only the appropriate subset of the resources is applicable.

Scaling Voltage and Frequency

Active power dissipation of a CMOS-based DSP is linearly proportional to the clock rate (frequency), and quadratically proportional to the operating voltage. Additionally, the operating voltage determines the maximum clock rate available.

If an application can reduce the CPU clock rate and still meet its processing deadlines, it can produce a linearly proportional savings in power dissipation. [However, reducing the CPU clock rate also proportionally extends the execution time, so the application must be carefully analyzed to make sure it can still meets its real-time requirements.] If the clock frequency can be reduced and the new frequency is compatible with a lower operating voltage supported by the DSP, then potentially significant additional savings can be also be made by reducing the voltage, due to the quadratic relationship.

Power provides the Power_changeSetpoint() API, which can be called by an application to change the operating voltage and frequency (V/F). [The combination of an operating voltage and an operating frequency is referred to as a “setpoint”.] So, for example, when an application switches to a mode with reduced processing requirements, it can step down the voltage and frequency (i.e., move to a lower setpoint) to reduce power consumption. Or, an application might accumulate "slack" time in its data-dependent processing, and then reduce V/F to absorb the slack time while running at lower power.

Portable applications can learn about the V/F scaling features supported on a platform via runtime queries, with the Power_getCurrentSetpoint(), Power_getNumSetpoints(), Power_getSetpointInfo(), and Power_getTransitionLatency() APIs.

The Power module also supports coordination of V/F changes across the application, through a registration and notification mechanism. Additionally, clients can indicate to Power the V/F setpoints they support. Power will check any client-registered constraints before attempting to transition to the requested setpoint.

The Power module calls to a platform-specific Power Scaling Library (PSCL) (an underlying abstraction layer) to make the actual changes to voltage and frequency.

Using Sleep Modes

Power allows applications to activate sleep modes, which place the CPU and related device modules into low-power states. Sleep modes may include idling module clocks, reducing clock frequencies, reducing operating voltages (e.g., to retention levels), and powering off subsystems. For the C6748 and OMAP-L138 the following sleep modes are supported:

Power_STANDBY – The CPU and other modules within the C674x megamodule  are clock gated at the megamodule  boundary.

Power_SLEEP – In addition to clock-gating of C674x DSP megamodule (as in Power_STANDBY), the core voltage is reduced, and device PLLs are bypassed.

Power_DEEPSLEEP – In addition to the actions for Power_SLEEP, the C674x megamodule clock is gated further up-stream (at its Power Sleep Controller (PSC)), memories are put into retention, and PLLs are powered down.

Coordinating Sleep and Scaling

Power provides a synchronization framework for notifying application components (i.e., “clients”), that have registered to be notified, when specific power events occur.

Clients actively register for the specific power events that they care about, by calling Power_registerNotify(). Any type of code can register, e.g., drivers, straight-application code, and SYS/BIOS itself. When notifications are no longer needed (e.g., when a device driver is shutting down), the companion Power_unregisterNotify() API should be called to remove the client for the event notification list.

When registering, clients specify a callback function that Power should call when a specific event occurs. Clients can also specify a specific argument that gets passed back at notification time; this allows a common notification function to be used for multiple instances of a client.

At notification time, clients can indicate to Power that they are done (by returning Power_ NOTIFYDONE from the callback function), or that they need a “delayed completion” (by returning Power_ NOTIFYNOTDONE), meaning that they have received the notification, but must finish some processing before being ready for the power event transition.

In the case where a client has signaled it needs a delayed completion, when the client has completed its required action (for example, on the next interrupt from a peripheral), it should call the delayedCompletionFunction() returned to it from the Power_registerNotify() call for the event type. The Power module waits until all clients have signaled to Power that they are ready for the transition before performing the transition. If a client does not signal to Power that it is done within the specified timeout, the relevant Power API returns Power_ETIMEOUT, which is typically an indicator of a system failure.

Before notifying clients of a power event, Power first disables Task and Swi scheduling, to protect against preemption while the power event is being processed. Since Task and Swi scheduling are disabled during Power notifications, clients cannot rely on Task or Swi scheduling to finish Power event processing. Hardware interrupts are still enabled, and can be used to determine and signal completion of processing of the notification. For example, to allow an in-process DMA operation to complete, the DMA ISR can still run, and then call the delayedCompletionFunction() to signal to Power that the client has finished processing the event.

Finally, it is important to note that when notified of an event, it is truly a “notification”. Clients cannot “vote” on a power event or transition when they get the notification from Power. The application must determine if the transition should occur before calling Power (e.g., to change the setpoint); once the transition is started and notifications begin, clients must act upon the notifications appropriately.

The following figure illustrates the registration/notification concept:

In this example, the numbered steps are as follows:

1. Application code registers to be notified of V/F setpoint changes. For example, different EMIF settings may be needed for different setpoints, so the application registers control code with Power so that it can change EMIF settings when there is a change to the setpoint.

2. A peripheral driver using DMA for transfers to/from external memory registers to be notified of V/F setpoint changes. For example, prior to a setpoint change, the driver may need to temporarily stop DMA operations to external memory.

3. Packaged target content (e.g., a protocol stack) similarly registers for notification on setpoint changes.

4. The application decides to change the V/F setpoint, and calls Power_changeSetpoint() to initiate the setpoint change. It may do this, for example, because of a change in the application's operation mode (for example, a switch between data collection mode and data processing mode).

5. Before the setpoint change, Power validates the change request versus any registered constraints, and then notifies all registered clients of the impending setpoint change. Clients are notified in the same order they registered for notification (i.e., FIFO order).

6. Power calls down to the Power Scaling Library (PSCL) to change the V/F setpoint.

7. After the setpoint change, Power notifies the registered clients that the setpoint has been changed.

On the C6748 and OMAP-L138, clients can use Power_registerNotify() to register to be notified about the following types of events:

   enum Event {
      GOINGTOSTANDBY = 0, /*! Going to Power_STANDBY */
      AWAKEFROMSTANDBY,   /*! Awake from Power_STANDBY */
      GOINGTOSLEEP,       /*! Going to Power_SLEEP */
      AWAKEFROMSLEEP,     /*! Awake from Power_SLEEP */
      GOINGTODEEPSLEEP,   /*! Going to Power_DEEPSLEEP */
      AWAKEFROMDEEPSLEEP, /*! Awake from Power_DEEPSLEEP */
      PENDING_CPU_SETPOINTCHANGE, /*! A CPU setpoint change is about to occur */
      PENDING_PER_SETPOINTCHANGE, /*! A peripheral setpoint change is about to occur */
      DONE_CPU_SETPOINTCHANGE, /*! A CPU setpoint change has just completed */
      DONE_PER_SETPOINTCHANGE, /*! A peripheral setpoint change has just completed */
      INVALIDEVENT
  };

Configuring Power

“Using” Power in Your Application

The Power module resides in the package ti.sysbios.family.c674, and is only applicable for C6748 and OMAP-L138 devices. And for the OMAP-L138, it applies for the DSP-side only. Separate Linux power management support is available for the ARM-side.

Note that there are other Power modules in other ‘family’ packages that ship with SYS/BIOS. With SYS/BIOS, the functionality and implementation of the Power module is “family-specific”, and you need to “use” the appropriate Power module for the device that you are building your application for. For example, for C6748 or OMAP-L138, in XGCONF you should select the Power module in the ti.sysbios.family.c674 package, or if writing the configuration script directly, add the following to your .cfg file:

   var Power = xdc.useModule('ti.sysbios.family.c674.Power');

Configuration Parameters

The configuration parameters for Power are described in the ‘cdoc’ in the SYS/BIOS release (in the “docs\cdoc” subdirectory), and summarized below:

Configuration Parameter	Usage	Default
enableScaling	Boolean: Enable voltage and frequency (V/F) scaling for the application?	false
scaleVoltage	Boolean: Scale voltage along with frequency?	true
waitVoltage	Boolean: Power should wait during downward voltage ramping?	true
initialSetpointCPU	UInt: The initial CPU domain setpoint at boot time	2
initialSetpointPER	UInt: The initial peripheral (PER) domain setpoint at boot time	0
moveToSetpoints	Boolean: Should Power transition to the initial setpoints during program initialization?	false
trackResources	Boolean: Enable resource tracking for the application?	false
idleCpu	Boolean: Idle the CPU automatically during idle time (in the Idle loop)?	false
idleFunc	FuncPtr: The idling function to be used by Power when “idleCpu” is true	Power.idleStopClock
onChipRegion	String: The on-chip memory region to place Power's code and data that must reside on-chip	IRAM
pmiControlLib	pmiLib: The PMI library to be used (linked)	Power.pmiLib_evm6748
psclConfigLib	psclLib: The PSCL library to be used (linked)	Power.psclLib_evm6748

An example snippet from an application configuration script:

   var Power = xdc.useModule('ti.sysbios.family.c674.Power');  /* ‘use’ Power in the app*/
  Power.enableScaling = true;                                 /* enable V/F scaling */
  Power.initialSetpointCPU = 2;                               /* initial CPU domain setpoint = 2 */
  Power.initialSetpointPER= 0;                                /* initial PER domain setpoint = 0 */
  Power.moveToSetpoints = true;                               /* move to initial setpoints at boot */
  Power.scaleVoltage = true;                                  /* scale voltage along with frequency */
  Power.waitVoltage = true;                                   /* wait during downward voltage ramps */
  Power.psclConfigLib = Power.psclLib_lcdk;                   /* select the pre-built PSCL library for LCDK */ 
  Power.pmiControlLib = Power.pmiLib_lcdk;                    /* select the pre-built PMI library for LCDK */
  Power.onChipRegion = "L3_CBA_RAM";                          /* place Power’s on-chip code/data in L3_CBA_RAM */

Miscellaneous

Available Setpoints

The following tables indicate the default V/F setpoints provided with the different pre-built PSCL configuration libraries:

psclLib_evm6748.a674 and psclLib_evm6748.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.0V
1	200MHz	1.1V
2	300MHz	1.2V

PER Setpoint	Frequency	Voltage
0	264MHz	1.0V
1	300MHz	1.2V

psclLib_evm6748_372.a674 and psclLib_evm6748_372.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.0V
1	200MHz	1.1V
2	372MHz	1.2V

PER Setpoint	Frequency	Voltage
0	264MHz	1.0V
1	300MHz	1.2V

psclLib_evm6748_408.a674 and psclLib_evm6748_408.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.0V
1	200MHz	1.1V
2	372MHz	1.2V
3	408MHz	1.3V

PER Setpoint	Frequency	Voltage
0	264MHz	1.0V
1	300MHz	1.2V

psclLib_evm6748_456.a674 and psclLib_evm6748_456.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.0V
1	200MHz	1.1V
2	372MHz	1.2V
3	456MHz	1.3V

PER Setpoint	Frequency	Voltage
0	264MHz	1.0V
1	300MHz	1.2V

psclLib_lcdk.a674 and psclLib_lcdk.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.3V
1	200MHz	1.3V
2	300MHz	1.3V
3	456MHz	1.3V

PER Setpoint	Frequency	Voltage
0	264MHz	1.3V
1	300MHz	1.3V

psclLib_C6742.a674 and psclLib_C6742.ae674:

CPU Setpoint	Frequency	Voltage
0	100MHz	1.0V
1	150MHz	1.1V
2	200MHz	1.2V

PER Setpoint	Frequency	Voltage
0	264MHz	1.0V
1	300MHz	1.2V

Constraints for Power_SLEEP and Power_DEEPSLEEP

To operate within TMS320C6748 and OMAPL138 device constraints, it must be ensured that no off-chip accesses to DDR memories occur while PLL1 is bypassed. The Power Manager (Power) provides two sleep modes where this constraint is a concern: Power_SLEEP, when PLL1 is allowed to be bypassed, and Power_DEEPSLEEP.

Power, and the underlying PSCL and PMI layers have been implemented with the goal of minimizing the impact of this constraint upon the user. However, there remain some user-domain memory placement requirements, for invoking these two sleep modes.

When PLL1 is being bypassed the following sections must be explicitly placed in on-chip memory:

   .text
  .bss
  .vecs
  .far

Either L2 or L3 memory (referred to as IRAM or L3_CBA_RAM in the SYS/BIOS configuration) can be used. Note that L2 memory will provide faster performance compared to L3. The following snippet from an application .cfg file shows how these sections can be placed into L3_CBA_RAM:

   Program.sectMap[".text"] = "L3_CBA_RAM";
  Program.sectMap[".bss"] = "L3_CBA_RAM";
  Program.sectMap[".vecs"] = "L3_CBA_RAM";
  Program.sectMap[".far"] = "L3_CBA_RAM";

Power's own on-chip section (.ti_sysbios_family_c674_pmi_onchip) will be automatically placed in the on-chip section specified in Power's configuration (i.e., Power.onChipRegion).

Examples

V/F Scaling

This example queries the Power module for the available V/F setpoints for the CPU, prints out the values, and then steps the processor thru these setpoints. The application first registers for notification of CPU setpoint changes, and when the notifications occur, prints out the notification parameters. Note that in this test only frequency is actually scaled; voltage scaling is disabled, to allow the test to run on a wider-selection of hardware.

To build this example you can create a CCS project using the two files: vfscale6x.c and vfscale6x.cfg. For example… Start the new project wizard to create a project. Select device Family of “C6000”, device variant of “Generic C674x Device”. Select the “Empty RTSC project” template and then click Next. Select the platform “ti.platforms.evm6748” from the drop list of available platforms. In the list of Product and Repositories, uncheck all the boxes except those for SYS/BIOS. Then click Finish. Unzip this file [vfscale6x.zip], copy and paste the vfscale6x.c and vfscale6x.cfg files into the project, and then build the project.

Load and run the example, and the CCS console output should look similar to the following:

registered for PENDING_CPU_SETPOINTCHANGE event
registered for DONE_CPU_SETPOINTCHANGE event
number CPU setpoints = 3
CPU setpoint info:
 setpoint 0:
    freq = 100MHz, voltage = 1000mV
 setpoint 1:
    freq = 200MHz, voltage = 1100mV
 setpoint 2:
    freq = 300MHz, voltage = 1200mV
current CPU setpoint = 2
changing to CPU setpoint 0 ...
   myNotifyFxn - PENDING_CPU_SETPOINTCHANGE
     current = 2, next = 0
   myNotifyFxn - DONE_CPU_SETPOINTCHANGE
     previous = 2, current = 0
new setpoint = 0, measured CPU speed = 100MHz
BIOS.cpuFreq.lo = 100000000 Hz
changing to CPU setpoint 1 ...
   myNotifyFxn - PENDING_CPU_SETPOINTCHANGE
     current = 0, next = 1
   myNotifyFxn - DONE_CPU_SETPOINTCHANGE
     previous = 0, current = 1
new setpoint = 1, measured CPU speed = 199MHz
BIOS.cpuFreq.lo = 200000000 Hz
changing to CPU setpoint 2 ...
   myNotifyFxn - PENDING_CPU_SETPOINTCHANGE
     current = 1, next = 2
   myNotifyFxn - DONE_CPU_SETPOINTCHANGE
     previous = 1, current = 2
new setpoint = 2, measured CPU speed = 299MHz
BIOS.cpuFreq.lo = 300000000 Hz

Sleep Modes

This example demonstrates activation and wake from sleep modes. The application first registers for notification of sleep mode transitions. It then activates the Power_STANDBY and Power_SLEEP modes, with wakeup via the Clock timer tick. It then sets up an RTC alarm to wake the device in 15 seconds, and then activates Power_DEEPSLEEP.

To build this example you can create a CCS project using the two files: sleep6x.c and sleep6x.cfg. Create a CCS project like done for the previous example… Start the new project wizard to create a project. Select device Family of “C6000”, device variant of “Generic C674x Device”. Select the “Empty RTSC project” template and then click Next. Select the platform “ti.platforms.evm6748” from the drop list of available platforms. In the list of Product and Repositories, uncheck all the boxes except those for SYS/BIOS. Then click Finish. Unzip this file [sleep6x.zip], copy and paste the sleep6x.c and sleep6x.cfg files into the project, and then build the project.

NOTE: Because this example activates the device DEEPSLEEP mode, to run it with CCS it is critical that CCS is “Free Run”. So after loading the program, select Run->Free Run, and then halt the DSP after at least 15 seconds. Also, if this test is run on an OMAP-L138, the ARM processor must be “Free Run” during the test as well, otherwise there will be emulation failure messages to the console.

After halting the DSP, you can look at the output using the ROV tool. (Normally there won’t be any CCS console output for this test.) In ROV, look at the SysMin buffer contents. You should see output similar to the following:

registered for GOINGTOSLEEP event
registered for AWAKEFROMSLEEP event
registered for GOINGTODEEPSLEEP event
registered for AWAKEFROMDEEPSLEEP event
current Clock ticks = 0
going to STANDBY ...
awake from STANDBY, status = 0x0
current Clock ticks = 1
going to SLEEP ...
   myNotifyFxn - GOINGTOSLEEP
   myNotifyFxn - AWAKEFROMSLEEP
awake from SLEEP, status = 0x0
current Clock ticks = 2
current RTC time = 0 sec
going to DEEPSLEEP ...
   myNotifyFxn - GOINGTODEEPSLEEP
   myNotifyFxn - AWAKEFROMDEEPSLEEP
awake from DEEPSLEEP, status = 0x0
current RTC time = 15 sec

Known Issues

I2C Communication Failures on Beta SOMs

I2C communication instabilities occur on certain Beta C6748 and OMAPL138 SOMs on the evm6748. The instability occurs after commanding the DCDC3 output of the TPS65070 to move to or from 1.0V. The output voltage changes as expected, but further I2C communication with the TPS65070 may fail. (No issue has been seen for setpoints with voltages of 1.1V and 1.2V.) The defect was root-caused to an inappropriate signal buffer on the I2C clock signal line. For affected SOMs, scaling to/from 1.0V should be avoided.

No Update of DDR Timing Parameters

Power does not update DDR timing parameters as part of scaling PLL1 (i.e., the Peripheral domain) on the C6748 and OMAPL138 devices. This is not clearly described in current documentation. Depending upon your DDR configuration, it may be necessary for you to update timing parameters, after calling Power_changeSetpoint() to scale PLL1.

Linker Error when Resource Tracking is not Enabled

The Power module is designed to be scalable, meaning that if certain features are disabled, then the corresponding code and data won’t get linked into the application (reducing application memory footprint). The default configuration for Power has the Resource Tracking feature disabled. If the application makes Power_setDependency() or Power_releaseDependency() calls in C code, without first enabling the Resource Tracking feature in the application configuration, then a linker error like the following will occur:

   undefined symbol                       first referenced in file
  ----------------                       ------------------------
  ti_sysbios_family_c674_Power_database  C:\Program Files\TexasInstruments\bios_6_33_01_25\
                                     packages\ti\sysbios\family\c674\lib\debug\
                                     ti.sysbios.family.c674.ae674<Power.oe674>
  
  error: unresolved symbols remain

To avoid this error, and allow Power’s resource database to be linked into the application, the Resource Tracking feature needs to be enabled in the application configuration. This can be done either via the graphical configuration tool (by checking the box next to “Enable resource tracking” in the Power module page), or by adding the following to the application configuration script:

   Power.trackResources = true;