This blog demonstrates the Windows Embedded Compact 7 on NXPs iMX6 UltraLite evaluation kit with the video as a proof of Embien’s capability in porting WinCE 7 operating system on various processors and architectures.

The EVK includes an LCD display, audio playback and many connectivity options. It is designed to showcase the most commonly used features of iMX6UL processor in a small, low cost package and to facilitate software development with the ultimate goal of faster time to market.

Below is the video demonstration of the OS running on NXPs iMX6UL evaluation kit.

About Embien:

Embien Technologies is a leading service provider in the Embedded software domain. Our team has rich experience in working with various OS like Linux, Android, Windows CE, FreeRTOS, uC-OS, QNX etc. We have created various applications on top the WinCE systems such as HMI, Medical instrumentation displays, Smart Home control system etc. We have also enabled running legacy Windows Applications on top of latest hardware and software including emulation over Linux using technologies such as Mono, OpenNETCF etc.

Windows Embedded Compact 7 is a popular OS being used in low power embedded systems. Embien, working from its early iterations from 4.2 to latest 2013, has ported the same on to NXP’s iMx 6UL based development platforms. This blog demonstrates the Windows Embedded Compact 7 on iMx6 UltraLite with the video, show-casing our capability in porting such Operating systems to various processors and architectures.

Windows Embedded Compact 7

Windows Embedded Compact 7 more commonly known as WinCE 7 or WEC7 is the successor to the WinCE 6.0. Released on 2011, it is still one of the most popular versions of the Microsoft offerings for the embedded devices.

Some of the features of the OS include

  • Rich User Interface
  • Silverlight support
  • Support for Symmetric Multi processing (SMP)
  • Rich Media play back support
  • Complete Win95 based shell

In a WEC7, is still more sought after than its successor WEC2013 because of better licensing options and more importantly the availability of the Shell. From WEC2013, Microsoft removed the support for Windows 95 like Shell that forces the developer to offer an equivalent shell which involves a lot of effort. Further WEC 7 can be ported on the non-Thumb2 only devices too.

WinCE on NXP iMx6UL

Embien offers its expertise in Windows CE for porting the RTOS on to various platforms. One of the most popular low cost SoC of recent times from NXP stables is the iMx6UL. This processor has gained a good market share at low power low cost computing. Some of the features include

  • ARM® Cortex®-A7 @ 696 MHz, 128 KB L2 cache
  • Parallel LCD Display up to WXGA (1366×768)
  • 8/10/16/24-bit Parallel Camera Sensor Interface
  • 16-bit LP-DDR2, DDR3/DDR3L
  • 8/16-bit Parallel NOR FLASH / PSRAM
  • Dual-channel Quad-SPI NOR FLASH
  • 8-bit Raw NAND FLASH with 40-bit ECC
  • 2x MMC 4.5/SD 3.0/SDIO Port
  • 2x USB 2.0 OTG, HS/FS, Device or Host with PHY
  • Audio Interfaces include 3x I2S/SAI, S/PDIF Tx/Rx
  • 2x 10/100 Ethernet with IEEE 1588
  • 2x 12-bit ADC, up to 10 input channel total, with resistive touch controller (4-wire/5-wire)
  • Advanced Power Management
  • Partial PMU Integration

Many vendors offers different development boards for the same. Some of the popular platforms are

  • NXP – iMX 6 UltraLite EVK
  • Variscite – DART-6UL
  • Compu lab – SOM-iMX6UL
  • TechNexion’s PICO-IMX6 COM
  • iWave Systems – iW-RainboW-G18M-SM
  • Embedded Artists – iMX6 UltraLite COM Board

Embien has ported Windows Embedded Compact 7 (WEC7) on to the NXP iMx6UL supporting all the major peripherals. Below is a video demonstration of the port running on the Variscite DART-6UL platform.


A video of WEC7 running on NXP iMx6UL Platform.

About Embien: Embien Technologies is a leading service provider in the Embedded software domain. Our team has rich experience in working with various OS like Linux, Android, Windows CE, FreeRTOS, uC-OS, QNX etc. We have created various applications on top the WinCE systems such as HMI, Medical instrumentation displays, Smart Home control system etc. We have also enabled running legacy Windows Applications on top of latest hardware and software including emulation over Linux using technologies such as Mono, OpenNETCF etc.


Saravana Pandian Annamalai
27. October 2016 · Write a comment · Categories: ARM, Embedded Software, Technology · Tags: ,

With an understanding of ARM registers and Exception model, now we are ready to explore the ARM interrupt controllers. These are the modules that sit in between the interrupt sources (peripherals) and ARM cores deciding how to route the interrupts to.

The ARM core accepts only two input signals handling unscheduled interrupts from the external systems – nIRQ and nFIQ. If IRQ is asserted, the system enters IRQ mode as discussed earlier or if FIQ is asserted, FIQ mode is entered.

It is up to the ARM licences i.e SoC manufacturer to decide the mechanism to route the interpret signals to the core. There are many ways to implement the interrupt controllers each of which are discussed in detail in this blog.

Vendor Specific Model

In the early ARM implementations where there used to be only one core in general, the logic for this routing of interrupts to the core is done by the SoC manufacturer mostly based on their design philosophy. More likely there will be a set of following registers

  • RAW Interrupt Status register
  • Interrupt Enable Register
  • Interrupt Status Register
  • IRQ Priority Encoding
  • FIQ/IRQ Selection

Up on assertion of any interrupt line, the interrupt source is checked if it is configured as FIQ. If so, the signal is routed to the core immediately. If it is an IRQ interrupt, ARM interrupt status is updated. If multiple interrupts occur simultaneously, the priority is resolved between other pending interrupts and finally the core is given the interrupt signal.

The below diagram gives a model implementation for the Interrupt Controller by Freescale called the Interrupt Collector (ICOLL) used in Freescale/NXP iMx233/iMx28 series of MCUs.

Freescale Interrupt Collector

Vendor specific Interrupt Controller

Vectored Interrupt Controller – VIC

ARM itself came up with a model called Vectored Interrupt Controller (VIC). Sitting directly on the AMBA High Speed bus, the latency is significantly reduced. Being an early generation controller it supports 32 interrupt sources each of which can be routed to either FIQ or IRQ signals. A unique feature of VIC is that, as it name suggests, it supports 16 vectored interrupts. In this there are 16 registers where the address of the corresponding interrupt service routines (ISR) can be saved. Based on the priority, the VIC identifies the high priority interrupt and loads its ISR address to a register called VICVectAddr. The firmware can simply use a LDR PC instruction to jump to this ISR. This saves a lot of software effort in branching to the ISR there by reducing latency.

Interrupt Controller from ARM

Vectored Interrupt Controller (VIC)

But VIC supports only level sensitive interrupts that must remain active HIGH till the ISR services it. Thus for these reasons, many SoC designers preferred their own implementation rather than the VIC.

Generic Interrupt Controller – GIC

As processors evolved, soon the number of interrupts became quiet large and also it was not uncommon to have more than 1 core (either symmetric or asymmetric), there was a need for a more standardized way of handling interrupts.

ARM defines Generic Interrupt Controller that suits this need. Though vendors are still free to choose their own mechanism, GIC has become very popular and is almost present in all modern SoCs. It consists of primarily two components – Distributor and CPU interfaces. The primary functionalities of the same include


This is the peripheral facing component that is available as only one implementation (instance). It is responsible for managing interrupts in the whole system and decides priorities between them and routing mechanism of the same.

CPU Interfaces:

For each CPU core available, there is a corresponding CPU Interface present bridging the Distributor interface with the core. It implements the priority masking for the processor.

The below diagram explains the same.


ARM's Interrupt Controller for Multi-core SoCs

ARM Generic Interrupt Controller (GIC)

The interrupts are identified by unique ID and could be in any one of the following 4 states (as explained by the GIC Architecture Specification):

  • Inactive: An interrupt that is not active or pending.
  • Pending: An interrupt from a source to the GIC that is recognized as asserted in hardware or generated by software and is waiting to be serviced by a target processor.
  • Active: An interrupt from a source to the GIC that has been acknowledged by a processor, and is being serviced but has not completed.
  • Active and pending: A processor is servicing the interrupt and the GIC has a pending interrupt from the same source.

Based on the source, there are three major types of interrupts defined.

Shared Peripheral Interrupts – SPI: These interrupts sources are typically from different peripherals in the system. They can be routed to (i.e shared with) any one or more of the cores as per the requirement and will be handled suitably. For example, UART0 and UART1 interrupts could be SPI and configured in the Distributor to be routed to two available cores. Up on UART0 interrupt, the signal is routed to first available processor. If at that instance, UART1 interrupt is received, the distributor routes it to the other core for handling.

These are assigned Interrupt ID from 32 to 1019.

Private Peripheral Interrupts – PPI: There could be interrupts that are only specific to one processor. In such cases, they are routed to PPI of only that processor. For example in an asymmetric system with a Cortex A5 and Cortex M4, a Watchdog interrupt corresponding to A5 will be routed only to the A5 core. There might be no need to share it with the M4. Hence it will be routed as a PPI.

The interrupt ID is defined from 16 to 31.

Software Generated Interrupts – SGI: ARM defines interrupt IDs 0 through 15 specifically for Inter processor communication. It is possible a SGI can be routed to one or more processors through the Distributor.

The Interrupts 0 to 31 are banked by the distributor for each CPU Interface i.e. each processor sees them different and are identified by the CPUID. For example, PPI 16 could be pending in CPU0 but not in CPU1. Whereas, in case of the SPI, it will be same across the CPU’s as they are not banked.

Irrespective of all these, each core is provided signal through either nIRQ or nFIQ lines for interrupting program execution.

Nested Vectored Interrupt Controller – NVIC

While the above implementations are suitable for powerful processors, there is a need for specialized handling in microcontroller profiles that typically run in sub-100MHz speed and with few tens of kilobytes of RAM and flash. It is important to reduce the interrupt latency and to leverage the fact that the number of peripherals is less and hence fewer interrupt sources. For that, ARM defines a NVIC model for the Cortex-M implementations.

In Cortex-M implementation, the interrupt service routine addresses are to be provided in a set of consecutive addresses at offsets corresponding to the vector number. As soon as the interrupt signals are received, the NVIC finds the ISR corresponding to the highest priority interrupt and jumps to it.

The Cortex-M core accepts only nIRQ interrupt and there is no option for a FIQ.

With our understanding of hardware implementation, in the upcoming blogs, we will discuss software mechanism in handling interrupts in ARM architectures.