Comtrol eCos - Manual (Page 305)

Chapter 10. Exception Handling
The default interrupt VSR has a number of responsibilities if it is going to interact with the Kernel cleanly and
allow interrupts to cause thread preemption.
To support this VSR an ISR vector table is needed. For each valid vector three pointers need to be stored: the ISR,
its data pointer and an opaque (to the HAL) interrupt object pointer needed by the kernel. It is implementation
defined whether these are stored in a single table of triples, or in three separate tables.
The VSR follows the following approximate plan:
1. Save the CPU state. In non-debug configurations, it may be possible to get away with saving less than the
entire machine state. The option CYGDBG_HAL_COMMON_INTERRUPTS_SAVE_MINIMUM_CONTEXT is supported
in some targets to do this.
2. Increment the kernel scheduler lock. This is a static member of the Cyg_Scheduler class, however it has also
been aliased to cyg_scheduler_sched_lock so that it can be accessed from assembly code.
3. (Optional) Switch to an interrupt stack if not already running on it. This allows nested interrupts to be de-
livered without needing every thread to have a stack large enough to take the maximum possible nesting. It
is implementation defined how to detect whether this is a nested interrupt but there are two basic techniques.
The first is to inspect the stack pointer and switch only if it is not currently within the interrupt stack range;
the second is to maintain a counter of the interrupt nesting level and switch only if it is zero. The option
CYGIMP_HAL_COMMON_INTERRUPTS_USE_INTERRUPT_STACK controls whether this happens.
4. Decode the actual external interrupt being delivered from the interrupt controller. This will yield the ISR
vector number. The code to do this usually needs to come from the variant or platform HAL, so is usually
present in the form of a macro or procedure callout.
5. (Optional) Re-enable interrupts to permit nesting. At this point we can potentially allow higher priority inter-
rupts to occur. It depends on the interrupt architecture of the CPU and platform whether more interrupts will
occur at this point, or whether they will only be delivered after the current interrupt has been acknowledged
(by a call to
HAL_INTERRUPT_ACKNOWLEDGE() in the ISR).
6. Using the ISR vector number as an index, retrieve the ISR pointer and its data pointer from the ISR vector
table.
7. Construct a C call stack frame. This may involve making stack space for call frames, and arguments, and
initializing the back pointers to halt a GDB backtrace operation.
8. Call the ISR, passing the vector number and data pointer. The vector number and a pointer to the saved state
should be preserved across this call, preferably by storing them in registers that are defined to be callee-saved
by the calling conventions.
9. If this is an un-nested interrupt and a separate interrupt stack is being used, switch back to the interrupted
thread’s own stack.
10. Use the saved ISR vector number to get the interrupt object pointer from the ISR vector table.
11. Call interrupt_end() passing it the return value from the ISR, the interrupt object pointer and a pointer
to the saved CPU state. This function is implemented by the Kernel and is responsible for finishing off the
interrupt handling. Specifically, it may post a DSR depending on the ISR return value, and will decrement the
scheduler lock. If the lock is zeroed by this operation then any posted DSRs may be called and may in turn
result in a thread context switch.
12. The return from interrupt_end() may occur some time after the call. Many other threads may have ex-
ecuted in the meantime. So here all we may do is restore the machine state and resume execution of the
201