CS452 - Real-Time Programming - Winter 2016

Lecture 12 - AwaitEvent, Clock Server

Pubilc Service Annoucements

  1. Due date for kernel 3: 8 February, 2016.

The Hardware in the Trains Lab

32-bit Timer

Base address: 0x80810080

The four registers of the timer.
Offset Function R/W Bits Comments
0x0 Timer3Load R/W 32: <Load/Reload Value>
0x4 Timer3Value R 32:<Current value> Set when Load is written,
even when counting
0x8 Timer3Control R/W 32:the lowest order bits are <CLKSEL>xx<MODE><ENABLE> <CLKSEL>: 0, 2KHz clock; 1, 508KHz
<MODE>: 1, count continuously; 0, count once
<ENABLE>: Clock turned on
0xc Timer3Clear W 32: Writing anything clears the interrupt

Interrupt Control Unit (ICU)

The actual device is the ARM PL190, and there are two of them in the SoC. In the Cirrus documentation they are called VIC1 and VIC2.

Base addresses

Basic Operation

VIC powers up with

Most likely you will change only the last of them.



  1. leave protection off, unless you are in doubt about your partner's ethics or competence.
  2. enable in VICxIntEnable only when you are ready to handle the interrupt

On an interrupt, the kernel

  1. reads the VICxIRQStatus register,
  2. chooses which interrupt to handle and
  3. clears the interrupt source in the device.

For debugging

  1. Use VICxSoftInt and VICxSoftIntClear to turn interrupt sources off and on in software

Hardware Definitions

Registers for Basic Operation
Register Name Offset R/W Description
VICxIRQStatus 0x00 RO One bit for each interrupt source

1 if interrupt is asserted and enabled

VICxFIQStatus 0x04 RO As above for FIQ
VICxRawIntr 0x08 RO As above but not masked
VICxIntSelect 0x0c R/W 0: IRQ, 1: FIQ
VICxIntEnable 0x10 R/W 0: Masked, 1: Enabled
VICxIntEnClear 0x14 WO Clears bits in VICxIntEnable
VICxSoftInt 0x18 R/W Asserts interrupt from software
VICxSoftIntClear 0x1c WO Clears interrupt from software
VICxProtection 0x20 R/W Bit 0 enables protection from user mode access
VICxVectAddr 0x30 R/W Enables priority hardware

See documentation.

Non-vectored Operation


  1. Create user tasks with interrupts enabled.
  2. Enable interrupt in device
  3. Enable interrupt in ICU
  4. Enable interrupt in CPU, by MOVS whenever a task is activated.

Normal operation

When a hardware interrupt occurs you find yourself in IRQ mode. Next, you

  1. Remember that you started in IRQ mode.
  2. Switch to svc mode.
  3. Do the context switch.
  4. Look at the active interrupt sources; decide which one you will service; turn it off.
  5. Find which task is blocked waiting for the interrupt.
  6. Set up its return value, and make it ready.
Tasks waiting on interrupts are normally high priority, and usually run right away.

If a second interrupt occurs immediately

  1. The CPU checks AND( IRQ, NOT( IRQ disabled bit set in CPSR ) ) before each instruction fetch.
  2. If it is asserted an IRQ exception is taken in place of next instruction fetch.
  3. Context switch into kernel
  4. Turn off interrupt in device

Last gasp of the hardware context switch

I have alluded several times to the IP bug, which occurs when you fail to save IP. Very infrequently a hardware interrupt occurs between two instructions

    mov	ip,sp
    stm sp!,{fp,ip,lr}
in every function preamble. The result is an activated task with another task's stack. In a running train program this bug occurs every several minutes.

There is a dual bug, the LR bug, in which one task's data gets another task's instructions. Here is a sequence that produces it.

  1. A hardware interrupt occurs.
  2. The registers of the interrupted task are pushed onto its stack.
  3. The lr_IRQ overwrites the lr on the stack.
  4. When the interrupted task is next scheduled, registers r0-r14 are restored in system mode.
  5. Then, movs pc, lr restarts execution of the interrupted task in scv mode.
This almost always works, but very infrequently it crashes. Why?


The final Kernel Primitive

... except for Destroy

int AwaitEvent( int eventType )

More About AwaitEvent


  1. Somewhere there is a list of event types
  2. This is not very portable

Processing in the kernel

Clock Server, Task Structure

How is AwaitEvent Used?

  1. There should (almost) always be a task blocked on AwaitEvent for every interrupt type. Why?
  2. A server cannot call AwaitEvent. Why?
  3. We call the task that calls AwaitEvent a Notifier. Why?
  4. Code for a typical Notifier
    struct delivery {
        int type;
        int data;
    void notifier( ) {
        struct delivery request;
        // Initialization, probably including device
        // Synchronization
        FOREVER {
            request.data = AwaitEvent( evtType );
            request.type = NOTIFIER;
            Send( server, &request, ... );
  5. Code for a typical server
    void server( ) {
        struct delivery request;
        // create notifier
        // other initialization
        // synchronization
        FOREVER {
            Receive( &requester, &request, ... );
            switch ( request.type ) {
            case NOTIFIER:
                Reply( notifier );
                data = request.data;
                // use data
            case CLIENT:

HALT versus an Idle Task

What do you do when there are no tasks to run?

Clock Server


int Time( )
int Delay( int ticks )
int DelayUntil( int ticks )


void clock( ) {
    // Create Notifier and send  any initialization data
    // Initialize self
        Receive( &requester, &request, ... );
        switch ( request.type ) {
        case NOTIFIER:
            Reply( notifier, ... )
            // update time and check for terminated delays
        case TIME_REQUEST:
            Reply( requester, time,... )
        case DELAY_REQUEST: 
            // Add requester to list of suspended tasks
        // Reply to any timed-out tasks


  1. You need a common request type, or possibly a union.
  2. You should notice a typical server pattern.

It's normal to sort the list of suspended tasks. Why?

Return to: