Windows Mobile 6.5 Hardware Interrupt Handling

Windows Mobile 6.5, powered by the Windows CE 5.2 real-time kernel, managed hardware interrupts through a predictable, two-tier architecture designed to ensure low latency and real-time responsiveness. By dividing interrupt processing into lightweight Interrupt Service Routines (ISRs) and thread-based Interrupt Service Threads (ISTs), the operating system maintained system stability while preventing hardware requests from locking up the device. This article details the sequence, components, and mapping mechanisms Windows Mobile 6.5 used to process peripheral hardware interrupts.

The Two-Tier Processing Model

Windows Mobile 6.5 avoided doing heavy processing inside the immediate hardware context. Instead, it decoupled low-level hardware responses from driver-level processing using a two-stage pipeline:

  1. Interrupt Service Routine (ISR): Executed in high-priority kernel space immediately after a hardware interrupt (IRQ) fired. Its sole duty was to determine the cause of the interrupt, mask it on the physical controller, translate the physical IRQ into a logical interrupt identifier (SYSINTR), and return that ID to the kernel. To maintain system responsiveness, ISRs performed the minimum possible work and executed with interrupts disabled or restricted.
  2. Interrupt Service Thread (IST): A standard or high-priority thread running within the device driver in user or kernel space. The IST handled data transfer, state changes, and hardware clean-up.

Physical-to-Logical Interrupt Mapping (IRQ to SYSINTR)

The kernel abstracted hardware-specific interrupts via logical IDs known as SYSINTR values:

  • Physical IRQ: The electrical interrupt line routed into the processor's interrupt controller.
  • SYSINTR: A platform-independent integer used by Windows Mobile drivers. Predefined constants existed for core components (such as SYSINTR_TOUCH, SYSINTR_KEYBOARD, or SYSINTR_RTC_ALARM), while dynamic ranges were reserved for OEM-specific peripheral hardware.

The OEM Adaptation Layer (OAL) handled this mapping. When an IRQ fired, the OAL's ISR checked the processor registers and mapped the line to the corresponding SYSINTR. This design allowed hardware drivers to remain portable across different chipsets, as drivers communicated strictly using logical SYSINTR values rather than physical CPU lines.

The Lifecycle of an Interrupt

The handling lifecycle followed a strict, deterministic sequence:

  1. Initialization: The peripheral device driver spawned a dedicated worker thread (the IST) and initialized a Win32 synchronization event. The driver then called InterruptInitialize(SYSINTR, hEvent, ...), linking the logical interrupt to that event.
  2. Waiting: The IST immediately entered an idle state by calling WaitForSingleObject(hEvent, INFINITE).
  3. Hardware Trigger: A peripheral device asserted an IRQ. The CPU vectored execution to the kernel’s core exception handler.
  4. ISR Execution: The kernel dispatched the registered ISR for that IRQ. The ISR acknowledged the hardware, masked the physical interrupt line, resolved the corresponding SYSINTR, and returned it to the kernel.
  5. Event Signaling: Upon receiving the SYSINTR, the Windows Mobile 6.5 kernel signaled the specific event associated with it, waking the dormant IST.
  6. IST Execution: The IST scheduled according to its thread priority. Once active, it performed the necessary processing, such as emptying hardware FIFO buffers or notifying higher-level subsystems.
  7. Re-enabling the Interrupt: After completing processing, the IST called InterruptDone(SYSINTR). The kernel notified the OAL to unmask the physical interrupt line, allowing the hardware to issue subsequent interrupts.

Scheduling and Real-Time Latency

Because Windows Mobile 6.5 utilized Windows CE's 256-level priority scheduler, ISTs could be assigned priorities ranging from 0 (highest) to 255 (lowest). Time-critical devices, such as the cellular baseband interface, touch digitizer, or audio subsystems, were typically configured with IST priorities between 0 and 99. This guaranteed that as soon as the ISR signaled the event, the kernel’s scheduler immediately preempted lower-priority background tasks to execute the IST deterministically.