mirror of
https://gitlab.rtems.org/rtems/rtos/rtems.git
synced 2025-12-06 15:43:15 +00:00
6449498bc7
* SUPPORT, LICENSE: New files. * Numerous files touched as part of merging the 4.5 branch onto the mainline development trunk and ensuring that the script that cuts snapshots and releases works on the documentation.
197 lines
6.5 KiB
Perl
197 lines
6.5 KiB
Perl
@c
|
|
@c Interrupt Stack Frame Picture
|
|
@c
|
|
@c COPYRIGHT (c) 1988-2002.
|
|
@c On-Line Applications Research Corporation (OAR).
|
|
@c All rights reserved.
|
|
@c
|
|
@c $Id$
|
|
@c
|
|
|
|
@chapter Interrupt Processing
|
|
|
|
@section Introduction
|
|
|
|
Different types of processors respond to the
|
|
occurrence of an interrupt in its own unique fashion. In
|
|
addition, each processor type provides a control mechanism to
|
|
allow for the proper handling of an interrupt. The processor
|
|
dependent response to the interrupt modifies the current
|
|
execution state and results in a change in the execution stream.
|
|
Most processors require that an interrupt handler utilize some
|
|
special control mechanisms to return to the normal processing
|
|
stream. Although RTEMS hides many of the processor dependent
|
|
details of interrupt processing, it is important to understand
|
|
how the RTEMS interrupt manager is mapped onto the processor's
|
|
unique architecture. Discussed in this chapter are the XXX's
|
|
interrupt response and control mechanisms as they pertain to
|
|
RTEMS.
|
|
|
|
@section Vectoring of an Interrupt Handler
|
|
|
|
Depending on whether or not the particular CPU
|
|
supports a separate interrupt stack, the XXX family has two
|
|
different interrupt handling models.
|
|
|
|
@subsection Models Without Separate Interrupt Stacks
|
|
|
|
Upon receipt of an interrupt the XXX family
|
|
members without separate interrupt stacks automatically perform
|
|
the following actions:
|
|
|
|
@itemize @bullet
|
|
@item To Be Written
|
|
@end itemize
|
|
|
|
@subsection Models With Separate Interrupt Stacks
|
|
|
|
Upon receipt of an interrupt the XXX family
|
|
members with separate interrupt stacks automatically perform the
|
|
following actions:
|
|
|
|
@itemize @bullet
|
|
@item saves the current status register (SR),
|
|
|
|
@item clears the master/interrupt (M) bit of the SR to
|
|
indicate the switch from master state to interrupt state,
|
|
|
|
@item sets the privilege mode to supervisor,
|
|
|
|
@item suppresses tracing,
|
|
|
|
@item sets the interrupt mask level equal to the level of the
|
|
interrupt being serviced,
|
|
|
|
@item pushes an interrupt stack frame (ISF), which includes
|
|
the program counter (PC), the status register (SR), and the
|
|
format/exception vector offset (FVO) word, onto the supervisor
|
|
and interrupt stacks,
|
|
|
|
@item switches the current stack to the interrupt stack and
|
|
vectors to an interrupt service routine (ISR). If the ISR was
|
|
installed with the interrupt_catch directive, then the RTEMS
|
|
interrupt handler will begin execution. The RTEMS interrupt
|
|
handler saves all registers which are not preserved according to
|
|
the calling conventions and invokes the application's ISR.
|
|
@end itemize
|
|
|
|
A nested interrupt is processed similarly by these
|
|
CPU models with the exception that only a single ISF is placed
|
|
on the interrupt stack and the current stack need not be
|
|
switched.
|
|
|
|
The FVO word in the Interrupt Stack Frame is examined
|
|
by RTEMS to determine when an outer most interrupt is being
|
|
exited. Since the FVO is used by RTEMS for this purpose, the
|
|
user application code MUST NOT modify this field.
|
|
|
|
The following shows the Interrupt Stack Frame for
|
|
XXX CPU models with separate interrupt stacks:
|
|
|
|
@ifset use-ascii
|
|
@example
|
|
@group
|
|
+----------------------+
|
|
| Status Register | 0x0
|
|
+----------------------+
|
|
| Program Counter High | 0x2
|
|
+----------------------+
|
|
| Program Counter Low | 0x4
|
|
+----------------------+
|
|
| Format/Vector Offset | 0x6
|
|
+----------------------+
|
|
@end group
|
|
@end example
|
|
@end ifset
|
|
|
|
@ifset use-tex
|
|
@sp 1
|
|
@tex
|
|
\centerline{\vbox{\offinterlineskip\halign{
|
|
\strut\vrule#&
|
|
\hbox to 2.00in{\enskip\hfil#\hfil}&
|
|
\vrule#&
|
|
\hbox to 0.50in{\enskip\hfil#\hfil}
|
|
\cr
|
|
\multispan{3}\hrulefill\cr
|
|
& Status Register && 0x0\cr
|
|
\multispan{3}\hrulefill\cr
|
|
& Program Counter High && 0x2\cr
|
|
\multispan{3}\hrulefill\cr
|
|
& Program Counter Low && 0x4\cr
|
|
\multispan{3}\hrulefill\cr
|
|
& Format/Vector Offset && 0x6\cr
|
|
\multispan{3}\hrulefill\cr
|
|
}}\hfil}
|
|
@end tex
|
|
@end ifset
|
|
|
|
@ifset use-html
|
|
@html
|
|
<CENTER>
|
|
<TABLE COLS=2 WIDTH="40%" BORDER=2>
|
|
<TR><TD ALIGN=center><STRONG>Status Register</STRONG></TD>
|
|
<TD ALIGN=center>0x0</TD></TR>
|
|
<TR><TD ALIGN=center><STRONG>Program Counter High</STRONG></TD>
|
|
<TD ALIGN=center>0x2</TD></TR>
|
|
<TR><TD ALIGN=center><STRONG>Program Counter Low</STRONG></TD>
|
|
<TD ALIGN=center>0x4</TD></TR>
|
|
<TR><TD ALIGN=center><STRONG>Format/Vector Offset</STRONG></TD>
|
|
<TD ALIGN=center>0x6</TD></TR>
|
|
</TABLE>
|
|
</CENTER>
|
|
@end html
|
|
@end ifset
|
|
|
|
@section Interrupt Levels
|
|
|
|
Eight levels (0-7) of interrupt priorities are
|
|
supported by XXX family members with level seven (7) being
|
|
the highest priority. Level zero (0) indicates that interrupts
|
|
are fully enabled. Interrupt requests for interrupts with
|
|
priorities less than or equal to the current interrupt mask
|
|
level are ignored.
|
|
|
|
Although RTEMS supports 256 interrupt levels, the
|
|
XXX family only supports eight. RTEMS interrupt levels 0
|
|
through 7 directly correspond to XXX interrupt levels. All
|
|
other RTEMS interrupt levels are undefined and their behavior is
|
|
unpredictable.
|
|
|
|
@section Disabling of Interrupts by RTEMS
|
|
|
|
During the execution of directive calls, critical
|
|
sections of code may be executed. When these sections are
|
|
encountered, RTEMS disables interrupts to level seven (7) before
|
|
the execution of this section and restores them to the previous
|
|
level upon completion of the section. RTEMS has been optimized
|
|
to insure that interrupts are disabled for less than
|
|
RTEMS_MAXIMUM_DISABLE_PERIOD microseconds on a
|
|
RTEMS_MAXIMUM_DISABLE_PERIOD_MHZ Mhz XXX with
|
|
zero wait states. These numbers will vary based the
|
|
number of wait states and processor speed present on the target board.
|
|
[NOTE: The maximum period with interrupts disabled is hand calculated. This
|
|
calculation was last performed for Release
|
|
RTEMS_RELEASE_FOR_MAXIMUM_DISABLE_PERIOD.]
|
|
|
|
Non-maskable interrupts (NMI) cannot be disabled, and
|
|
ISRs which execute at this level MUST NEVER issue RTEMS system
|
|
calls. If a directive is invoked, unpredictable results may
|
|
occur due to the inability of RTEMS to protect its critical
|
|
sections. However, ISRs that make no system calls may safely
|
|
execute as non-maskable interrupts.
|
|
|
|
@section Interrupt Stack
|
|
|
|
RTEMS allocates the interrupt stack from the
|
|
Workspace Area. The amount of memory allocated for the
|
|
interrupt stack is determined by the interrupt_stack_size field
|
|
in the CPU Configuration Table. During the initialization
|
|
process, RTEMS will install its interrupt stack.
|
|
|
|
The XXX port of RTEMS supports a software managed
|
|
dedicated interrupt stack on those CPU models which do not
|
|
support a separate interrupt stack in hardware.
|
|
|
|
|