The OEMPowerOff routine is part of the OAL and responsible for switching the CPU into Suspend state. OEMPowerOff should also put the RAM into self-refresh mode if the processor does not automatically do so when it enters the Suspend state. You can also set up the interrupts to wake up the device. In handheld devices, this is typically the power-button interrupt, but you may use any wakeup event source that is appropriate for your target platform.
Entering the Suspend State
When entering the Suspend state, Windows Embedded CE performs the following sequence of steps:
1. GWES notifies the Taskbar about the power down event.
2. The system aborts calibration if in the calibration screen.
3. The system stops the Windows message queues. After step 3, the system enters single-thread mode, which prevents function calls that rely on blocking operations.
4. The system checks if the startup user interface (UI) must appear on resume.
5. The system saves video memory to RAM.
6. The system calls SetSystemPowerState (NULL, POWER_STATE_SUSPEND, POWER_FORCE).
7. Power Manager:
a. Calls the FileSystemPowerFunction to power off the drivers related to the file system.
b. Calls PowerOffSystem to inform the kernel to do the final power down.
c. Calls Sleep(0) to invoke the scheduler.
If the OS design does not include Power Manager or GWES, then the OEM must explicitly call FileSystemPowerFunction and PowerOffSystem.
8. Kerneclass="underline"
a. Unloads GWES process.
b. Unloads Filesys.exe.
c. Calls OEMPowerOff.
9. OEMPowerOff configures the interrupts and puts the CPU in Suspend state.
Waking Up from Suspend State
When a pre-configured interrupt wakes up the system, the associated ISR runs and returns to the OEMPowerOff routine. On returning from this function, the system goes through the resume sequence, which includes the following steps:
1. OEMPowerOff re-configures interrupts to original state and returns.
2. Kerneclass="underline"
a. Calls InitClock to re-initialize the system timer.
b. Starts Filesys.exe with power on notification.
c. Starts GWES with power on notification.
d. Re-initializes KITL interrupt if it was in use.
3. Power Manager calls FileSystemPowerFunction with power on notification.
4. GWES:
a. Restores video memory from RAM.
b. Powers on Windows Manager.
c. Sets the display contrast.
d. Shows startup UI if required.
e. Notifies Taskbar of resume.
f. Notifies User Subsystem.
g. Triggers applications as required.
If the OAL supports the kernel IOCTL_HAL_ENABLE_WAKE, applications can register wake up sources. For detailed information, see the section "IOCTL_HAL_ENABLE_WAKE" in the Windows Embedded CE 6.0 Documentation, available on the Microsoft MSDN Web site at http://msdn2.microsoft.com/en-us/library/aa914884.aspx.
Supporting the Critical Off State
On hardware platforms equipped with a voltage comparator that triggers NMI, you can implement support for the Critical Off state to protect the user from data loss in low-battery conditions. On x86 hardware, the kernel exports the OEMNMIHandler function to capture critical events in the system. On other systems, you might have to implement a custom IST that calls SetSystemPowerState to turn off the system gracefully with the help of Power Manager. The Critical Off state typically corresponds to the Suspend state with dynamic RAM refresh enabled.
When implementing Critical Off state support, make sure you trigger the NMI at a point when the system still has time to perform all power down tasks , such as powering down peripherals, putting RAM into self-refresh, perhaps setting a wakeup condition, and suspending the CPU.
Lesson Summary
Power management is an important Windows Embedded CE feature that ensures efficient power consumption on target devices. OEMs should implement power management features in the OAL to enable transitions from full-power mode to Idle and Suspend modes and Critical Off state for battery-powered devices. Implementing power management support involves re-synchronizing timer-related kernel variables, powering down peripherals, putting RAM into self-refresh mode, setting wakeup conditions, and suspending the CPU. It is not trivial to implement these low-level routines, yet Microsoft provides sufficient reference code in the sample BSPs to get a better understanding of the implementation details.
Lab 5: Adapting a Board Support Package
In this lab you clone a reference BSP in Visual Studio 2005 with Platform Builder and use it to build a run-time image. As the underlying platform, this lab uses the Device Emulator because this platform can run on the Windows Embedded CE development computer. Microsoft included the Device Emulator BSP in Platform Builder as a reference BSP.
To help you successfully master the procedures presented in this Lab, see the document "Detailed Step-by-Step Instructions for Lab 5" in the companion material for this book.
► Clone a BSP
1. In Visual Studio 2005, open the Tools menu, click Platform Builder For CE 6.0, and then click Clone BSP.
2. In the Clone Board Support Package window select Device Emulator: ARMV4I as the Source BSP from the drop-down list.
3. Under New BSP Information enter the information shown in Table 5-12 (see also Figure 5-10):
Table 5-12 New BSP details
| Parameter | Value |
|---|---|
| Name | DeviceEmulatorClone |
| Description | Clone of the Device Emulator BSP |
| Platform Directory | DeviceEmulatorClone |
| Vendor | Contoso Ltd. |
| Version | 0.0 |
4. Select Open New BSP Catalog File In Catalog Editor check box and then click Clone.
5. Verify that Platform Builder clones the Device Emulator BSP successfully, and then in the corresponding Clone BSP dialog box, click OK.