Embedded Systems Design - July 2008 - (Page 41)

20 years ago Recovery from an exception without disruption of the entire system can be academic when the code and concepts required to recover from a fatal fault are more complex than the code that generated the fault. If non-disruptive recovery is essential, the system engineer should evaluate how the system will be implemented and decide which run-time environment and language should be used. Ada, with its many run-time resources for handling exceptions, is often the best language for systems that require a high degree of fault tolerance. Fault recovery can be built into multitasking systems. When the exception handler is invoked, it determines whether a complete system restart or simply a ﬂush and restart of the task that raised the exception is needed. In the latter case, if any outstanding operatingsystem resources (such as memory partitions) need to be reclaimed, a handler must be invoked to dean them up and return them to the operating system. This is normally handled by a procedure associated with each task that can be restarted. The procedure knows which resources may need reclaiming and how to check the task’s internal structures to determine the resources in use at the time of the exception. Once the resources have been reclaimed, the task’s data structures need to be reinitialized to a known state (typically the cold-start condition) and the task restarted. One remaining issue is the interaction and synchronization with other tasks in the system. Since these tasks weren’t restarted and are unaware of the faulted task’s restart, they could be waiting on that task for processing that was in progress when the exception occurred. One way to handle this problem is to issue a global fault message alerting the other tasks of the restart and asking that any requests being processed by that task be restarted as well. Our exception handler could be improved by assigning priorities to the exception or classes of exceptions. If we assume that the exception is a long (32-bit) integer, we can deﬁne a crash code as follows: typedef struct { char class; char pri; short fault; } SYS_EXCEPTION; Since SYS_EXCEPTION can be treated as a long integer, it can still be passed to functions as in our original example. The class ﬁeld could be used to determine the type of exception that has occurred: either a report-only, an explicit hard-boot fault, or an exception to be handled based on its priority. The pri ﬁeld, on the other hand, can be used to provide dynamic exception-handling characteristics. Upon fault, a master current exception priority ﬁeld (a global variable set by the user or www.embedded.com | embedded systems design | JULY 2008 41 http://www.lauterbach.com http://www.lauterbach.de http://www.lauterbach.co.uk http://www.lauterbach.it http://www.lauterbach.cn http://www.lauterbach.jp http://www.lauterbach.com http://www.embedded.com

Table of Contents Feed for the Digital Edition of Embedded Systems Design - July 2008

Embedded Systems Design - July 2008 Contents #Include Parity Bit Programming Pointers Interactive C-code Cleaning Tool Supports Multiprocessor SoC Design Building a Power Supply for Discontinuous Transmission Wireless Networks An Exception Primer Advertising Index Break Points Marketplace

Embedded Systems Design - July 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.