How Windows Mobile 6.5 Woke the CPU from Sleep
In Windows Mobile 6.5, background applications woke the CPU from a
low-power suspended state through a combination of the hardware
Real-Time Clock (RTC), kernel-level interrupts, and the Windows CE
Notification Engine. By leveraging dedicated APIs like
CeRunAppAtTime and utilizing the OS's specialized
"Unattended" power state, developers could schedule precise wake-up
triggers that activated the processor to perform tasks—such as syncing
email or firing alarms—without turning on the device’s display or
alerting the user.
The Hardware RTC and Interrupt Architecture
When a Windows Mobile 6.5 device entered its lowest power state, known as the Suspended state, the CPU halted most operations, cutting clock cycles to conserve battery life. While active processes were frozen in RAM, the hardware Real-Time Clock (RTC) continued running independently on low power.
To wake the CPU, the system relied on hardware-level wake interrupts:
- An application requested a wake-up time in the future.
- The operating system configured the RTC's hardware alarm registers via the OEM Adaptation Layer (OAL).
- When the target timestamp was reached, the RTC raised a hardware interrupt (IRQ).
- The OAL mapped this IRQ to a system interrupt
(
SYSINTR_RTC_ALARM), which signaled the kernel to restore power rails, unfreeze processor clocks, and resume execution.
The
Notification Engine: CeRunAppAtTime and
CeSetUserNotificationEx
Applications did not interact directly with the hardware timers. Instead, they registered wake events with the Windows Embedded CE Notification Subsystem using two primary APIs:
CeRunAppAtTime: Instructed the OS to launch an executable file or trigger a named system event at a specific time. If the device was suspended when the target time arrived, the system automatically initiated the wake-up sequence.CeSetUserNotificationEx: A more comprehensive API used for recurring schedules, notifications, and background triggers. It allowed an app to set compound scheduling rules (e.g., waking up periodically every 30 minutes to check an inbox).
When an app registered a wake event through these APIs, the notification subsystem evaluated the earliest scheduled trigger across the entire system and programmed that specific target into the RTC alarm.
The "Unattended" Power State
Waking the CPU did not mean fully turning on the phone. Windows Mobile 6.5 implemented an advanced Power Manager architecture designed to separate internal computation from user-facing peripherals.
When the RTC alarm woke the CPU, the device entered the Resuming state and immediately transitioned to Unattended Mode:
- Display and Backlight: Remained completely powered down.
- Audio: Remained muted unless explicitly engaged by an alarm sound.
- CPU and Radio: Fully operational, allowing network access (Wi-Fi or cellular data) and storage I/O.
Maintaining
Execution with PowerPolicyNotify
Because the system was designed to return to sleep quickly to prevent battery drain, the OS would automatically transition back to the Suspended state after a brief timeout (typically a few seconds) if it detected no user input.
To prevent premature suspension during a background task, the application had to inform the Power Manager that it was actively working by making the following call:
PowerPolicyNotify(PPN_UNATTENDEDMODE, TRUE);This API call locked the device in the Unattended state, preventing the CPU from falling back asleep while the background process finished downloading data, computing tasks, or writing to the database.
Returning to Deep Sleep
Once the background work was finished, the application released its power lock:
PowerPolicyNotify(PPN_UNATTENDEDMODE, FALSE);Once all active applications released their hold on Unattended Mode, the Power Manager's inactivity timer expired. The system saved the current CPU context back to RAM, shut down non-essential internal rails, reprogrammed the RTC for the next registered event in the queue, and placed the CPU back into the Suspended state.