Most developers are somewhat familiar with the notion of exception handling. Software is rarely implemented with perfect hardware in a perfect environment, and the possibility of an anomalous event or error condition has to be considered. Exception handling in embedded applications is often vitally important; a confused processor can generate expensive and even life-threatening results. Having a program give up and post an Abort, Retry, Fail? message is rarely an acceptable option in avionics or medical applications.

The way exceptional conditions are handled depends on the supporting software. In general, the exception handler is an operating-system resource. In a UNIX environment, for example, an error during a program's execution (such as an invalid memory access) will cause the operating system to generate a core file that's written to the disk, then halt program execution.

That's simple exception handling: a fault is recognized, a file is generated to indicate the system state at the time of the fault, the process is killed, and the operating system returns to the user prompt. The operator is then expected to take appropriate action, such as determining the cause of the error and re-executing the program.

In contrast to the UNIX scenario, embedded systems call for sophisticated exception handling techniques. Embedded usually implies that the system performs a known, defined function in the real world. The operating personnel will likely be untrained in computer engineering, or perhaps not even present. As a result, the system must be able to resolve the anomalous condition and continue operation.

An exceptional methodology
The first step in any exception-handling scheme is to define what will constitute an exception. The definition depends largely on whether the underlying operating system is a simple monitor, a kernel such as VRTX or pSOS, or a full-blown operating system such as UNIX.

The existing software foundation will influence your design a great deal, as monitors and kernels generally provide no error handling at all other than reporting that an error occurred during a system call. UNIX, on the other hand, provides a rich set of tools through which complex error-handling systems can be built. When a serious fault occurs, the state of the system is written to the disk in the form of a core file and signals are sent to parent processes to alert them to the error condition.

As comfortable as the UNIX tools may be, the most common environments for embedded applications are kernels and monitors. Accordingly, the examples here are for a kernel-based system.

The exception handler
An exception is, by definition, an anomalous condition. In practice, this term covers a wide variety of sins. Let's say a message is posted to a message queue through a kernel call. If it's posted successfully, the kernel returns a message to the caller that no error occurred. But what if the message queue is full or the request specifies a nonexistent message queue? Exceptions aren't limited to kernel calls; they can be defaults at the end of a case statement (to represent an invalid parameter) or other program flow-type problem.

One simple approach to exception handling is to establish a rigorous methodology at the beginning of the project. A central handler can easily be used throughout the system, as represented by the following pseudocode:

err = system_operation();
if( err ) sys_fault();
else
{
  normal_processing();
}

This simple example demonstrates a consistent approach for checking and handling anomalous conditions. Wherever an unrecoverable error could exist, a check is made. If an error occurs, the system-wide exception handler is called.

From this basic method we can build a system in which each exception is assigned a unique error code to identify the line that caused the exception. Using the exception handler is as simple as a normal function call:

sys_fault( SYS_CRASH_001, err );

The field SYS_CRASH_001 is a unique number within the system and forms a unique exception ID (a long integer, in this example). Implementers of a project can build a central file, similar to the following, listing exception IDs and keep track of their use in the system:

/* qpost, sys_chk_msg() */
#define SYS_CRASH_001 0x0001
/* bad indx, sys_prcs_msg() */
#define SYS_CRASH_002 0x0002
/* qpend, sys_snd_msg() */
#define SYS_CRASH_003 0x0003

The err field represents additional information that the user desires to pass to the exception handler; for kernel errors, this could be the error returned from the kernel call. For software flow errors, such as the default of a case, it could be the value used in the case.

The methodology defined thus far offers the following:

• A consistent approach to invoking exceptions.

• The ability to identify (through the ID code) the exact line of code that caused the exception condition.

• A single hook--in this case, sys_ fault()--through which all exceptions pass, enabling us to change the way exceptions are handled in one central procedure.

The actual exception processing can be approached in several ways. During the debug and implementation phases, the programmer needs to know what exception occurred and be able to examine the state of the system at the exact moment the exception occurred. The best way to do this is to print a crash report that gives the exception condition, then freeze the system by returning to the debugger/monitor.

After the project has been completed and shipped to the field, it's usually highly undesirable for the system to freeze when an exception occurs. Exceptions in a production mode may best be handled by recording the exception and automatically restarting the system (advanced exception handling is discussed later). The crash report can subsequently be retrieved to determine the cause of the exception.