When debugging is complete, the system has been tested, and the application is ready for release, standard reporting status is enabled in the OIL configuration file. In standard status mode, most API services only return E_OK.
The OSEK/VDX standard defines two types of errors: application errors and fatal errors.
An application error occurs when an API service is unable to complete the service because the data or the OS state is invalid. The API service returns the error to the calling function and the service is not performed. Any values referenced by parameters that were passed as argu-ments to the service are undefined on return. A fatal error occurs when the API identifies that its internal data might be corrupted. In this case, the OS does not return to the calling func-tion; rather, it shuts itself down and returns to the function that called StartOS().
As with system startup and shutdown, the application can define a hook routine that is invoked after an application error is detected.
void ErrorHook(StatusType);
ErrorHook() is called at the end of an API service routine, and immediately before returning to the calling function, if the return is other than E_OK. It is also called if an error occurs when an alarm expires or a message is transmitted or received, although OSEK COM might call a differentErrorHook(), especially when mixing OS and COM modules from different vendors.
ErrorHook() is never called recursively.
For the application here, I have defined an ErrorHook() that keeps a running buffer of the last 10 errors identified by the system. The complete routine is shown in Listing 3.1 and has been added to a debug module found in debug.c.
Listing 3.1 ErrorHook().
The debug module is only included in the application during development. At this point, I store just the error value. In the future I will store additional information that is available from the system to assist in debugging the application. To allow for this future expansion, I have defined a structure that contains just one member of type StatusType. Additional mem-bers are added throughout the book.
3.2 Debugging Hook Routines
The OSEK/VDX OS standard defines two additional hook routines that are intended to be used by the application developer to support debugging.
void PreTaskHook(void);
void ErrorHook(StatusType error) {
nextErrorLog->error = error;
++nextErrorLog;
if(nextErrorLog > errorLog + sizeof(errorLog)){
nextErrorLog = errorLog;
} }
Example Program
31
void PostTaskHook(void);
PreTaskHook() is called by the OS after it has switched tasks but before passing control of the microcontroller to the new task. This allows the hook routine to query the OS and determine which task is about to run. PostTaskHook() is called after the OS determines that a switch is to occur, but before the switch actually occurs. Again this allows the hook routine to query the OS to determine which task has just completed or has been preempted.
Because these two hook routines are tied closely to tasks, I will forego development of the actual hook routines until I have covered tasks completely; however, I include the do-nothing tasks in the debug module along with ErrorHook().
The addition of these three hook routines requires that you update the OS object in the OIL file. The complete object definition is shown in Listing 3.2.
Listing 3.2 OS OIL definition.
3.3 Example Program
3.3.1 Modules
In this chapter, I only added one module to the example application — debug.c. All other modules are identical to the versions used in the Chapter 2.
debug.c This module contains all routines used by the application to assist in system run-time debugging. At this point, the module only has the three hook routines described in detail in this chapter. Additional debugging functions are added to this module in the exercises presented throughout the book.
/*************************************************************/
/* O/S */
/*************************************************************/
OS OSEKWorks_os { CC = AUTO;
STATUS = EXTENDED;
SCHEDULE = AUTO;
SYSTEMSTACKSIZE = 1024;
StartupHook = TRUE;
ErrorHook = TRUE;
ShutdownHook = TRUE;
PreTaskHook = TRUE;
PostTaskHook = TRUE;
};
32
Chapter 3: Development Support3.4 Exercise
1. Set a breakpoint at the entrance to each of the hook routines, including StartupHook(). Run the program and observe the sequence of events as the program starts and executes, then terminates, the background task.
3.5 Summary
This chapter introduced briefly how an OSEK/VDX OS processes errors and provides debug-ging capability. In Chapter 4, I will define the basic application building block — the task.
33
4
Chapter 4
Tasks
The first and most importing concept in the OSEK/VDX OS is the task. As you might remem-ber from the previous chapters, even the simplest application required defining a small task.
The task in the example program, a game of blackjack, was called background. It did abso-lutely nothing except terminate itself on startup; however, without it, the OS could not be built.
This chapter describes tasks as they relate to the OSEK/VDX OS. First I’ll discuss the overall task model and the attributes of an individual task. Next, I will discuss each of the interfaces of the OSEK/VDX API that relate to tasks. Finally, I will discuss the scheduling pol-icies of the OSEK/VDX OS.
4.1 Task Model
Tasks within the OSEK/VDX OS have a number of attributes that affect both the operation of the system and the size of the code. A task is either basic or extended, has a statically defined priority, might or might not be preemptive, and might be able to suspend execution while waiting for an event. The combination of these and other attributes creates a conform-ance class, as defined in the OSEK/VDX specification. Each of these attributes and the defini-tion of conformance classes are discussed in this secdefini-tion.