Embedded Development: Handling Exceptions and Interrupts in eCos

This chapter is from the book

Embedded Software Development with eCos

Learn More Buy

This chapter is from the book

This chapter is from the book 

Embedded Software Development with eCos

Learn More Buy

3.2 Interrupts

An interrupt is an asynchronous external event that occurs during program execution, causing a break in the normal program execution. Typically, these external events are hardware related, such as a button press or timer expiration. Interrupts can happen at any time. Interrupts allow time-critical operations to be performed with higher precedence over normal program execution.

Similar to exception processing, when an interrupt occurs, the processor jumps to a specific address for execution of the Interrupt Service Routine (ISR). Hardware support for interrupts varies among different architectures. Each processor has its own number of interrupt pins to trigger the ISR.

The methods for vector handling among different architectures are also diverse. Some processor architectures support vectoring interrupts to individual vectors, while others have a single vector for all interrupts. When individual vectors are supported, an ISR can be attached directly to the vector for processing when the interrupt occurs. For single vector support, the software must determine which interrupt occurred before proceeding to the appropriate ISR.

One of the key concerns in embedded systems with respect to interrupts is latency. Latency is the interval of time from when an interrupt occurs until the ISR begins to execute. eCos employs an interrupt handling scheme to reduce interrupt latency in the system.

3.2.1 eCos Interrupt Model

eCos uses a split interrupt handling scheme where the interrupt processing is divided into two parts. The first part is the ISR, and the second part is the Deferred Service Routine (DSR). This scheme allows for the minimal amount of interrupt latency in the system by reducing the amount of time spent inside interrupt service routines. The idea is to keep the processing done in the ISR to a bare minimum. In this scheme, the DSR is executed with interrupts enabled, allowing other higher priority interrupts to occur and be processed in the midst of servicing a lower priority interrupt.

In some cases, where very little interrupt processing needs to be done, the interrupt can be handled in the ISR completely. If more complex servicing is required, a DSR should be used. The DSR is executed at a later time when thread scheduling is allowed. Executing the DSR at a later time allows the DSR to use kernel synchronization mechanisms; for example, to signal a thread, via a semaphore, that an interrupt has occurred. However, there are periods where thread scheduling is disabled by the kernel, although these periods are kept as small as possible. User threads can suspend scheduling as well. This prevents the DSR from executing. Preventing the DSR from executing in a timely manner can lead to system failures from an interrupt source overrunning. These issues should be kept in mind when designing the interrupt structure and how it interacts with the threads in the system.

In most cases, the DSR is executed immediately after the ISR completes. However, if a thread has locked the scheduler, the DSR is delayed until the thread unlocks it. The priority scheme is that ISRs have absolute priority over DSRs, and DSRs have absolute priority over threads.

For the split interrupt handling scheme to work, the ISR must ensure the interrupt that just occurred does not recur until the DSR has finished its processing. To accomplish this, the ISR masks the current interrupt and the DSR will unmask the current interrupt after it has been serviced.

Some HAL implementations offer an interrupt nesting scheme. In this scenario, higher priority interrupts can interrupt, and be processed before, lower priority interrupts. A configuration option is available to enable this nesting functionality, as shown in Item List 3.5.

3.2.1.1 Interrupt and Scheduler Synchronization

It is important to understand the interaction between the interrupt (ISR and DSR) and the scheduler. Certain guidelines must be followed during interrupt processing to ensure proper operation.

First, ISRs cannot make any scheduler-related synchronization function calls. These include kernel API functions for semaphores, mutexes, and condition variables. Kernel synchronization functions cause interaction with the scheduler, which is disabled during ISR execution. Making such calls causes undefined behavior in the system and can lead to system failures. The eCos interrupt scheme allows these synchronization calls to be made from the DSR.

Typically, the DSR will execute immediately after the ISR finishes. DSRs are only delayed if the thread that was interrupted had locked the scheduler for some reason. Since the DSR executes when thread scheduling is enabled, certain kernel synchronization calls are allowed from within the DSR. This enables a DSR to wake up a thread for additional processing after the interrupt has occurred.

However, DSRs must not make a synchronization call that blocks. Blocking occurs when code execution must wait for a resource to be released. For example, using the kernel API call cyg_mutex_lock stops the current thread from executing until the mutex is released, with a cyg_mutex_unlock call.

An example of a DSR that uses one of the kernel synchronization primitives is shown in Code Listing 3.2.

3.2.2 Interrupt Configuration

The eCos interrupt configuration options affect the way interrupts are processed in the system. Configuration options for interrupts are available at the HAL and kernel level. The configuration options available are architecture dependent.

The HAL-level configuration options are located under the HAL Interrupt Handling (CYGPKG_HAL_COMMON_INTERRUPTS) within the HAL Common Configuration Components. Item List 3.4 lists the configuration options available for setting up interrupts at the HAL level.

Item List 3.4 HAL Interrupt Configuration Options

Careful consideration is necessary when specifying the HAL interrupt configuration settings. Since the DSR executes with interrupts enabled, another interrupt might occur during the execution of the DSR. This means that the processor state information, which can be sizeable for certain architectures, for the current interrupt needs to be saved on the stack.

The stack used depends on the Use Separate Stack For Interrupts option. If this option is disabled, every thread in the system needs to be able to store the interrupt state information on its stack, since interrupts can happen at any time. If multiple interrupts occur, the stack would need the resources to hold the state information for each of these interrupts.

If Use Separate Stack For Interrupts is enabled, the threads in the system would only need to store a single interrupt state from the interrupt that caused the thread to de-schedule, along with its own thread state information. Only the interrupt stack has the responsibility to store this state information. The size of the interrupt stack should be carefully selected.

Another option that can change the way interrupts are handled is the configuration of Allow Nested Interrupts. The default setting for this option is disabled, meaning that interrupts are disabled during the ISR. When this option is enabled, the ISR enables interrupts to the processing of any higher priority interrupts that might occur. Some architectures support this feature in hardware. In most systems, the need to allow nested interrupts is nonexistent because the ISR is kept very short and the main work is accomplished in the DSR.

The kernel-level interrupt configuration options are under the Kernel Interrupt Handling (CYGPKG_KERNEL_INTERRUPTS) component. Within this component is the main option Use Delayed Service Routines (CYGIMP_KERNEL_INTERRUPTS_DSRS), which enables or disables the eCos split interrupt handling scheme.

The kernel-level interrupt suboptions available when using DSRs are listed in Item List 3.5.

Item List 3.5 Kernel Interrupt Configuration Options

3.2.3 Interrupt Handling

An interrupt is a type of exception that can be found in a processor's exception table. As mentioned previously, different architectures support interrupts in various methods; however, eCos provides a standard method for handling interrupts across all HAL architectures. The ARM architecture is the exception that deviates from the standard eCos interrupt handling model.

The eCos interrupt handling mechanism, described in this section, can be bypassed by installing a vector service routine in the VSR table directly from the application layer. The application is then solely responsible for implementing, in assembly language, all support that would otherwise have been provided by the HAL default interrupt VSR, such as storing and restoring the processor's current state after the interrupt has been serviced.

We are going to take a look at the default configuration when the HAL default interrupt VSR is used. The HAL default interrupt VSRs for the different architectures are shown in Table 3.2. Figure 3.2 illustrates the execution flow of the eCos interrupt handling method. This figure shows the level—application, kernel, and HAL—responsible for executing each piece of code.

Table 3.2 Default Interrupt Vector Service Routines

The following is a step-by-step description of the execution flow shown in Figure 3.2; the numbers correspond to the events in the diagram.

Figure 3.2 eCos interrupt handling execution flow.

1. The first item in Figure 3.2 shows the execution of a thread.

2. The next event is an external hardware interrupt.

3. Now, the processor looks into the VSR table, hal_vsr_table, to determine the location of the interrupt vector service routine to execute. During HAL startup, hal_mon_initinstalls the default interrupt VSR into the VSR table for the external interrupt. The names of the default interrupt VSRs for the different architectures are shown in Table 3.2. The ARM architecture is not shown in the table because it defines separate vector service routines for each of its interrupts.

4. Next, the default interrupt VSR begins executing. The first task of the default interrupt VSR is to save the current processor state. As mentioned before, the current processor's state can be saved either on a thread's stack or on the separate interrupt stack, depending on the HAL interrupt configuration options selected.

   After the processor's state information has been stored, the default interrupt VSR increments the cyg_scheduler_sched_lockkernel variable to ensure that scheduling does not take place.

   Next, the default vector service routine needs to find out what ISR to call. ISRs are installed by the application, as we see in the example in Code Listing 3.2.

   The HAL uses three tables, implemented as arrays, to maintain the ISR information needed. The size of these tables is architecture specific. The ISR tables are:

   • hal_interrupt_handlers—contains the addresses of the interrupt service routines installed by the application.

   • hal_interrupt_data—contains the data to be passed into the ISR.

   • hal_interrupt_objects—contains information that is used at the kernel level and hidden from the application layer.

   The HAL default interrupt VSR uses an architecture-specific function, hal_intc_decode, to perform the lookup into the hal_interrupt_handlers table. This function finds the index into the table based on the interrupt vector number and/or through examining the hardware, such as an interrupt controller. The value is used for indexing into the data (which is passed into the ISR) and objects (used at the kernel level) tables as well.

5. Next, the default VSR calls the ISR installed by the application. The ISR, which executes at the application level, performs any necessary functions for the particular interrupt. The ISR notifies the kernel that the DSR should be posted for execution by returning CYG_ISR_CALL_DSR. The ISR also returns CYG_ISR_HANDLED to terminate any chained interrupt processing. An example of an application ISR and DSR is shown in Code Listing 3.2.

6. After the ISR returns, the default interrupt VSR calls the function interrupt_end. The function interrupt_endis part of the kernel interrupt handling code and can be found in the file intr.cxxunder the kernel\current\src\intrsubdirectory.

7. If a DSR needs to execute, interrupt_end calls the function post_dsr. post_dsr, also part of the kernel interrupt handling code in the file intr.cxx, manages the implementation of posting the DSR. The two kernel interrupt configura-tion options Use Linked Lists For DSRs and Use Fixed-Size Table For DSRs determine the structure for the DSR list. See the Interrupt Configuration section in this chapter for a detailed description of these options.

8. After post_dsrreturns, interrupt_endthen unlocks the scheduler.

9. If the scheduler lock variable is at 0, the DSR executes. If the scheduler lock variable is greater than 0, then the thread that locked the scheduler executes at this point. In our case, we assume another thread has not locked the scheduler. An example of a DSR is shown in Code Listing 3.2. After the DSR completes, the scheduler unlock code continues execution.

10. Next, the HAL default interrupt VSR restores the processor state. This takes place in the routine restore_state, the same function called from the default exception VSR.

11. Finally, thread execution continues.

Let's now look at ISR and DSR functions. Both the ISR and DSR are set up in the application using the kernel API function calls. Code Listing 3.2 shows an example of ISR and DSR functions and how the kernel API is used to set them up.

 1  #include <cyg/kernel/kapi.h> 2
 2
 3  static cyg_interrupt int1;
 4  static cyg_handle_t int1_handle;
 5  static cyg_sem_t data_ready;
 6
 7  #define CYGNUM_HAL_INTERRUPT_1 1
 8  #define CYGNUM_HAL_PRI_HIGH 0
 9
10  //
11  // Interrupt service routine for interrupt 1.
12  //
13  cyg_uint32 interrupt_1_isr(
14              cyg_vector_t vector,
15              cyg_addrword_t data)
16  { 
17    // Block this interrupt from occurring until
18    // the DSR completes.
19    cyg_interrupt_mask( vector );
20
21    // Tell the processor that we have received
22    // the interrupt.
23    cyg_interrupt_acknowledge( vector );
24
25    // Tell the kernel that chained interrupt processing
26    // is done and the DSR needs to be executed next.
27    return( CYG_ISR_HANDLED | CYG_ISR_CALL_DSR );
28  }
29
30  // 
31  // Deferred service routine for interrupt 1.
32  // 
33  void interrupt_1_dsr(
34         cyg_vector_t vector,
35         cyg_ucount32 count,
36         cyg_addrword_t data)
37  {
38    // Signal the thread to run for further processing.
39    cyg_semaphore_post( &data_ready );
40
41    // Allow this interrupt to occur again.
42  cyg_interrupt_unmask( vector );
43  }
44
45  //
46  // Main starting point for the application.
47  //
48  void cyg_user_start(
49         void)
50  {
51    cyg_vector_t int1_vector = CYGNUM_HAL_INTERRUPT_1;
52    cyg_priority_t int1_priority = CYGNUM_HAL_PRI_HIGH;
53
54    // Initialize the semaphore used for interrupt 1.
55    cyg_semaphore_init( &data_ready, 0 );
56
57    //
58    // Create interrupt 1.
59    //
60    cyg_interrupt_create(
61       int1_vector,
62       int1_priority,
63       0,
64       &interrupt_1_isr,
65       &interrupt_1_dsr,
66       &int1_handle,
67       &int1);
68
69    // Attach the interrupt created to the vector.
70    cyg_interrupt_attach( int1_handle );
71
72    // Unmask the interrupt we just configured.
73    cyg_interrupt_unmask( int1_vector );
74  }

Code Listing 3.2 Example using the eCos kernel APIs for installing an interrupt within an application.

As we see in Code Listing 3.2, the main function, cyg_user_start on line 48, is called during the kernel startup procedure. We go through the kernel startup procedure in Chapter 5. After initializing the semaphore, see line 55, which is used in the DSR, the interrupt is created for the interrupt vector CYGNUM_HAL_INTERRUPT_1, using the kernel function cyg_interrupt_create, on line 60. The interrupt vector (CYGNUM_HAL_INTERRUPT_1 on line 51) and priority (CYGNUM_HAL_PRI_HIGH on line 52) are defined on lines 7 and 8, respectively. The data field, as we see on line 63, is set to zero since we do not need to pass anything into the ISR or DSR.

Next, the main function handles attaching the interrupt just created to the vector using cyg_interrupt_attach, shown on line 70. Finally, the interrupt 1 vector is unmasked, by cyg_interrupt_unmask on line 73, so that it can be processed when global interrupts are enabled. Global interrupts are enabled manually or, as in this example, when the scheduler starts after cyg_user_start returns.

The ISR, interrupt_1_isr on line 13, masks the current interrupt vector, shown on line 16, to ensure that it does not occur before the DSR has finished. It then acknowledges the interrupt within the processor, as we see on line 23. Lastly, the ISR signals to the kernel to post the DSR for further processing by returning CYG_ISR_CALL_DSR, on line 27. The ISR also returns CYG_ISR_HANDLED to terminate any chained interrupt processing.

When the DSR executes, interrupt_1_dsr on line 33, it signals a semaphore, as we see on line 39, and then unmasks the current interrupt, shown on line 42, so it can occur again. The semaphore, data_ready, used in this example demonstrates a method of synchronization between an interrupt and a thread. The thread, which is not included in the code listing, waits on this semaphore before beginning its processing. You can find the kernel API function descriptions for semaphores, including an example using the semaphore kernel API, in Chapter 6, Threads and Synchronization Mechanisms.

Detailed descriptions of the kernel API functions used in Code Listing 3.2, and the underlying HAL macros, are found in this chapter in the Interrupt Control section.

extern void
 cyg_interrupt_post_dsr(CYG_ADDRWORD
intr_handle); 

3.2.4 Interrupt Control

The HAL and kernel offer control over interrupt configuration. The HAL controls interrupts through the use of macros. The macro names are common across all HAL architectures; however, the implementations of these macros are architecture specific. The HAL macros are defined in the file hal_intr.h under the arch subdirectory.

The kernel API contains interrupt control functions that make use of these macros. Therefore, it is not necessary for an application to call directly into the HAL; rather, it can use the kernel API to configure system interrupts. The HAL and kernel interrupt control functionality is broken down into three groups:

• Interrupt Service Routine Management

• Interrupt State Management

• Interrupt Controller Management

3.2.4.1 Interrupt Service Routine Management

The first of the three groups, Interrupt Service Routine Management, controls the attachment and detachment of interrupt service routines within the three HAL ISR tables (handlers, data, and objects). The HAL ISR Management macros are described in Item List 3.6.

Item List 3.6 HAL Interrupt Service Routine Management Macros

HAL_INTERRUPT_ATTACH(
 _vector_,
 isr_,
 data_,
 object_
 )

HAL_INTERRUPT_DETACH(_
 vector_,
 _isr_
 );

The kernel API functions for Interrupt Service Routine Management are listed in Item List 3.7

Item List 3.7 Kernel Interrupt Service Routine Management API Functions

void
cyg_interrupt_create(
 cyg_vector_t vector,
 cyg_priority_t priority,
 cyg_addrword_t data,
 cyg_ISR_t *isr,
 cyg_DSR_t *dsr,
 cyg_handle_t *handle,
 cyg_interrupt *intr
 );

void
cyg_interrupt_delete(
 cyg_handle_t interrupt
 ); 

void
cyg_interrupt_attach(
 cyg_handle_t interrupt
 );

void
cyg_interrupt_detach(
 cyg_handle_t interrupt
 ); 

3.2.4.2 Interrupt State Management

The second group, Interrupt State Management, allows control over the state of the processor's interrupt mask mechanism by accessing the global interrupt enable found in the processor's register. These functions do not access the interrupt controller, which might be present on certain variants. The HAL Interrupt State Management macros are described in Item List 3.8.

Item List 3.8 HAL Interrupt State Management Macros

HAL_DISABLE_INTERRUPTS(
       _old_
       ) 

HAL_ENABLE_INTERRUPTS(
        ) 

HAL_RESTORE_INTERRUPTS(
       _old_
       ) 

HAL_QUERY_INTERRUPTS(
       _old_
       ) 

The kernel API functions for Interrupt State Management are listed in Item List 3.9.

Item List 3.9 Kernel Interrupt State Management API Functions

void
cyg_interrupt_disable(
 void
 ); 

void
cyg_interrupt_enable(
 void
 );

3.2.4.3 Interrupt Controller Management

The final group, Interrupt Controller Management, provides control over any interrupt controller that might be present for a specific variant. Not all HAL architectures have an interrupt controller.

A specific platform or variant that does contain an interrupt controller provides the implementation of these macros in its own interrupt definition file. The names of the platform or variant files containing these override macros differ among architectures. The HAL Interrupt Controller Management macros are defined in Item List 3.10.

Item List 3.10 HAL Interrupt Controller Management Macros

HAL_INTERRUPT_MASK(
 _vector_
 ) 

HAL_INTERRUPT_UNMASK(
 _vector_
 ) 

HAL_INTERRUPT_ACKNOWLEDGE(
 _vector_
 ) 

HAL_INTERRUPT_CONFIGURE(
 _vector_,
 level_,
 up_
 )

HAL_INTERRUPT_SET_LEVEL(
 _vector_,
 _level_
 )

The kernel API functions for the Interrupt Controller Management group are defined in Item List 3.11.

Item List 3.11 Kernel Interrupt Controller Management API Functions

void
cyg_interrupt_mask(
 cyg_vector_t vector
 );

void cyg_interrupt_mask_intunsafe(
 cyg_vector_t vector
 ); 

void
cyg_interrupt_unmask(
 cyg_vector_t vector
 ); 

void
cyg_interrupt_unmask_intunsafe(
 cyg_vector_t vector
 ); 

void
cyg_interrupt_acknowledge(
 cyg_vector_t vector
 ); 

void
cyg_interrupt_configure(
 cyg_vector_t vector,
 cyg_bool_t level,
 cyg_bool_t up
 ); 

The kernel API functions for Symmetric Multi-Processing (SMP) systems are defined in Item List 3.12. eCos support for SMP is covered in Chapter 8.

Item List 3.12 Kernel SMP Interrupt API Functions

void cyg_interrupt_set_cpu(
      cyg_vector_t vector, cyg_cpu_t cpu ); 

cyg_cpu_t cyg_interrupt_get_cpu(
      cyg_vector_t vector );