source: rtems/doc/user/fatal.t @ 20515fc

4.104.114.84.95
Last change on this file since 20515fc was 20515fc, checked in by Joel Sherrill <joel.sherrill@…>, on 03/27/98 at 18:53:17

Nodes, menus, etc are automatically generated now

  • Property mode set to 100644
File size: 5.1 KB
Line 
1@c
2@c  COPYRIGHT (c) 1988-1998.
3@c  On-Line Applications Research Corporation (OAR).
4@c  All rights reserved.
5@c
6@c  $Id$
7@c
8
9@chapter Fatal Error Manager
10
11@section Introduction
12
13The fatal error manager processes all fatal or
14irrecoverable errors.  The directive provided by the fatal error
15manager is:
16
17@itemize @bullet
18@item @code{@value{DIRPREFIX}fatal_error_occurred} - Invoke the fatal error handler
19@end itemize
20
21@section Background
22
23The fatal error manager is called upon detection of
24an irrecoverable error condition by either RTEMS or the
25application software.  Fatal errors can be detected from three
26sources:
27
28@itemize @bullet
29@item the executive (RTEMS)
30@item user system code
31@item user application code
32@end itemize
33
34RTEMS automatically invokes the fatal error manager
35upon detection of an error it considers to be fatal.  Similarly,
36the user should invoke the fatal error manager upon detection of
37a fatal error.
38
39Each status or dynamic user extension set may include
40a fatal error handler.  The fatal error handler in the static
41extension set can be used to provide access to debuggers and
42monitors which may be present on the target hardware.  If any
43user-supplied fatal error handlers are installed, the fatal
44error manager will invoke them.  If no user handlers are
45configured or if all the user handler return control to the
46fatal error manager, then the RTEMS default fatal error handler
47is invoked.  If the default fatal error handler is invoked, then
48the system state is marked as failed.
49
50Although the precise behavior of the default fatal
51error handler is processor specific, in general, it will disable
52all maskable interrupts, place the error code in a known
53processor dependent place (generally either on the stack or in a
54register), and halt the processor.  The precise actions of the
55RTEMS fatal error are discussed in the Default Fatal Error
56Processing chapter of the Applications Supplement document for
57a specific target processor.
58
59@section Operations
60
61@subsection Announcing a Fatal Error
62
63The @code{@value{DIRPREFIX}fatal_error_occurred} directive is invoked when a
64fatal error is detected.  Before invoking any user-supplied
65fatal error handlers or the RTEMS fatal error handler, the
66@code{@value{DIRPREFIX}fatal_error_occurred}
67directive stores useful information in the
68variable @code{_Internal_errors_What_happened}.  This @value{STRUCTURE}
69contains three pieces of information:
70
71@itemize @bullet
72@item the source of the error (API or executive core),
73
74@item whether the error was generated internally by the
75executive, and a
76
77@item a numeric code to indicate the error type.
78@end itemize
79
80The error type indicator is dependent on the source
81of the error and whether or not the error was internally
82generated by the executive.  If the error was generated
83from an API, then the error code will be of that API's
84error or status codes.  The status codes for the RTEMS
85API are in c/src/exec/rtems/headers/status.h.  Those
86for the POSIX API can be found in <errno.h>.
87
88The @code{@value{DIRPREFIX}fatal_error_occurred} directive is responsible
89for invoking an optional user-supplied fatal error handler
90and/or the RTEMS fatal error handler.  All fatal error handlers
91are passed an error code to describe the error detected.
92
93Occasionally, an application requires more
94sophisticated fatal error processing such as passing control to
95a debugger.  For these cases, a user-supplied fatal error
96handler can be specified in the RTEMS configuration table.  The
97User Extension Table field fatal contains the address of the
98fatal error handler to be executed when the
99@code{@value{DIRPREFIX}fatal_error_occurred}
100directive is called.  If the field is set to NULL or if the
101configured fatal error handler returns to the executive, then
102the default handler provided by RTEMS is executed.  This default
103handler will halt execution on the processor where the error
104occurred.
105
106@section Directives
107
108This section details the fatal error manager's
109directives.  A subsection is dedicated to each of this manager's
110directives and describes the calling sequence, related
111constants, usage, and status codes.
112
113@page
114@subsection FATAL_ERROR_OCCURRED - Invoke the fatal error handler
115
116@subheading CALLING SEQUENCE:
117
118@ifset is-C
119@example
120void volatile rtems_fatal_error_occurred(
121  rtems_unsigned32        the_error
122);
123@end example
124@end ifset
125
126@ifset is-Ada
127@example
128procedure Fatal_Error_Occurred (
129   The_Error : in     RTEMS.Unsigned32
130);
131@end example
132@end ifset
133
134@subheading DIRECTIVE STATUS CODES
135
136NONE
137
138@subheading DESCRIPTION:
139
140This directive processes fatal errors.  If the FATAL
141error extension is defined in the configuration table, then the
142user-defined error extension is called.  If configured and the
143provided FATAL error extension returns, then the RTEMS default
144error handler is invoked.  This directive can be invoked by
145RTEMS or by the user's application code including initialization
146tasks, other tasks, and ISRs.
147
148@subheading NOTES:
149
150This directive supports local operations only.
151
152Unless the user-defined error extension takes special
153actions such as restarting the calling task, this directive WILL
154NOT RETURN to the caller.
155
156The user-defined extension for this directive may
157wish to initiate a global shutdown.
Note: See TracBrowser for help on using the repository browser.