Table of Contents Previous Chapter
The Fatal Error class provides notification that an irrecoverable condition exists and controls an expeditious watchdog CPU reset.
Any of the processes or functions may use Fatal Error. Normally, requests for this service are a result of some function encountering a illegal value or condition.
Specifically it provides the following features:
Figure 1 illustrates the relationship between the classes used by Fatal Error.
FIGURE 129. Fatal Error Class Relationships
Fatal Error uses Devices, TlmFatal, and, Protocol, class categories.
IntrGuard - This class is used to prevent interrupts from interfering with FatalErrors activities.
TlmFatal - This class is responsible for insertion of the data into the packet and for initiating delivery of the panic message.
Watchdog - The Devices::Watchdog is responsible for resetting the hardware watchdog timer.
The FatalError.report() 1: may be called by any active process. It is delivered a value identifying the error encountered, and a second argument which provides further information. A call to FatalError.report() never returns.
FIGURE 130. Fatal Error Scenario
FatalError.report() invokes IntrGuard 2: which disables interrupts. Failure to complete the following steps will result in the watchdog reseting when its regular interval completes since the disabled interrupts will keep the taskMonitor() from touching() the watchdog.
report() 3: then delivers the information to the TlmFatal form using its' sendMessage() function which installs the arguments provided by the client, and hands it off to TlmManager.sendPanic() for delivery. sendPanic() must return for this procedure to continue.
It is TBD how the Fatal Error data is to be stored through CPU reset for echoing during the CPU start-up.
The Watchdog.forceReset() 4: is used to reset that device to a short interval, and then busy loops until the CPU is reset.
unsigned errorNum unsigned opInfo
Watchdoginterval to quickly reset the CPU.
Table of Contents Next Chapter