HC12 Os

OSEK Operating System
Rev. 1.2
R E Q U I R E D
HC12
OSEK
A G R E E M E N T
Operating System
User’s Manual
Rev. 1.2
N O N - D I S C L O S U R E
May 19, 1999
User’s Manual
R E Q U I R E D
A G R E E M E N T
Motorola reserves the right to make changes without further notice to

any products herein to improve reliability, function or design. Motorola
does not assume any liability arising out of the application or use of any
product or circuit described herein; neither does it convey any license
under its patent rights nor the rights of others. Motorola products are not
designed, intended, or authorized for use as components in systems
intended for surgical implant into the body, or other applications intended
to support or sustain life, or for any other application in which the failure
of the Motorola product could create a situation where personal injury or
death may occur. Should Buyer purchase or use Motorola products for
any such unintended or unauthorized application, Buyer shall indemnify
and hold Motorola and its officers, employees, subsidiaries, affiliates,
and distributors harmless against all claims, costs, damages, and
expenses, and reasonable attorney fees arising out of, directly or
indirectly, any claim of personal injury or death associated with such
unintended or unauthorized use, even if such claim alleges that Motorola
was negligent regarding the design or manufacture of the part. Motorola
and are registered trademarks of Motorola, Inc. Motorola, Inc. is an
Equal Employment Opportunity/Affirmative Action Employer.
Copyright © 1999 Motorola, Inc. All Rights Reserved
User’s Manual MC68HC(7)05H12 — Rev. 1.2
2 MOTOROLA
R E Q U I R E D
Legal Notices
iii
The information in this document has been carefully checked and is
believed to be entirely reliable, however, no responsibility is assumed for
inaccuracies. Furthermore, Motorola reserves the right to make changes
to any products herein to improve reliability, function or design. Motorola
does not assume liability arising out of the application or use of any
product or circuit described herein; neither does it convey any license
under its patent rights or the rights of others.
A G R E E M E N T
The software described in this document is furnished under a license
agreement. The software may be used or copied only in accordance with
the terms of the agreement.
Copyright © 1999 Motorola, Inc. All Rights Reserved
No part of this publication may be reproduced or transmitted in any form

or by any means - graphic, electronic, electrical, mechanical, chemical,
including photocopying, recording in any medium, taping, by any
computer or information storage retrieval systems, etc., without prior
permissions in writing from Motorola Inc.
Permission is granted to reproduce and transmit the Problem Report

Form, the Customer Satisfaction Survey, and the Registration Form to
Motorola.
IMPORTANT NOTICE TO USERS
While every effort has been made to ensure the accuracy of all
information in this document, Motorola assumes no liability to any party
for any loss or damage caused by errors or omissions or by statements
of any kind in this document, its updates, supplements, or special
editions, whether such errors are omissions or statements resulting from
negligence, accident, or any other cause. Motorola further assumes no
liability arising out of the application or use of any product or system
described herein; nor any liability for incidental or consequential
damages arising from the use of this document. Motorola disclaims all
warranties regarding the information contained herein, whether
expressed, implied or statutory, including implied warranties of
merchantability or fitness for a particular purpose.
OSEK Operating System — Rev 1.2 User’s Manual
MOTOROLA Legal Notices 3

Legal Notices
R E Q U I R E D
TRADEMARKS
Microsoft, MS-DOS and Windows are trademarks of Microsoft.
UNIX is a trademark of AT&T Bell Laboratories.

A G R E E M E N T
User’s Manual OSEK Operating System — Rev 1.2
4 Legal Notices MOTOROLA

R E Q U I R E D
User’s Manual — OSEK Operating System
Table of Contents
Section 1. Overview
Section 2. Notation
A G R E E M E N T
2.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2 Manual Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Definitions, Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 27
2.5 Installation Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.1 Required Environment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.6 Technical Support Information . . . . . . . . . . . . . . . . . . . . . . . . . 29
Section 3. Operating System Architecture

3.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.2 Processing Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 Conformance Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 OSEK OS Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Application Program Interface . . . . . . . . . . . . . . . . . . . . . . . . . 37
Section 4. Task Management

4.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2 Task Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.3 Task State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.1 Extended Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.3.2 Basic Tasks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.4 Task Activation and Termination . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Task Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
MOTOROLA Table of Contents 5

Table of Contents
R E Q U I R E D
4.6 Task Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.7 Task Related Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.1 Task Configuration Table . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.7.2 Task Control Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.7.2.1 Persistent Node Assignment . . . . . . . . . . . . . . . . . . . . . . 52
4.7.3 Task Link Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.7.4 Task Stack. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7.4.1 Stack Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7.5 Allocation of Fixed Stack Linked with the Task Node . . . . . 56
4.7.5.1 Dynamic Stack Allocation from the Stack Pool . . . . . . . . 57
A G R E E M E N T
4.7.5.2 Persistent Stack Allocation from the Stack Pool . . . . . . . 57

4.7.5.3 Explicit Stack Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.7.5.4 Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.8 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.8.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.8.3 Task Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.8.4 Run-time Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.8.5 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.8.6 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
Section 5. Scheduler
5.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.2.1 Simple Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.1 Non-preemptive Scheduling . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.2 Full-preemptive Scheduling. . . . . . . . . . . . . . . . . . . . . . . . . 68
5.3.3 Mixed-preemptive Scheduling . . . . . . . . . . . . . . . . . . . . . . . 69
5.4.3 Scheduler Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Section 6. Interrupt Processing

6.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Table of Contents MOTOROLA

Table of Contents
R E Q U I R E D
6.3 ISR Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 ISR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.1 ISR Category 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.2 ISR Category 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.4.3 ISR Category 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.5 Interrupt Flag Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Local Variables Considerations . . . . . . . . . . . . . . . . . . . . . . . . 78
A G R E E M E N T
6.7.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.7.4 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.7.5 ISR Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.7.6 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Section 7. Resource Management

7.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.3 Access to Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3.1 Priority Ceiling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.3.2 Scheduler as a Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.4.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.4.4 Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Section 8. Counters and Alarms

8.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.3 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.4 Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.5.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .100

Table of Contents
R E Q U I R E D
8.5.3 Counters and Alarm Generation . . . . . . . . . . . . . . . . . . . .101

8.5.4 Run-time Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .102
8.5.5 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .103
Section 9. Events
9.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
9.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
9.3 Events and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
9.4 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
A G R E E M E N T
9.4.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

9.4.2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
9.4.3 Events Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
9.4.5 Additional Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .109
Section 10. Communication

10.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
10.2 Message Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
10.3 Unqueued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
10.4 Queued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115

10.5.2 Identifiers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .117
10.5.3 Message Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .118
10.5.5 Usage of Messages. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .119
Section 11. Error Handling and Special Routines

11.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.3 Hook Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.4 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
11.4.1 Error Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
11.4.2 Extended Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127

Table of Contents
R E Q U I R E D
11.4.3 Possible Error Reasons. . . . . . . . . . . . . . . . . . . . . . . . . . .128
11.5 Start-up Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
11.6 Application Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
11.7 System Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
Section 12. System Configuration

12.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
A G R E E M E N T
12.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
12.3 Application Configuration File . . . . . . . . . . . . . . . . . . . . . . . . .134
12.4 OIL Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
12.4.1 OIL File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
12.4.2 Standard OIL Format. . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
12.4.3 Extended OIL Format . . . . . . . . . . . . . . . . . . . . . . . . . . . .135
12.4.4 Implementation Definition . . . . . . . . . . . . . . . . . . . . . . . . .135
12.4.4.1 Implementation Definition Grammar . . . . . . . . . . . . . . .136
12.4.5 Application Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
12.4.5.1 Object Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .138
12.4.5.2 Include Directive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
12.4.5.3 Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
12.4.5.4 File Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .139
12.4.6 Configuration File Rules . . . . . . . . . . . . . . . . . . . . . . . . . .140
Section 13. System Objects Definition

13.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
13.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
13.3 OS Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
13.3.1 Global System Attributes. . . . . . . . . . . . . . . . . . . . . . . . . .142
13.3.2 Task Related Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . .147
13.3.3 Interrupt Related Properties . . . . . . . . . . . . . . . . . . . . . . .149
13.3.4 Resources and Events Related Attributes. . . . . . . . . . . . .151
13.3.5 Counters and Alarms Related Attributes . . . . . . . . . . . . . .152
13.3.6 Messages Related Attributes . . . . . . . . . . . . . . . . . . . . . .153
13.3.7 Hook Routines Related Attributes . . . . . . . . . . . . . . . . . . .154
13.3.8 OS Service Related Attributes. . . . . . . . . . . . . . . . . . . . . .155

Table of Contents
R E Q U I R E D
13.4 Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156

13.4.1 Object Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
13.4.2 Object References. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .158
13.5 Stack Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
13.6 Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
13.7 Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
A G R E E M E N T
13.8 Counter Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

13.9 Alarm Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
13.10 Message Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
13.11 ISR Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
13.12 Different Application Modes Definition . . . . . . . . . . . . . . . . . .168
Section 14. Building of Application

14.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
14.2 Application Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
14.3 Action Sequence to Build an Application . . . . . . . . . . . . . . . .172
14.3.1 Application Configuration . . . . . . . . . . . . . . . . . . . . . . . . .173
14.3.2 Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .175
14.3.3 Compiling and Linking . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
14.4 Sample Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
Section 15. HC12 Platform-Specific Features

15.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .179
15.2 Compiler-Specific Features . . . . . . . . . . . . . . . . . . . . . . . . . .179
15.2.1 OSEK OS Environment Variables . . . . . . . . . . . . . . . . . . .179

Table of Contents
R E Q U I R E D
15.2.2 Cosmic Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .180
15.3 Interrupt Flag Manipulation Specific Features . . . . . . . . . . . .180
15.4 HC12 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
15.4.1 Base Page Memory Usage . . . . . . . . . . . . . . . . . . . . . . . .182
15.4.1.1 Mapping RAM and REGISTERS . . . . . . . . . . . . . . . . . .182
15.4.2 Interrupt Vector Table . . . . . . . . . . . . . . . . . . . . . . . . . . . .183
15.4.3 The Banked Memory Model Support. . . . . . . . . . . . . . . . .184
15.4.3.1 Banked Memory Model Overview . . . . . . . . . . . . . . . . .184
15.4.3.2 Configuration of the Application for Banked Memory. . .185
15.4.3.3 Cosmic Compiler Issue . . . . . . . . . . . . . . . . . . . . . . . . .186
A G R E E M E N T
15.4.4 Recommendations on System Properties . . . . . . . . . . . . .187
15.4.4.1 UseMainStack property . . . . . . . . . . . . . . . . . . . . . . . . .187
15.4.4.2 UseSameContext Property . . . . . . . . . . . . . . . . . . . . . .187
15.4.4.3 InterruptMaskControl Property . . . . . . . . . . . . . . . . . . . .187
15.4.4.4 CounterSize Property. . . . . . . . . . . . . . . . . . . . . . . . . . .188
15.4.4.5 Unused Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .188
15.4.5 System Timer Hardware . . . . . . . . . . . . . . . . . . . . . . . . . .188
15.4.6 Scheduler Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . .191
15.4.7 Alarms Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . .191
15.5 Task Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
Section 16. Application Troubleshooting

16.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
16.2 System Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
16.3 Using OS Extended Status for Debugging . . . . . . . . . . . . . . .193
16.4 Context Switch Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
16.5 Stack Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
16.6 Known Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
Section 17. System Services

17.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
17.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
17.3 Task Management Services . . . . . . . . . . . . . . . . . . . . . . . . . .199
17.3.1 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
17.3.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .199
17.3.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

Table of Contents
R E Q U I R E D
17.3.4 Task Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

17.3.5 ActivateTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .201
17.3.6 TerminateTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .202
17.3.7 ChainTask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .203
17.3.8 Schedule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .204
17.3.9 GetTaskId . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .205
17.3.10 GetTaskState . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .206
17.3.11 GetTCBInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .207
17.3.12 Examples for Task Management Services . . . . . . . . . . . .208
A G R E E M E N T
17.4 ISR Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . .210

17.4.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .210
17.4.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
17.4.3 Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
17.4.4 EnterISR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .211
17.4.5 LeaveISR. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .213
17.4.6 EnableInterrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .214
17.4.7 DisableInterrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .216
17.4.8 GetInterruptDescriptor. . . . . . . . . . . . . . . . . . . . . . . . . . . .217
17.4.9 Examples for Interrupt Management Services . . . . . . . . .218
17.5 Resource Management Services . . . . . . . . . . . . . . . . . . . . . .220
17.5.1 Data types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
17.5.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .220
17.5.3 Resource Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . .221

17.5.4 GetResource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .221
17.5.5 ReleaseResource . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .223
17.5.6 Examples of Using Resources . . . . . . . . . . . . . . . . . . . . .224
17.6 Counters and Alarms Management Services . . . . . . . . . . . . .225
17.6.1 Data Types and Identifiers . . . . . . . . . . . . . . . . . . . . . . . .225
17.6.2 Constants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .226
17.6.3 Counter and Alarm Declaration . . . . . . . . . . . . . . . . . . . . .227
17.6.3.1 Counter Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . .227
17.6.3.2 Alarm Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
17.6.4 InitCounter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .228
17.6.5 CounterTrigger . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .229
17.6.6 AdvanceCounter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .230
17.6.7 GetCounterValue. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .231
17.6.8 GetCounterInfo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .232
17.6.9 SetRelAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .233

Table of Contents
R E Q U I R E D
17.6.10 SetAbsAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .235
17.6.11 CancelAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .236
17.6.12 GetAlarmBase . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .237
17.6.13 GetAlarm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .238
17.6.14 Examples for Counter and Alarm Management . . . . . . . .239
17.7 Event Management Services . . . . . . . . . . . . . . . . . . . . . . . . .242
17.7.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
17.7.2 Event Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .242
17.7.3 SetEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .243
17.7.4 ClearEvent. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .244
A G R E E M E N T
17.7.5 GetEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .245
17.7.6 WaitEvent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .246
17.7.7 Examples of Using Events . . . . . . . . . . . . . . . . . . . . . . . .247
17.8 Communication Management Services . . . . . . . . . . . . . . . . .249
17.8.1 Data Types and Identifiers . . . . . . . . . . . . . . . . . . . . . . . .249
17.8.2 SendMessage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .250
17.8.3 ReceiveMessage. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .252
17.8.4 GetMessageResource. . . . . . . . . . . . . . . . . . . . . . . . . . . .253
17.8.5 ReleaseMessageResource . . . . . . . . . . . . . . . . . . . . . . . .254
17.8.6 GetMessageStatus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .255
17.8.7 Examples of Using Messages . . . . . . . . . . . . . . . . . . . . . .256
17.9 Operating System Execution Control . . . . . . . . . . . . . . . . . . .259
17.9.1 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .259
17.9.2 GetActiveApplicationMode . . . . . . . . . . . . . . . . . . . . . . . .259
17.9.3 StartOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
17.9.4 ShutdownOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .260
17.9.5 Examples of Application Modes Usage. . . . . . . . . . . . . . .261
17.9.6 Hook Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
17.9.6.1 ErrorHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .264
17.9.6.2 PreTaskHook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .265
17.9.6.3 PostTaskHook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
17.9.6.4 IdleLoopHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .266
17.9.6.5 StartupHook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .267
17.9.6.6 ShutdownHook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .268
Section 18. ORTI Implementation

18.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269

Table of Contents
R E Q U I R E D
18.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269

18.3 ORTI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.3.1 ORTI Trace Interfaces. . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.3.2 ORTI Breakpoint Interface. . . . . . . . . . . . . . . . . . . . . . . . .273
18.4 ORTI Supporting OS Properties . . . . . . . . . . . . . . . . . . . . . . .274
18.5 ORTI Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
Appendix A. Sample Application

A G R E E M E N T
A.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279

A.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
A.3 Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
Appendix B. System Service Timing

B.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
B.2 General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
Appendix C. Memory Requirements

C.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .289
C.2 Memory for the OSEK Operating System. . . . . . . . . . . . . . . .289
C.3 Data Sheet for the Cosmic . . . . . . . . . . . . . . . . . . . . . . . . . . .292
Appendix D. System Generation Error Messages

D.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.2 Error Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.3 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.4 Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
Appendix E. Quick Reference

E.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
E.2 System Services Quick Reference . . . . . . . . . . . . . . . . . . . . .319
E.3 OIL language Quick Reference . . . . . . . . . . . . . . . . . . . . . . .325
E.3.1 OS Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326

Table of Contents
R E Q U I R E D
E.3.2 TASK Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
E.3.3 ISR Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E.3.4 STACK Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E.3.5 RESOURCE Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
E.3.6 ALARM Object. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348
E.3.7 COUNTER Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E.3.8 MESSAGE Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E.3.9 EVENT Object . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
User’s Manual Index
A G R E E M E N T

Table of Contents
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
List of Figures
Figure Title Page
3-1 Restricted upward compatibility for conformance classes . . 33

4-1 Task status model of an Extended Task with its task
transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
A G R E E M E N T
4-2 Task status model with task transitions for Basic Tasks . . . 44
4-3 Task management architecture . . . . . . . . . . . . . . . . . . . . . . 46
4-4 Task priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4-5 Persistent task node assignment . . . . . . . . . . . . . . . . . . . . . 53
4-6 Task link table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4-7 Fixed stack linked with the task node. . . . . . . . . . . . . . . . . . 56
4-8 Dynamic stack allocation from the stack pool . . . . . . . . . . . 57
4-9 Persistent stack allocation from the stack pool . . . . . . . . . . 58
4-10 Static stack allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5-1 Non-preemptive scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 68
5-2 Full-preemptive scheduling . . . . . . . . . . . . . . . . . . . . . . . . . 69
7-1 Priority Ceiling Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
8-1 Counters and alarms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8-2 Two cases for the absolute alarm . . . . . . . . . . . . . . . . . . . . 98
9-1 Synchronization by events in case of full-preemptive
scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .107
9-2 Synchronization by events in case of full-preemptive
scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .108
10-1 Operations with Queued Messages . . . . . . . . . . . . . . . . . .116
11-1 System startup in the OSEK OS . . . . . . . . . . . . . . . . . . . .129
14-1 Application building process. . . . . . . . . . . . . . . . . . . . . . . .173
15-1 Banked Memory Model . . . . . . . . . . . . . . . . . . . . . . . . . . .185
18-1 Application Building Process with ORTI Support . . . . . . . .270
MOTOROLA List of Figures 17

List of Figures
R E Q U I R E D
A G R E E M E N T
18 List of Figures MOTOROLA

R E Q U I R E D
List of Tables
Figure Title Page
3-1 OSEK OS Conformance Classes . . . . . . . . . . . . . . . . . . . . . . 34

3-2 OSEK OS maximal system resources . . . . . . . . . . . . . . . . . . 35
4-1 States and status transitions in the case of Extended Tasks . 42
A G R E E M E N T
4-2 States and status transitions in the case of Basic Tasks . . . . 43
4-3 Task Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4-4 Task Management Run-time Services . . . . . . . . . . . . . . . . . . 62
6-1 Interrupt Management Services in the OSEK OS . . . . . . . . . 81
8-1 Counter and Alarm Management Run-time Services . . . . . .102
9-1 Event Management Run-time Services . . . . . . . . . . . . . . . .109
10-1 Features of the Message Concept . . . . . . . . . . . . . . . . . . . .113
10-2 Task Management Run-time Services . . . . . . . . . . . . . . . . .119
11-1 OSEK OS system services for hook routines . . . . . . . . . . . .124
11-2 OSEK OS Error codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . .127
14-1 System Generator command line options . . . . . . . . . . . . . .174
15-1 Parameters to define System Timer hardware . . . . . . . . . . .189
18-1 ORTI Generator Command Line Options . . . . . . . . . . . . . . .276
B-1 OSEKOS_20 version of the Operating System run-time services
timing characteristics (HC12D60, Cosmic software) . . . . . .285
C-1 OSEKOS_20 version of the Operating System memory
requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .292
E-1 OSEK OS services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .319
E-2 Data Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .322
E-3 Constructional elements . . . . . . . . . . . . . . . . . . . . . . . . . . . .323
E-4 OSEK Operating System run-time services return values
and error values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .324
E-5 OSEK Operating System constants . . . . . . . . . . . . . . . . . . .325
E-6 OS Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .326
E-7 TASK Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .345
E-8 ISR Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E-9 STACK Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .347
E-10 RESOURCE Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . .348
MOTOROLA List of Tables 19

List of Tables
R E Q U I R E D
E-11 ALARM Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .348

E-12 COUNTER Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E-13 MESSAGE Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . .349
E-14 EVENT Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .351
A G R E E M E N T
20 List of Tables MOTOROLA

R E Q U I R E D
Section 1. Overview
OSEK1 Operating System (OSEK OS) is a real-time operating system

which conforms to the specification of the OSEK/VDX Operating System
version 2.0, revision 1, 15 October 1997.
A G R E E M E N T
OSEK OS conforms to the following requirements:
• OS is fully configured and statically scaled;

• OSEK OS is a ROM-able system, i.e. the OS code may be
executed from Read-Only-Memory. OSEK OS may be placed into
chip memory during manufacture, and users’ applications may be
added during development time;
• OS performance parameters are well known;
• Being written in strict correspondence with ANSI C standard, the
OS and application on its basis can be easily ported from one
platform to another.
A wide range of scalability, a set of system services, various scheduling
mechanisms, and convenient configuration features make the OSEK
Operating System feasible for a broad spectrum of applications and
hardware platforms.
The OSEK OS provides a pool of different services and processing

mechanisms for task management and synchronization, data exchange,
resource management, and interrupt handling. The following features
are granted to the user:
1. The term OSEK means ‘Offene Systeme und deren Schnittstellen fur die Elektronik im Kraft-
fahrzeug’ (Open systems and the corresponding interfaces for automotive electronics). A real-
time operating system, software interfaces and functions for communication and network man-
agement tasks are thus jointly specified within the OSEK standard.
MOTOROLA Overview 21
Overview
R E Q U I R E D
Task Management
• Activation and termination of tasks;

• Management of task states, task switch.
Scheduling Policies
• Full-, non-, and mixed-preemptive scheduling techniques.
Event Control
A G R E E M E N T
• Event Control for task synchronization.
Interrupt Management
• Services for hardware interrupt flag manipulations;

• Frames for interrupt service routines.
Resource Management
• Mutually exclusive access control for inseparable operations to

jointly used resources or devices, or for control of a program flow.
Communication1
• Unqueued Message: Data exchange without buffering;

• Queued Message: Data exchange with buffering.
Counter2 and alarm management
• Counter management provides services for execution of recurring

events;
• Alarm management is based on counter management. It enables
entry of (cyclic) alarm requests. The expiration of a preset relative
counter value, or the fact that a preset absolute counter value is
reached, results in activation of a task, or setting of a task event.
1. Communication part of OSEK Operating System conforms the specification of the OSEK Com-
munication System, version 2.1, revision 1, 17 June 1998.
2. Counter Management part of OSEK Operating System conforms the specification of the OSEK
Operating System Application Program Interface version 1.00, 11 September 1995.
22 Overview MOTOROLA
Overview
R E Q U I R E D
Error treatment
• Mechanism supporting the user in various error classes.
ORTI Subsystem
• ORTI provides interface to Operating System run-time data for

“OSEK aware” debuggers.
OSEK Operating System is scaled in two ways – either by changing the

set of system services or via the so-called Conformance Classes. They
are available to satisfy different requirements concerning functionality
A G R E E M E N T
and capability of the OS. These Conformance Classes do not only differ
concerning the number of services they provide, but also with regard to
their capabilities and scalability. The classes are based on one another
in upwardly compatible fashion. The Conformance Classes are
generated by meaningful grouping of services (see
Section 3.3 Conformance Classes).
The OSEK OS is built according to the user’s configuration instructions

at system generation time. Both system and application parameters are
configured statically. Therefore, a special tool called the System
Generator is used for this purpose. Special statements are designed to
tune any parameter. The user must only edit the definition file, run
System Generator and then assemble resulting files with application
files. Thus, the user can adapt the Operating System to the control task
and the target hardware. OS cannot be modified later at execution time.
OSEK Operating System is well documented and measured. In the

User’s Manual, all system mechanisms, particularities, services and
programming techniques are described in detail with numerous
examples. Numbers for performance characteristics and memory
requirements are provided.
MOTOROLA Overview 23
Overview
R E Q U I R E D
A G R E E M E N T
24 Overview MOTOROLA
R E Q U I R E D
Section 2. Notation
2.1 Contents
2.2 Manual Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
A G R E E M E N T
2.3 Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.4 Definitions, Acronyms and Abbreviations . . . . . . . . . . . . . . . . . 27
2.5 Installation Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.6 Technical Support Information . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Manual Structure

This User’s Manual consists of the following sections:
Section 1 Overview describes what the OSEK OS is and highlights its

basic features.
Section 2 Notation contains a description of the Manual structure,
typographical conventions and the list of acronyms.
Section 3 Operating System Architecture gives a high level

description of OS architecture and presents OS Conformance Classes.
Section 4 Task Management explains the task concept in OSEK and

all other questions related to tasks.
Section 5 Scheduler provides a description of scheduling policies in

OSEK OS.
Section 6 Interrupt Processing highlights the OSEK approach to

interrupt handling.
Section 7 Resource Management describes resource management

and task coordination by resources.
MOTOROLA Notation 25
Notation
R E Q U I R E D
Section 8 Counters and Alarms describes usage of these control

mechanisms in OSEK OS.
Section 9 Events is devoted to event management and task

coordination by events.
Section 10 Communication describes message concept in OSEK and

their usage.
Section 11 Error Handling and Special Routines describes support

provided to the user to debug an application and handle errors.
A G R E E M E N T
Section 12 System Configuration describes possible OSEK OS

versions, configuration options and the configuration mechanism.
Section 14 Building of Application contains information on how to

build an user’s application using OSEK OS. It also describes memory
requirements.
Section 15 HC12 Platform-Specific Features discusses special

OSEK OS features for different MCU types and issues connected with
porting applications to these MCUs.
Section 16 Application Troubleshooting contains useful information

for debugging applications developed using OSEK OS.
Section 17 System Services provides a detailed description for all

OSEK Operating System run-time services, with appropriate examples.
Section 18 ORTI Implementation provides information about

preparation all data needed for OSEK aware debugger to display
information about application in OSEK terms.
Appendix A Sample Application contains the text and listing of a

sample customer application developed using OSEK OS.
Appendix B System Service Timing provides information about OS

services execution time.
Appendix C Memory Requirements provides information about the

amount of ROM and RAM directly used by various versions of the OSEK
OS.
26 Notation MOTOROLA
Notation
Typographical Conventions
R E Q U I R E D
Appendix D System Generation Error Messages explains OSEK OS
System Generator error messages.
Appendix E Quick Reference briefly lists all OSEK OS run-time

services, with entry and exit conditions.
2.3 Typographical Conventions

This manual employs the following typographical conventions:
A G R E E M E N T
boldface type
Bold is used for important terms, notes and warnings.
Italics
Italics are used for all OSEK names of directives, macros,
constants, routines and variables.
Courier font
Courier typeface is used for code examples in the text.
Courier Italic
Courier Italic typeface is used for OSEK terms when these are
first introduced.
2.4 Definitions, Acronyms and Abbreviations
API Application Program Interface (a set of data types and functions)
Basic Conformance Class, a defined set of functionality in OSEK, for

BCC
which the waiting state of tasks is not permitted
BT Basic task (task, which never has the waiting state)
CPU Central Processor Unit
Extended Conformance Class, a defined set of functionality in

ECC
OSEK, for which the waiting state of tasks is permitted
ECU Electronic Control Unit (similar to MCU)
ET Extended Task (task, which may have the waiting state)
Notation
R E Q U I R E D
ID Identifier, an abstract identifier of a system object
Interrupt Stack Frame, a stacked model of CPU registers, produced

ISF
by CPU hardware and/or software instructions during CPU interrupt
ISR Interrupt Service Routine
MCU Microcontroller Unit (Motorola’s microcontrollers)
MO Message object
N/A Not applicable
OIL OSEK Implementation Language

A G R E E M E N T
ORTI OSEK Run Time Interface
OrtiGen ORTI Generator Utility
OS Operating System, a part of the OSEK
Open systems and their corresponding interfaces for automotive

OSEK
electronics (in German)
Implementation of the OSEK OS according to "OSEK/VDX Operat-

OSEKOS_20
ing System", Version 2.0 Revision 1, 15 October 1997
RAM Random Access Memory
ROM Read Only Memory
SG, SysGen System Generator

2.5 Installation Instructions
2.5.1 Required Environment
This version of the product is to be used on an IBM PC 486 (and higher)

compatible. To install and evaluate the product, you require
approximately 4 MB of hard disk space.
The PC must work under MS Windows 95 or Windows NT 4.0 during

OSEK installation.
To use OSEK OS after installation install the Cross Compiler on your

computer (See Section 15 for more information). You must call the DOS
prompt under Windows NT to run the NMAKE utility.
All supplied makefiles are developed for the Microsoft C++ NMAKE
utility.
Notation
Technical Support Information
R E Q U I R E D
2.5.2 Installation
To setup OSEK OS on your hard drive:
1. Insert the installation disk into a 3.5” floppy drive. The following
instructions assume that the drive letter is a:. If another drive is
chosen, substitute that drive letter where appropriate.
2. Run the A:\SETUP.EXE program either from the File Manager or
Program Manager.
3. Follow the prompts and instructions of the installation program.
4. After installation verify the consistency of the package by means
A G R E E M E N T
of comparing the real set of files and directories with the list in
FILELIST.TXT file.
After installation, the hard drive should contain the root directory of
OSEK which contains a set of files in the following subdirectories:
• BIN System Generator

• INC Operating System header files
• SRC Operating System source files
• HWSPEC Hardware specific files (usually startup and vector
table files)
• SAMPLE OSEK Operating System Sample application
• MAN User’s Documentation
There is a file titled FILELIST.TXT file in the OSEK OS root directory.

This document contains a complete list of files included in this release.
2.6 Technical Support Information

For additional product or support information please contact your local
Motorola Sales Office. Alternatively, use the following contact methods:
Email: osek@helpline.sps.mot.com
Phone: +44 13 55 35 53 98 (English)
+49 89 92 10 38 83 (German or English)
Notation
R E Q U I R E D
Fax: +44 13 55 26 52 01 (English)

+49 89 92 10 38 20 (German or English)
A G R E E M E N T
R E Q U I R E D
Section 3. Operating System Architecture
3.1 Contents
3.2 Processing Levels. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
A G R E E M E N T
3.3 Conformance Classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 OSEK OS Overall Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5 Application Program Interface . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Processing Levels

The OSEK Operating System provides a pool of different services and
processing mechanisms. It serves as a basis for application programs
which are independent of each other, and provides their environment on
a processor. The OSEK OS enables a controlled real-time execution of
several processes which virtually run in parallel.
The OSEK Operating System provides a defined set of interfaces for the
user. These interfaces are used by entities which are competing for the
CPU. There are two types of entities:
• Interrupts (service routines managed by the Operating System);

• Tasks (basic tasks and extended tasks).
The highest processing priority is assigned to the interrupt level, where

interrupt service routines (ISR) are executed. Interrupt services may call
a number of operating system services. The processing level of the
operating system has a priority ranking immediately below the former
one. This is the level on which the operating system works: task
management procedures, scheduler and system services. Just below
this is the task level on which the application software is executed. Tasks
are executed according to their user assigned priority. A distinction is
MOTOROLA Operating System Architecture 31

Operating System Architecture
R E Q U I R E D
made between the management of tasks with and without waiting state
(Extended and Basic Tasks, see Section 4.2 Task Concept). The run
time context refers to resources which are occupied at the beginning of
execution time and are released again once the task is finished.
The following priority rules have been established:
• Interrupts have precedence over tasks;

• The interrupt priority is defined by specific hardware conditions;
• For items handled by the OS, bigger numbers refer to higher
A G R E E M E N T
priorities;
• The task’s priority is statically assigned by the user.
The Operating System provides services and ensures compliance with

the priority rules mentioned above.
3.3 Conformance Classes

Various requirements of the application software for the system, and
various capabilities of a specific system (e.g. processor type, amount of
memory) demand different features of the operating system. These
operating system features are described as Conformance Classes (CC).
They differ in the number of services provided, their capabilities and

different types of tasks.
Conformance classes were created to support the following objectives:
• To provide convenient groups of operating system features for

easier understanding and discussion of the OSEK operating
system.
• To allow partial implementations along pre-defined lines. These
partial implementations may be certified as OSEK compliant.
• To create un upgrade path from classes of lesser functionality to
classes of higher functionality with no changes to the application
using OSEK related features.
The desired Conformance Class is selected by the user at system

generation time and cannot be changed during execution.
32 Operating System Architecture MOTOROLA

Conformance Classes
R E Q U I R E D
The definition of the functionalities provided by each Conformance Class
depends on the properties of the tasks and on the scheduling behavior.
As the task properties (Basic or Extended, see Section 4.3 Task State
Model) have a distinct influence on CC, they also assume part of their
names. There are Basic-CC and Extended-CC, and each of these
groups can have various “derivatives”.
Conformance classes are determined by the following attributes:
• Multiply requesting of task activation (see Section 4.4 Task

Activation and Termination);
A G R E E M E N T
• Task types (see Section 4.3 Task State Model);
• Number of tasks per priority.
BT only BT and ET
1 task/priority
no multiply activations BCC1 ECC1
>1 task/priority BCC2 ECC2

multiply activations for
basic tasks only
Figure 3-1. Restricted upward compatibility for conformance
classes
The following Conformance Classes are defined in the OSEK OS:

BCC1, BCC2, ECC1, ECC2.
• BCC1 – only Basic tasks, limited to one request per task and one
task per priority, while all tasks have different priorities;
• BCC2 – like BCC1, more than one task per priority possible and
multiple activation admissible;
• ECC1 – like BCC1, plus Extended tasks;
• ECC2 – like BCC2, plus Extended tasks without multiply activation
admissible.

R E Q U I R E D
BCC1 defines the minimum Conformance Class of the OSEK OS, ECC2
defines its maximum CC.
Multiple activations means that the OSEK OS receives and records

activations (even multiple activations) of a task already activated.
In the OSEK OS the number of task multiply activations is defined in a

basic task specific attribute during system generation. If the maximum
number of multiply activations has not been reached, the activation of
the basic task is queued in a Scheduler queue to preserve task activation
A G R E E M E N T
order.
Table 3-1 presents minimum resources to which an application may

resort, determined for each Conformance Class in the OSEK OS.
Table 3-1. OSEK OS Conformance Classes
BCC1 BCC2 ECC1 ECC2
BT: no, BT: yes,
Multiple activation of tasks no yes
ET: no ET: no
Number of tasks which are >= 16, any combination
>=8
not in the suspended state of BT/ET
1 >1
Number of tasks per priority 1 >1
(both BT/ET) (both BT/ET)
BT: no
Number of events per task -
ET: >= 8
Number of priority classes >=8

only
Resources >= 8 resources (including Scheduler)
Scheduler
Alarm >= 1 single or cyclic alarm
Messages possible
The system configuration option CC (specified by the user) defines the

class of the overall system. This option can have values BCC1, BCC2,
ECC1, ECC2 (see Section 13.3 OS Definition).
It is impossible to have tasks of different Conformance Classes in one

application! All tasks must strictly conform to the Conformance Class
specified at the system configuration stage.

OSEK OS Overall Architecture
R E Q U I R E D
Table 3-2 presents maximal values for system resources:
Table 3-2. OSEK OS maximal system resources
BCC1 BCC2 ECC1 ECC2
Number of tasks which are
limited only to RAM and/or ROM available(1)
not in the suspended state
Number of tasks per priority limited only to RAM available
BT: -
Number of events per task -
ET: 8(2)
Number of priority classes 256(2)
only
A G R E E M E N T
Resources limited only to RAM and/or ROM available(3)
Scheduler
Alarm limited only to RAM and/or ROM available
Messages limited only to RAM and/or ROM available
1. See Appendix C Memory Requirements for memory consumption numbers.
2. Keeping this value allows a byte to be used which improves RAM and ROM requirements
and execution speed.
3. In case of using resource access check, number of resources is limited to 8, including

Scheduler. This corresponds to the following system configuration: STATUS = EXTEND-
ED, Resources = TRUE, ResourceAccessCheck = TRUE, FastResource = FALSE (see
Section 13.3 OS Definition for the details of system configuration).
3.4 OSEK OS Overall Architecture
The OSEK OS is a real-time operating system, which is executed within
a single electronic control unit. It provides local services for user’s tasks.
The OSEK OS consists of the following components:
• Scheduler – controls the allocation of the CPU to the

different tasks;
• Task management – provides operations with tasks;
• ISR management – provides entry/exit frames for interrupt
service routines and supports CPU
interrupt flag manipulation;
• Resource management – supports a special kind of semaphore
for mutually exclusive access to shared
resources;

R E Q U I R E D
• Local communication – provides message exchange between

tasks;
• Counter management – provides operations on objects like
timers and incremental counters;
• Alarm management – links the tasks and counters;
• Error handlers – handle the user’s application errors and
internal errors, and provide recovery from
the error conditions;
A G R E E M E N T
• Hook routines – provide additional debugging features

• System start-up – initializes the data and starts the
execution of the applications;
• System timer – provides implementation-independent
time management.
As you have seen in Table 3-1, Conformance Classes, in general, differ

in the degree of services provided for the task management and
scheduling (number of tasks per priority, multiple requesting,
Basic/Extended Tasks). In higher CC advanced functionality is added for
resource management and event management only. But even in the
lowest BCC1 the user is provided with merely all OSEK OS service
mechanisms.
The OSEK Operating System is scaled not only via Conformance

Classes but it also has many various extensions which can be in any
Conformance Class. These extensions affect memory requirements and
overall system performance. The extensions can be turned on or turned
off with the help of the corresponding system configuration options.
These are all described in Section 12 System Configuration.
Since the OSEK Operating System is fully statically configured, the

configuration process is supported by the System Generator (SG). This is
a command-line utility, which processes system generation statements
defined by the user in the special file. These statements fully describe
the desired system features and application object’s parameters. SG
produces C-code that is to be compiled together with other user’s source
code. The produced code consists of C-language definitions and
declarations of data as well as C-preprocessor directives. See

Application Program Interface
R E Q U I R E D
Section 12 System Configuration and Section 14 Building of
Application for details about system generation.
3.5 Application Program Interface

The OSEK Operating System establishes the Application Program
Interface (API) which must be used for all user actions connected with
system calls and system objects. This API defines data types used by
the system, the syntax of all run-time service calls, declarations and
definitions of the system.
A G R E E M E N T
OSEK OS data types are described in subsections dedicated to the
corresponding mechanisms. Syntax of system calls and system
configuration statements are described briefly in corresponding
subsections and in detail in Section 12 System Configuration and
Section 17 System Services.
NOTE: The user’s source code shall strictly correspond to the rules presented
in this Manual.
The OSEK OS can has the Extended Status. It means that additional
checking is made inside all OS activities and extended return codes are
returned by all OS services to indicate errors if they have occurred. See
Section 17 System Services and Section 11.4 Error Handling
about Extended Status return values. To provide the Extended Status in
the system, the configuration option STATUS must be set to
EXTENDED at the configuration stage.

R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 4. Task Management
4.1 Contents
4.2 Task Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
A G R E E M E N T
4.3 Task State Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Task Activation and Termination . . . . . . . . . . . . . . . . . . . . . . . 44
4.5 Task Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.6 Task Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.7 Task Related Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.2 Task Concept

Complex control software can conveniently be subdivided into parts
executed according to their real-time requirements. These parts can be
implemented by means of tasks. A task provides the framework for the
execution of functions. The Operating System provides parallel and
asynchronous task execution organization by the scheduler.
OSEK OS provides a set of tools for the user to manage tasks. They are
activated before their execution – memory resources needed for a task
are allocated. Tasks may be terminated after necessary actions are
performed – memory resources are released. After a task is activated, it
may run and terminate or it may be implemented in an endless loop with
at least one synchronizing system call. It is not possible to run several
parallel endless loops without switching mechanism (scheduler). Tasks
can be switched during their execution from one to another, or may be
interrupted by ISR. If no task is active, only the scheduler idle loop runs
(see Section 5.2 General). Task states and transitions between them
are discussed in Section 4.3 Task State Model.
MOTOROLA Task Management 39

Task Management
R E Q U I R E D
Two different task concepts are provided by the OSEK OS:
• Basic Tasks (BT);

• Extended Tasks (ET).
Basic Tasks only release the processor, if:
• they are being terminated,

• the OSEK OS is executing higher-priority tasks, or
• interrupts occur which cause the processor to switch to an
A G R E E M E N T
interrupt service routine.
Extended Tasks are distinguished from Basic Tasks by being allowed to

use additional operating system services which may result in a waiting
state. The waiting state allows the processor to be freed and to be
reassigned to a lower-priority task without the need to terminate the
Extended Task.
Both kinds of tasks have their advantages which must be compared,

application dependent. They are both justified and are supported by the
OSEK operating system.
Each task has a set of data related to it – a task descriptor located in

ROM (task configuration table) and a task control block in RAM (task node)
for activated tasks. Also, each task has its own stack assigned. See
Section 4.7 Task Related Resources about the task control block, the
task configuration table and the task stack.
Every running task is represented by its run time context. This refers to
CPU registers and some compiler-dependent ‘pseudoregisters’ in RAM.
When the task is interrupted or preempted by another task, the run time
context is saved in the task’s stack. Run time context differs for non-
preemptive and preemptive tasks; for preemptive tasks, more RAM is
required to save the context. Therefore, for a mixed-preemptive system
(it means that both non-preemptive and preemptive tasks can exist in the
system, see Section 5.3 Scheduling Policy) a distinction can be made
by the Operating System between these types of contexts. It is
controlled by the UseSameContext configuration option. In the case
where different contexts are saved for non-preemptive and preemptive
tasks, the OS must perform additional code to distinguish the task type.
40 Task Management MOTOROLA

Task Management
Task State Model
R E Q U I R E D
Otherwise, some more RAM is required to store the ‘full’ context for non-
preemptive tasks too. The use of this option is application dependent.
4.3 Task State Model

A task can be in several states since the processor can only execute one
instruction of a task at any point in time, but several tasks may be
competing for the processor at the same time. The OSEK OS is
responsible for saving and restoring task context in conjunction with
state transitions whenever necessary.
A G R E E M E N T
4.3.1 Extended Tasks
Extended Tasks have four task states:
• running In the running state, the CPU is assigned to the

task, so that its instructions can be executed.
Only one task can be in this state at any point in
time, while all the other states can be adopted
simultaneously by several tasks.
• ready All functional prerequisites for a transition into
the running state exist, and the task only waits
for allocation of the processor. The scheduler
decides which ready task is executed next.
• waiting A task cannot be executed (any longer),
because it has to wait for at least one event
(see Section 9 Events).
• suspended In the suspended state, the task is passive and
does not occupy any resources, merely ROM.

Task Management
R E Q U I R E D
running
wait terminate
waiting preempt start suspended

A G R E E M E N T
release activate
ready
Figure 4-1. Task status model of an Extended Task with its task
transitions
Table 4-1. States and status transitions in the case of Extended Tasks
Transition Former state New state Description
A new task is entered into the ready list by a system

activate suspended ready
service.
start ready running A ready task selected by the scheduler is executed.
To be able to continue operation, the running task

wait running waiting requires an event. It causes its transition into the
waiting state by using a system service.
release waiting ready Events have occurred on which a task has waited.
The scheduler decides to start another task. The

preempt running ready
running task is put into the ready state.
The running task causes its transition into the
terminate running suspended
suspended state by a system service.
Termination of tasks is only possible if the task terminates itself (‘self-

termination’). This restriction is to avoid complex book-keeping of
resources dynamically allocated by the task.

Task Management
Task State Model
R E Q U I R E D
There is no provision for a direct transition from the suspended state into
the waiting state. This transition is redundant and would add to the
complexity of the scheduler. The waiting state is not directly entered
from the suspended state since the task starts and explicitly enters the
waiting state on its own.
4.3.2 Basic Tasks
The state model of Basic Tasks is nearly identical to the Extended Tasks
state model. The only exception is that Basic Tasks do not have a
A G R E E M E N T
waiting state.
• running In the running state, the CPU is assigned to the

task so that its instructions can be executed.
Only one task can be in this state at any point in
time, while all the other states can be adopted
simultaneously by several tasks.
• ready All functional prerequisites for a transition into
the running state exist, and the task only waits
for allocation of the processor. The scheduler
decides which ready task is executed next.
• suspended In the suspended state, the task is passive and
does not occupy any resources, merely ROM.
Table 4-2. States and status transitions in the case of Basic Tasks
Transition Former state New state Description
A new task is entered into the ready list by a system

activate suspended ready
service.
start ready running A ready task selected by the scheduler is executed.
The scheduler decides to start another task. The

preempt running ready
running task is put into the ready state.
The running task causes its transition into the
terminate running suspended
suspended state by a system service.

Task Management
R E Q U I R E D
running
terminate
preempt start suspended

A G R E E M E N T
activate
ready
Figure 4-2. Task status model with task transitions for Basic Tasks
4.4 Task Activation and Termination

Depending on the Conformance Class, a task can be activated single or

multiple.
The difference between single and multiple activation is that:
• For of a task suited for multiple activation, all task activations are
noted down. It means that whenever a task is activated by the
application, the appropriate task is started at the next possible
time, even if it is already running while the request is issued. In
such cases, the request is saved by the operating system, so the
task can be started again by the operating system once it has
been terminated. This procedure is repeated several times until all
requests have been completed. In the OSEK OS the activation of
the basic task is queued in Scheduler queues to preserve task
activation order.

Task Management
Task Activation and Termination
R E Q U I R E D
• In the case of a task suited for single activation, either the task
activation is noted down, or, if the task has already been
requested, nothing happens.
Multiple activation property exists only for BCC2 and ECC2

Conformance Classes. It is possible to turn it off via the system
configuration option MultiplyActivation.
OSEK OS uses the scheme of task activation and termination as shown

on Figure 4-3. This idea allows dynamic memory reallocation which
provides economical consumption of resources.
A G R E E M E N T
During task activation the ActivateTask service analyzes the task
configuration table of the task to be activated, and allocates a stack
buffer and a task node as specified in the task configuration table. In the
figure the typical allocation method is shown – a stack buffer is retrieved
from the stack pool and a task node from the scheduler’s list of free task
nodes. If these resources are available, then the task node is initialized
and inserted into the scheduler’s queues to be dispatched.
If the task does not have multiply activation requests, then the
TerminateTask and ChainTask services release both the task node and
the stack buffer and return them to the system for re-use. If a task has
multiple activation requests, then TerminateTask and ChainTask
services do not release the task node and the stack buffer because
these structures will be used for task reactivation.

Task Management
R E Q U I R E D
Stack pools Task nodes Task configuration tables

(control blocks)
Task
Free task configuration
table
node
Stack
A G R E E M E N T
buffer
Activate task Terminate task
Initialized Running
task mode task mode
Scheduler queues
Figure 4-3. Task management architecture
Hence, task activation may be considered as dynamic resource

allocation, because task control blocks and stack pools are allocated
dynamically. This approach allows the optimization of resource usage,

because one resource (for instance, a task control block) may be used
by different tasks at different times.
But, in the case where requested resources aren’t available, it may lead
to indeterministic behavior of the operating system. This situation may
occur when too many tasks are activated. To avoid that weakness, the
user is also allowed to statically assign task control blocks and stack
areas for critical tasks. Such explicitly defined resources are held by a
task for the application life time. In this case, the task control block and/or
the task stack are not released and cannot be re-assigned for other
tasks.

Task Management
Task Properties
R E Q U I R E D
4.5 Task Properties
In OSEK OS every task is characterized by the set of properties. These
properties define the task behavior and resource allocation method.
Each task property has its own name, and the user defines the task
features by setting the corresponding properties in the task definition.
See Section 12 System Configuration about task definition. The list of
possible task properties is provided in Table 4-3.
A G R E E M E N T
Table 4-3. Task Properties
Property Name Property Value Description
BASIC Basic task
TYPE
EXTENDED Extended task
NON Non-preemptive task
SCHEDULE
FULL Preemptive task
AUTOSTART TRUE/FALSE Activate the task at system start-up
A persistent task control block is assigned (linked with the task
PersistentNode TRUE/FALSE
configuration tables)
A stack should be allocated to the task during task activation –
POOLSTACK
dynamic stack allocation from the stack pool
A stack is explicitly assigned to the task (address of the top of
StackMethod OWNSTACK
the stack is included in the task configuration table)
A task node stack is implicitly assigned to be used by the task
NODESTACK
(during the task activation)
A persistent stack from the stack pool (the pool identifier is
PersistentStack TRUE/FALSE
included in the task configuration table)
4.6 Task Priorities

OSEK OS specifies the value 0 as the lowest priority in the operating
system. Accordingly bigger numbers define higher priorities.
In OSEK OS a priority is statically assigned to each task and it cannot be

changed by the user at the execution time. Some Conformance Classes
permit several tasks of the same priority level (see Section 3-1 OSEK
OS Conformance Classes). A dynamic priority management is not

Task Management
R E Q U I R E D
supported. However, in particular cases the operating system can treat

a task with a defined higher priority. In this context, please refer to
Section 7.3.1 Priority Ceiling Protocol.
On the basis of the task priority the scheduler decides which is the next
of the ready tasks to be transferred into the running state. Tasks are
started depending on their order of activation, according to the FIFO
mechanism, whereby an Extended Task in the waiting state does not
block the start of subsequent tasks of identical priority.
A G R E E M E N T
A preempted task is considered to be the oldest task in the ready list of

its current priority. A task being released from the waiting state is treated
like the newest task in the ready list of its priority.
Figure 4-4 illustrates how tasks priorities affect the order of their
execution
.
N 3 2 1 0
FIFO
list of
ready
tasks •••
high low
priority
> > these tasks will be

scheduler executed in turn later
search the
next task to
be processed
actually processed
CPU and terminated task scheduler next running task
(with priority N)
processor time
Figure 4-4. Task priorities

Task Management
Task Related Resources
R E Q U I R E D
Several tasks of different priorities are in the ready state – three tasks of
priority 3, one of priority 2, one of priority 1, and two priority 0 tasks. The
task that has waited the longest time, depending of its order of
requesting, is shown at the bottom of each FIFO queue. The CPU has
just processed and terminated a task with priority N. The scheduler
selects the next task to be processed (priority 3, first FIFO location).
Before priority 2 tasks can be processed, all tasks of higher priority must
have been executed completely.
Thus, the following three steps are made to switch to the next running
task:
A G R E E M E N T
1. The scheduler searches for all tasks in the ready state.
2. From the set of ready tasks, the scheduler determines the set of
tasks with the highest priority.
3. Within the set of tasks in the ready state and of the highest priority,
the scheduler finds the task that has been in the ready state the
longest time (‘oldest’ task).
4.7 Task Related Resources

Each task has a task configuration table in ROM and task control block
(task node) and task stack in RAM (during the task run time, if they are
not assigned statically). These resources uniquely define task properties
and the task run-time context. Also, at run-time the task link table exists
in RAM to provide the correspondence between the task control block
and the task configuration table.
4.7.1 Task Configuration Table
The ROM-based task configuration table contains a static task

description. This table holds all the information describing the task’s
properties and serves to initialize the RAM-based task control block
during task activation.
The task configuration table contains the following data:

Task Management
R E Q U I R E D
• Task properties (see Table 4-3) which define a run-time behavior

of the task, as well as task activation parameters. The main
properties are whether it is a Basic/Extended task (for the
extended Conformance Classes only) or a preemptive/non-
preemptive task (for a mixed-preemptive scheduling policy). The
properties also specify the source of the stack for the task, and the
assignment of the task control block;
• OS internal priority of the task1;
• User defined priority of the task;
A G R E E M E N T
• The hardware memory bank of the task2. If banked memory model

is not supported (the HCBankCode system configuration option is
turned off) this field is absent in the task configuration table;
• The starting interrupt mask of the task. This field is absent if
interrupt mask control is not supported;
• The program counter value (the entry point) of the task;
• The address of the persistent task node, that is a task node that is
permanently assigned to the task (see Section 4.7.2 Task
Control Block). This field is absent if persistent task control
blocks are not supported in the system;
• The address of the task stack source, i.e. the address of the stack
pool or the constant address of the own task stack (see

Section 4.7.4 Task Stack). This field is absent if all tasks use
only node stacks.
• The maximum number of the task multiply activations.
• The address of the element of the task link table (see
Section 4.7.3 Task Link Table). This field is absent if the
simplified scheduler is used in the system (see
Section 5.2.1 Simple Scheduler) or the system configuration
option TaskIndexMethod is off and task multiple activation is not
supported.
1. OSEK OS uses internal task priority during run-time. This priority is calculated by OSEK OS
SysGen tool during application configuration. It may differ from user-defined task priority as a re-
sult of optimization.
2. This property is not used in current version of OSEK OS.

Task Management
R E Q U I R E D
Some of these parameters are specified by the user during system
configuration by means of the TASK object definition, while others are
generated automatically. See Section 12 System Configuration and
Section 14 Building of Application about system configuration and
building an application.
4.7.2 Task Control Block
A RAM-based task control block (task node) serves as a dynamic

descriptor of the task. It is valid only during task execution, that is when
A G R E E M E N T
the task is not in the suspended state. Except persistent node
assignment (see Section 4.7.2.1 Persistent Node Assignment), this
task control block is linked to the scheduler’s list of free nodes when it is
not assigned to the task. In general, this block is allocated to the task
during task activation, and it is initialized at that moment (see Figure 4-
3).
The task control block contains the following data:
• A pointer for linking the task control block into scheduler queues.
This field is absent if the simplified scheduler is used in the
system;
• The current task status. Some of the status bits are copied from
the task property bits of the task configuration table. Other bits are:
– a task waiting bit, which is set when the task is waiting for an
event(s);
– a scheduler bit, which is set when the task occupies the
scheduler.
• The current task priority. In general, the current priority may differ
from the starting priority (located in the task configuration table)
during the periods of time when the task occupies the resources,
see Section 7.3.1 Priority Ceiling Protocol.This field is absent
if the simplified scheduler is used in the system;
• A pointer to the task configuration table;
• The task context (for non-preemptive tasks), or a pointer to the
stack frame, where the context is saved (for preemptive tasks).
Note, that for mixed-preemptive scheduling systems, both non-

Task Management
R E Q U I R E D
preemptive context and a pointer to the preemptive context are

defined if the system configuration option UseSameContext is
turned on. Otherwise, the preemptive context is used for non-
preemptive tasks also;
• Two fields for event control in Extended Classes of the system.
The first field contains the mask of the events the task is waiting
for, while the second field contains the mask of the events that are
set for the task (see Section 9 Events). If event management is
not supported, these fields are absent;
A G R E E M E N T
• The pointer to the head of the list of resources occupied by the

task (if resource management is supported and the system
property FastResource is turned off, see Section 7 Resource
Management);
• The address of the stack buffer allocated to the task. It is used
during task termination when task management returns this stack
buffer into the stack pool. If stack pools are not supported in the
system then this field is absent;
• The address of the task node stack or address of the persistent
task stack if persistent node assignment is supported by the
system. This field is absent if neither task node stacks nor
persistent stacks are used;
• The real address of the top of the task stack. This field is absent if
multiple activation is not supported and the system configuration
option ChainTaskItself is turned off.
The task control block size depends on the system configuration and
task properties. See Appendix B System Service Timing
4.7.2.1 Persistent Node Assignment
The task control block may be statically assigned to the task. This
mechanism prevents a task activation failure due to missing free task
nodes and increases the speed of task activation/termination operations
by means of excluding a task node queue manipulation. This
mechanism is called persistent task node assignment, and it is illustrated
in Figure 4-5. To define persistent node assignment for the task, the
task property PersistentNode must be set in the TASK definition for this

Task Management
R E Q U I R E D
task and the system configuration option PersistentNode must be turned
on.
As it is in the figure, task#2 has persistent task node#3 assigned to this

task. Therefore, this task control block cannot be used by any other task
in the system, and is not linked into the scheduler’s list of free nodes
when task#2 is not activated (not used). This task node is exclusively
assigned for use by task#2. On the other hand, task#1 may use any of
task nodes #1, #2 or #4, if they are free while task#2 is activated.
Persistent task node assignment may be used in combination with any
A G R E E M E N T
of the stack allocation options (see Section 4.7.4 Task Stack).
Task configuration table #1 Task nodes array
Free task node #1
Free task node #2
Task configuration table #2

Persistent task node #3
the task node address Free task node #4
Activate task
Figure 4-5. Persistent task node assignment
4.7.3 Task Link Table
Every task in the system is defined via the ROM-based task

configuration table. When a task is activated, the task allocates a task
node, and the address of the task configuration table is stored in the task

Task Management
R E Q U I R E D
node. To accelerate the procedure of run-time task referencing, the

system supports a special RAM-based vector of the links between the
task configuration tables and task nodes. This vector is called the task
link table. It serves for fast access to the task configuration table and the
corresponding task control block during operations which reference to a
task.
The task link table is illustrated in the figure below:

A G R E E M E N T
Task configuration tables Task nodes
Task #1 Task node #1
Task link table

NULL
Task node #4
... ... Task node #3
Task node #1
Figure 4-6. Task link table
The task link table contains one element per task configured in the
system. The element contains a NULL-pointer if the task is in the
suspended state, or the task node address if the task is in the non-
suspended state (it is saved there during task activation). For instance,
in Figure 4-6 task#1 is not activated, while task#2 and task#8 are
activated. Task#2 uses task node#4, and task#8 uses task node#1. The
task configuration table contains the address of the task link element.
The system uses this address when the task is referenced, and looks at
the contents of the element of the task link table to define the current
state of the task.
If the OSEK OS supports task multiple activations, then the task link
table contains one additional element per task. The element is the

Task Management
R E Q U I R E D
counter of times of activation. That is, the content of this field increments
each time the task to be activated is in the non-suspended state, and
decrements each time the task is terminating.
4.7.4 Task Stack
4.7.4.1 Stack Allocation
During run-time, every task has its own stack. The stack is either
dynamically assigned to a task during its activation or statically allocated
A G R E E M E N T
for a task during system initialization. If a stack is allocated dynamically,
it is got from a stack pool. Several options are possible for static stack
assignment during system start-up.
Stack pools are used by task management to dynamically allocate stack

area for a task during task activation. To have stack pools in the system
the configuration option StackPool must be turned on. The user should
specify the desired number of stack pool with a defined number of
buffers of the required size in them. This is done with the help of the
STACK definition statements, see Section 12 System
Configurationand Section 14 Building of Application. The stack
pool contains a queue of stacks of a fixed size. The task control block
contains the address of the stack pool control block, and the stack buffer
is unlinked from the pool and assigned to the task during task activation.
During task termination the stack buffer is returned to the stack pool.
The simplest method of stack allocation is to use task node stacks. Each
task in the OSEK Operating system has the stack linked with a task
node. The size of this stack is the same for all tasks. It is defined by
means of the corresponding OS property NodeStackSize. See
Section 4.7.5 Allocation of Fixed Stack Linked with the Task Node
for this option.
The following options are available for task stack allocation:
1. Allocation of fixed stack linked with the task node.

2. Dynamic stack allocation from the stack pool.
3. Persistent stack allocation from the stack pool.

Task Management
R E Q U I R E D
4. Explicit stack allocation.
These options may be used simultaneously in the system, but each task
must use only one of them. These options allow the user to optimize
stack usage in the application.
The use of the stack allocation options is illustrated in Figure 4-7,

Figure 4-8, Figure 4-9, Figure 4-10 and explained below.
4.7.5 Allocation of Fixed Stack Linked with the Task Node

A G R E E M E N T

Task node #1 Task node stack
stack pointer
task node stack
Figure 4-7. Fixed stack linked with the task node
To allocate a task stack in this manner, the NODESTACK value should

be assigned to the StackMethod task property. Every task control block

in the system has an associated stack. The size of this stack is defined
by means of the NodeStackSize OS property and is the same for all task
nodes. During task activation, the system allocates a task control block
and the linked stack, and uses this stack as a task stack. Because all
task control blocks have an associated stack, it is the simplest method
of stack allocation. But, in this case, all tasks will use a stack of the same
(fixed) size regardless of the stack space really needed for tasks. To
remove such a stack type, the system configuration option NodeStack
should be turned off.

Task Management
R E Q U I R E D
4.7.5.1 Dynamic Stack Allocation from the Stack Pool

Stack pool Task node #2
stack buffer
Stack buffer
stack pool node stack pointer
A G R E E M E N T
Figure 4-8. Dynamic stack allocation from the stack pool
To force a task to use dynamic stack allocation, the POOLSTACK value

should be assigned to the StackMethod task property and the reference
to the stack pool. The stack pool is defined separately and it is statically
assigned to the task. Task #2 is configured to allocate a stack from the
stack pool during task activation. The task configuration table contains
the address of the stack pool, and the system allocates a stack buffer
from this pool, saving the address of the stack buffer in task node #2.
During task termination the stack buffer is returned to the stack pool
queue. The user is allowed to configure a stack pool of different sizes
and set the number of stack buffers in each to satisfy different stack
space requirements for various tasks.
NOTE: The user is responsible for the proper quantity of stack buffers to avoid
a possible failure of task activation if there are no stack buffers left. Also,
the increased time of task activation/termination due to stack pool
manipulations timing should be taken into consideration. This method
allows most efficient RAM distribution for task stacks.
4.7.5.2 Persistent Stack Allocation from the Stack Pool
To use persistent stack allocation from the stack pool the user should set
both PersistentNode and PersistentStack task properties. The system
configuration option PersistentStack must be turned on. In this case, the
task stack is allocated from the stack pool during system initialization
and the address of the stack is written in the task control block, which is

Task Management
R E Q U I R E D
persistently designated to the task too. In Figure 4-9 task #3 is

configured so that the persistent task node and a stack buffer from the
specified pool are allocated for the task at system start-up, and the
address of the allocated stack buffer is placed in the task node.
stack pool node Stack pool

A G R E E M E N T
task node address

Buffer
Buffer
Buffer
Persistent Task node #3
Task nodes
buffer
stack buffer
Free task node #1 Buffer
stack pointer
Free task node #2
Persistent task node #3
Free task node #4

Figure 4-9. Persistent stack allocation from the stack pool
NOTE: Persistent stack from a stack pool may be assigned only for the task with
assigned persistent task node and with assigned stack pool.

Task Management
R E Q U I R E D
4.7.5.3 Explicit Stack Allocation
Task configuration table #4 Static stack Task node #4
stack pointer
top of stack
Figure 4-10. Static stack allocation
A G R E E M E N T
Persistent stack allocation is selected when the OWNSTACK value is
given to the StackMethod property in the task definition. The system
configuration option TaskOwnStack must be turned on. The user must
also specify the stack size. In the figure above, task #4 has a stack
permanently assigned to the task. The user is allowed to assign one
static stack area to different tasks, if these tasks are not activated
simultaneously. But with such stack allocation there is the overhead
connected with non-used RAM areas when the task is not activated.
4.7.5.4 Stack Size
The minimal size of the task stack depends on:
• the scheduling policy (non-preemptive or preemptive task);
• the services that are used by the task;
• the interrupt and error handling policy;
• the processor type.
The recommended values of the minimal task stack size are provided in
Section 15.5 Task Stack Size.
NOTE: If the task stack is less than the minimal value for the given configuration,
it may lead to unpredictable behavior of the task and to a system crash.

Task Management
R E Q U I R E D
4.8 Programming Issues
4.8.1 Configuration Options
The following system configuration options affect the task management:
• MultiplyActivation The option controls the multiply activation

ability for Conformance Classes. If the
option is turned off, multiply activation is
disabled for tasks of these Conformance
A G R E E M E N T
Classes. This option may be turned on

only for BCC2, ECC2 Conformance
Classes.
• TaskIndexMethod If this option is turned on then the
intermediate vector of the pointers to the
tasks control blocks is used (fast and
deterministic access to task control
blocks).
• NodeStack This option defines the presence of task
node stacks in the system. If it is turned off
there are no task node stacks
implemented.
• StackPool This option defines the presence of stack

pools in the system. If it is turned off, there
are no stack pools implemented.
• PersistentNode If this option is turned on, a persistent task
control block may be assigned to the task.
• PersistentStack If this option is turned on, a persistent
stack buffer may be assigned to the task.
• TaskOwnStack This option defines that a task may have
its own stack.
• UseSameContext If this option is turned on, the same run
time context frame is used both for non-
preemptive and preemptive tasks in
mixed-preemptive systems.

Task Management
Programming Issues
R E Q U I R E D
• TaskBasePage If this option is turned on, the task control
blocks are placed into the base page
memory. It increases the system
performance, since the CPU accesses
the base page faster than extended
memory. In this case, the user is
responsible for the necessary amount of
RAM in the base page for the desired
number of task control blocks.
A G R E E M E N T
4.8.2 Data Types
The OSEK OS establishes the following data types for the task
management:
• TaskType The abstract data type for task

identification;
• TaskRefType The data type to refer variables of the
TaskType data type;
• TaskStateType The data type for variables to store the
state of a task;
• TaskStateRefType The data type to refer variables of the
TaskStateType data type.
The following data types belong to OSEK OS extension:
• TaskControlBlockType The data type for task control block

(task node);
• TaskControlBlockRefType The data type to refer variables of the
TaskControlBlockType data type.
Only these data types may be used for operations with tasks.
4.8.3 Task Definition
Each task in an application is generated by means of using the TASK

system generation statement.

Task Management
R E Q U I R E D
The task definition looks like the following:
TASK <TaskName> {
TYPE = <TaskType>;
PRIORITY = <TaskPriority>;
SCHEDULE = <TaskScheduling>;
ACTIVATION = <TaskMultiplyActivation>;
AUTOSTART = <TaskInitState>;
StackMethod = <TaskStackAssignment>;
};
The application definition file contains one such statement per task. The
A G R E E M E N T
task generation statement is described in detail in Section 12 System

Configuration.
To refer to a task, the constructional statement DeclareTask should be

used to declare the task before references to it.
DeclareTask looks like the following:
DeclareTask( TaskType <TaskName> )
4.8.4 Run-time Services
OSEK OS grants a set of services for the user to manage tasks. A

detailed description of these services is provided in Section 17 System
Services. Here only a brief list of them is given.
Table 4-4. Task Management Run-time Services

Service Name Description
ActivateTask Activates the task, i.e. put it from the suspended into the ready state
TerminateTask Terminates the task, i.e. put it from the ready into the suspended state
ChainTask Terminates the task and activates a new one immediately
Schedule Yields control to a higher-priority ready task (if any exists)
GetTaskId Gets the identifier of the running task
GetTaskState Gets the status of the specified task
Copies contents of the running task control block

GetTCBInfo(1)
by the address specified
1. This service is not defined in the OSEK OS v.2.0 rev.1 specification. This is an extension of OSEK OS.

Task Management
Programming Issues
R E Q U I R E D
Examples of using the run-time services are provided in
Section 17.3.12 Examples for Task Management Services.
4.8.5 Constants
The following constants are used within the OSEK Operating System to
indicate task states:
• RUNNING Constant of data type TaskStateType for task

state running
A G R E E M E N T
• WAITING Constant of data type TaskStateType for task
state waiting
• READY Constant of data type TaskStateType for task
state ready
• SUSPENDED Constant of data type TaskStateType for task
state suspended
These constants can be used for variables of the TaskStateType.
The following constant is used within the OSEK OS to indicate task:
• INVALID_TASK Constant of data type Task Type for an

undefined task
4.8.6 Conventions
Within the OSEK OS application a task should be defined according to

the following pattern:
TASK ( TaskName )
{
...
}
The name of the task function will be generated from TaskName by

macro TASK.

Task Management
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 5. Scheduler
5.1 Contents
5.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
A G R E E M E N T
5.3 Scheduling Policy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.2 General
The algorithm deciding which task has to be started and triggering all
necessary OSEK Operating System internal activities is called scheduler.
It performs all actions to switch the CPU from one instruction thread to
another. It is either switching from task to task or from ISR back to a task.
The task execution sequence is controlled on the base of task priorities
(see section Section 4.6 Task Priorities) and the scheduling policy
used.
The scheduler is activated whenever a task switch is possible according
to the scheduling policy. The principle of multitasking allows the
operating system to execute various tasks concurrently. The sequence
of their execution depends on the scheduling policy, therefore it has to
be clearly defined.
Scheduler also provides the endless idle loop if there is no task ready to
be running. It may occur, when all tasks are in the suspended or waiting
state until the awakening signal from an Interrupt Service Routine
occurs. In this case there is no currently running task in the system, and
the scheduler occupies the processor performing an endless loop while
the ISR awaits a task to be executed. It is possible to call a special user’s
hook from the scheduler idle loop. This property is turned on via the
system configuration option IdleLoopHook. If it is supported by
hardware, the scheduler’s idle loop may be replaced by an instruction
MOTOROLA Scheduler 65
Scheduler
R E Q U I R E D
that puts the CPU in low power mode to reduce power consumption. This
property is turned on via the system configuration option HCLowPower.
The scheduler has its own small stack (the scheduler’s stack) which is
needed for the endless idle loop. The stack size is specified by the user,
see section Section 13.3.1 Global System Attributes. The system
property UseMainStack can be specified by the user. In this case, the
same stack is used by the main() function, by the scheduler and by ISRs.
This option saves RAM consumption, but the user is responsible for the
required memory amount for the stack.
A G R E E M E N T
The scheduler can be treated as a specific resource that can be

occupied by any task. See Section 7.3.2 Scheduler as a Resource for
details.
The scheduling policy and some scheduler-related parameters are

defined by the user, see Section 13.3.1 Global System Attributes and
Section 13.3.2 Task Related Attributes.
5.2.1 Simple Scheduler
If each task in the application has an unique priority, the simplified

scheduler may be used to reduce memory and time consumption. In this
case, the scheduler uses a table of tasks instead of queues. This system
property can be turned on via the system configuration option
SimpleScheduler. By default this option is turned off.
The option does not depend on Conformance Classes so it is possible

to use this system property in ECC2 as well as in BCC1, but unique task
priorities are required (one task per priority).
The simplified scheduler cannot be used with resource management

and task multiply activation. Therefore, if the SimpleScheduler and the
Resources or MultiplyActivation options are both turned ON in the
system configuration file, then SimpleScheduler is ignored by the
System Generator, and an error message is produced (see
Section 12 System Configuration).
66 Scheduler MOTOROLA
Scheduler
Scheduling Policy
R E Q U I R E D
5.3 Scheduling Policy
The scheduling policy being used determines whether execution of a
task may be interrupted by other tasks or not. In this context, a distinction
is made between full-, non- and mixed-preemptive scheduling policies.
The scheduling policy affects the system performance and memory
resources. In the OSEK Operating System, all listed scheduling policies
are supported, but in the case of the mixed-preemptive policy, each task
in an application may use only one of the three policies. It is defined via
the appropriate task property (preemptive/non-preemptive).
A G R E E M E N T
Note that the interruptibility of the system depends neither on the
Conformance Class, nor on the task type.
The desired scheduling policy is defined by the user via the system
configuration option SCHEDULE. The valid values are – NON, FULL,
MIXED.
5.3.1 Non-preemptive Scheduling
The scheduling policy is considered as non-preemptive, if a task switch

is only performed via one of a selection of explicitly defined system
services (explicit point of rescheduling).
Non-preemptive scheduling imposes particular constraints on the
possible timing requirements of tasks. Specifically, the lower priority
non-preemptive section of a running task delays the start of a task with
higher priority, up to the next point of rescheduling. The time diagram of
the task execution sequence for this policy looks like the following:
Scheduler
R E Q U I R E D
latency time
activation of task T1 for task T1
Task T1 suspended ready running
Task T2 running suspended
terminaton of task T2
A G R E E M E N T
Figure 5-1. Non-preemptive scheduling
Task T2 has lower priority than task T1. Therefore, it delays task T1 up
the point of rescheduling (in this case termination of task T2).
The following points of rescheduling exist in the OSEK Operating

System:
• Successful termination of a task (via the TerminateTask system

service);
• Successful termination of a task with explicit activation of a
successor task (via the ChainTask system service);
• Explicit call of the scheduler (via the Schedule system service);
• Explicit wait call, if a transition into the waiting state takes place
(via the WaitEvent system service, Extended Tasks only).
In the non-preemptive system, all tasks are non-preemptive and the task
switching will take place exactly in the listed cases.
5.3.2 Full-preemptive Scheduling
Full-preemptive scheduling means that a task which is presently running

may be rescheduled at any instruction by the occurrence of trigger
conditions preset by the operating system. Full-preemptive scheduling
will put the running task into the ready state as soon as a higher-priority
task has got ready. The task context is saved so that the preempted task
can be continued at the location where it was interrupted.
Scheduler
Scheduling Policy
R E Q U I R E D
With full-preemptive scheduling, the latency time is independent of the
run time of lower priority tasks. Certain restrictions are related to the
increased RAM space required for saving the context, and the enhanced
complexity of features necessary for synchronization between tasks. As
each task can theoretically be rescheduled at any location, access to
data that are used jointly with other tasks must be synchronized.
In a full-preemptive system all tasks are preemptive.
A G R E E M E N T
activation of task T1 terminaton of task T1
Task T1 suspended running suspended
Task T2 running ready running

terminaton of task T2
Figure 5-2. Full-preemptive scheduling
5.3.3 Mixed-preemptive Scheduling
If full-preemptive and non-preemptive scheduling principles are to be
used for execution of different tasks on the same system, the resulting
policy is called “mixed-preemptive” scheduling. The distinction is made
via the task property (preemptive/non-preemptive).
The definition of a non-preemptive task makes sense in a full-preemptive

operating system in the following cases:
• if the execution time of the task is in the same magnitude of the

time of a task switch,
• if RAM is to be used economically to provide space for saving the
task context,
• if the task must not be preempted.
Many applications comprise only a few parallel tasks with a long

execution time, for which a full-preemptive operating system would be
convenient, and many short tasks with a defined execution time where
Scheduler
R E Q U I R E D
non-preemptive scheduling would be more efficient. For this

configuration, the mixed-preemptive scheduling policy was developed
as a compromise.
NOTE: Tasks can be ported between preemptive, non-preemptive and mixed-

preemptive OSEK applications if they do not have any assumption of
non-preemptability. That means that critical data must be protected
using resources and communication must be done using messages.
A G R E E M E N T
The following system configuration options are intended to define

scheduler properties:
• SimpleScheduler If this option is turned on, the simplified

scheduler will be used in the system if each
task has a unique priority. It reduces the OS
code and increases system performance.
• SCHEDULE This option defines which scheduling policy,
non-preemptive, full-preemptive or mixed-

preemptive, will be used in the application.
• UseMainStack If this option is turned on, the same stack area
is used for the main() function (during start-up),
for the scheduler stack and for the ISR stack.
• IdleLoopHook If this option is turned on, then user supplied
hook will be called from the scheduler idle loop.
• HCLowPower If this option is turned on, an instruction that
puts the CPU in low power mode is used
instead of the scheduler’s idle loop.
Scheduler
Programming Issues
R E Q U I R E D
The scheduler is not accessed by the user directly. The user can only
pass the CPU control to the scheduler by means of the Schedule system
service. This leads to task rescheduling.
The scheduler can be used by the programmer as a resource (in all

Conformance Classes). To provide this possibility, the services
GetResource and ReleaseResource with the constant
RES_SCHEDULER as a parameter can be called by a task. It means
that the task cannot be preempted by any other task after the scheduler
A G R E E M E N T
occupation, before the corresponding call ReleaseScheduler is
performed. While the task occupies the scheduler, it has the highest
priority and, therefore, cannot be interrupted by other tasks (only ISRs
can get the CPU control during this period). Such programming practice
can be used for important critical sections of code.
See the example:
GetResource( RES_SCHEDULER );
...
/* Critical section - this code cannot be interrupted by any other task */
...
ReleaseResource( RES_SCHEDULER ); /* End of the critical section */
5.4.3 Scheduler Definition
The scheduler parameters must be defined by the user in the

configuration file by setting the corresponding OS attributes.
Definition of scheduler related system properties looks like the following:
OS <name> {
.....
SCHEDULE = MIXED;
NodeNumber = <NumberOfTasks>;
SchedStackSize = <SchedulerStackSize>;
MaxPrio = <NumberOfPriorities>;
NodeStackSize = <TaskNodeStackSize>;
.....
};
The OS generation statement is described in detail in

Section 12 System Configuration.
Scheduler
R E Q U I R E D
A G R E E M E N T
R E Q U I R E D
Section 6. Interrupt Processing
6.1 Contents
6.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
A G R E E M E N T
6.3 ISR Stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.4 ISR Categories . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.5 Interrupt Flag Manipulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.6 Local Variables Considerations . . . . . . . . . . . . . . . . . . . . . . . . 78
6.2 General
Interrupt processing is an important part of any real-time operating
system. An Interrupt Service Routine (ISR) is a routine which is invoked
from an interrupt source, such as a timer or an external hardware event.
ISRs have higher priority than all tasks and the scheduler. Addresses of
ISRs should be pointed to in the vector table.
In OSEK OS, all ISRs should use the separate stack (ISR stack) which is
used only by ISRs during their execution. The size of the ISR stack is
defined by the user. At the beginning of an Interrupt Service Routine, the
user should switch to this stack using the system service EnterISR. After
the ISR completion, the corresponding service LeaveISR should be
performed to switch back to the previous stack. The instruction
sequence between the EnterISR and LeaveISR calls is considered as
ISR frame.
When interrupt occurs, either current stack can be used or the ISR stack.
The current stack is:
• the stack of the interrupted task,
MOTOROLA Interrupt Processing 73

Interrupt Processing
R E Q U I R E D
• the scheduler’s stack if an interrupt occurred during scheduler

execution,
• ISR stack in case of nested interrupts.
OSEK OS supports nested interrupts, theoretically up to 255 levels1. A

special system counter tracks the number of nested interrupts. Since the
OS provides the means to switch the stack and to control the interrupt
mask, such nested interrupts, if written correctly, could be treated as a
single one. To not waste a task stack space for nested interrupts or
complicated ISR, the ISR stack is used.
A G R E E M E N T
OS also controls the state of an interrupt mask. The user defines values
of the interrupt masks for disabling and enabling all interrupts, and the
default interrupt mask for task execution. See Section 13.3.3 Interrupt
Related Properties for details.
ISRs can communicate with tasks in the OSEK OS by the following

means:
• ISR can activate a task;

• ISR can send an unqueued or a queued message to a task;
• ISR can trigger a counter;
• ISR can get state of the task;

• ISR can set event for a task;
• ISR can get event mask of the task;
• ISR can manipulate alarms;
• ISR can get active application mode.
Interrupts cannot use any OS services except those which are specially
allowed to be used within ISRs. When using other services, the system
behavior will be unpredictable. In the Extended (debugging) status of the
Operating System, the error will be reported in such a case. See
1. If PreTaskHook/PostTaskHook user’s hooks are used (see Section 11.3 Hook Routines)
and GetTaskId directive is supported (see Section 17.3.9 GetTaskId) then OSEK OS supports
up to 127 levels of nested interrupts.
74 Interrupt Processing MOTOROLA

ISR Stack
R E Q U I R E D
Section 6-1 Interrupt Management Services in the OSEK OS and
Section 17 System Services for details.
6.3 ISR Stack

The purpose of the ISR stack is to save memory. Since interrupts can be
nested, it means, that every task stack must be big enough to store
several interrupt stack frames (in addition to task needs for local
variables, function calls, etc.). To avoid this overhead, the separate ISR
stack is used in the OSEK Operating System. Switching to this stack is
A G R E E M E N T
performed by the EnterISR service at the beginning of ISR. This stack is
used only by ISRs, and if nested interrupts occur after the stack has
been switched, they will use this stack too. Before leaving the ISR,
switching back to the interrupted task stack must be achieved by means
of LeaveISR.
The interrupt stack frame usually consists of the CPU registers, and
optionally some compiler-dependent ‘virtual’ registers. The CPU
registers are pushed onto the stack under hardware or software control.
In the latter case the compiler generates a stack frame by means of
adding special sequences of machine instructions before the first
statement in the function.
Most compilers use function modifiers (like ‘interrupt’) to generate stack
frames. In turn, the ISR keyword, specified in OSEK (see
Section 6.7.4 Conventions), is a macro for this modifier.
6.4 ISR Categories

In the OSEK Operating System three types of Interrupt Service Routines
are considered.
6.4.1 ISR Category 1
ISRs of this type do not use any operating system service. These ISRs
do not use OS services EnterISR and LeaveISR, consequently, ISRs of
these type are executed on the current stack. In this case, if the ISR uses

R E Q U I R E D
the stack space for its execution, the user is responsible for the
appropriate stack size. Moreover, if interrupts are re-enabled inside the
ISR, nested interrupts are possible, which will use the same task stack.
The general recommendation for ISRs category 1 may be the following:
RULE: ISR category 1 cannot use any OS services. These ISRs must disable
interrupts internally (at the beginning of the routine).
After the ISR is finished, processing continues exactly at the instruction

where the interrupt occurred, i.e. the interrupt has no influence on task
A G R E E M E N T
management.
ISR( ISR_handler )
{
...
/* the code without any OS service calls */
...
}
In ISR category 2, the OSEK Operating System provides an automatic

EnterISR call at the very beginning to switch to the ISR stack and save
the initial interrupt mask. After that, any user’s routine can be executed,
including allowed OS calls (to activate a task, send a message or trigger
a counter). See Section 6.7.3 Run-time Services for the list of

services allowed for ISR. At the end of the ISR, the System automatically
executes LeaveISR service to switch back to the task stack and restore
the interrupt mask.
ISR( ISR_handler )
{
/* OS internal EnterISR() call */
...
/* the code with allowed OS calls */
...
/* OS internal LeaveISR() call */
}
Inside the ISR, no rescheduling will take place. Rescheduling may only
take place on termination of the ISR if a preemptive task has been
interrupted.

Interrupt Flag Manipulation
R E Q U I R E D
In ISR category 3, the OSEK Operating System provides the ISR frame
to execute more complicated user code. The ISR frame is instructions
between OS services EnterISR and LeaveISR. Such ISRs are similar to
those of category 2, but the location of the ISR frame in the code
segment is application dependent and user defined. The code outside
the ISR frame can be used, e.g., to access global variables or hardware
registers. The user is responsible for operations outside the ISR frame,
since they could unproperly modify stack frame (see Section 6.6 Local
Variables Considerations), and interrupts may be enabled (see
A G R E E M E N T
Section 6.4.1 ISR Category 1). No OS service calls can be executed
outside the ISR frame.
ISR( ISR_handler )
{
/* user’s code */
...
EnterISR();
/* the code with allowed OS calls */
...
LeaveISR();
}
To avoid possible errors the following rule for ISR category 3 is

recommended:
RULE: In ISR category 3, all operations using OS services and/or with enabled
interrupts must be performed only inside the ISR frame.
The OSEK Operating System has no means to distinguish ISR

categories 2 and 3 at run-time. Therefore, such distinction should be
made by the user at the stage of source code writing.
6.5 Interrupt Flag Manipulation

OSEK OS provides services to control the interrupt flag – to disable or
enable interrupts and get the current state of the interrupt mask. These
services are implemented to allow the user to control interrupts of
several interrupt levels (for instance, Motorola MC68HC16 MCU has 8
interrupt levels). In this case, it is possible to set the desired interrupt

R E Q U I R E D
mask which disables some interrupts and enables other ones. In the
interrupt definition statement, the user should select interrupt masks for
all interrupts disabled, all interrupts enabled and some desired medium
state (by default a task gets this interrupt mask when it is activated if it
does not have its own starting interrupt mask specified). The special
data type is defined within the OSEK Operating System to control
interrupt masks. The set of special OS attributes is introduced to
configure interrupt masks.
A G R E E M E N T
6.6 Local Variables Considerations

There are some peculiarities related to using local variables inside ISR
category 3. The following considerations cover this subject.
The EnterISR and LeaveISR functions assume that the stack frame is
defined on entry. Moreover, the stack pointer may be changed during the
execution of these functions. Thus, the use of local variables inside ISR
category 3 may lead to unpredictable behavior and a crash. Therefore,
the user is not permitted to use local variables inside ISR category 3.
Instead, the user may split the interrupt service routine into two
functions. The nested function should perform useful work, and may
have local variables. The outermost function should call the nested
function framed by the calls to EnterISR and LeaveISR services.
The example of correct code:
int __SciHandler(void)
{ /* The inner function with local variables */
char status; /* local variable to hold SCI status*/
int num; /* local variable to byte counter*/
... /* useful user’s code*/
}
ISR( SciHandler ) /* Interrupt service routine*/

{ /* No local variables defined*/
EnterISR(); /* Switch to the ISR stack */
__SciHandler(); /* Perform useful work to handle interrupt*/
LeaveISR();
}

Programming Issues
R E Q U I R E D
The example of the wrong code – local variables are allocated on the
task stack, but the stack pointer is changed by EnterISR after, therefore
references to the variables are invalid:
int __SciHandler(void)
{ /* The inner function without local variables */
... /* useful user’s code*/
}
ISR( SciHandler ) /* Interrupt service routine*/

{
char status; /* local variable to hold SCI status*/
int num; /* local variable to byte counter*/
A G R E E M E N T
EnterISR(); /* Stack Pointer is changed ! */
num = __SciHandler();/* Perform useful work to handle
interrupt*/
LeaveISR();
}
The following system configuration options affect the interrupt

management:
• EntryExitISR if the option is turned off, it is assumed
that there are no interrupts in the system
at all and the Operating System does not
have any interrupt handling mechanisms.
No interrupt management services are
implemented.
• InterruptMaskControl
if the option is turned off (while the
EntryExitISR option is turned on),
interrupt masks are not controlled by the
operating system. Services
EnableInterrupt, DisableInterrupt,
GetInterruptDescriptor are not
implemented.

R E Q U I R E D
• ISRCategory1 if the option is turned off, it is assumed

that there are no interrupts of category 1
in the system.
in the system.
in the system.
A G R E E M E N T
• UnorderedExceptions
if the option is turned on, it is possible to
handle unordered exceptions. This
attribute is intended for MPC only.
6.7.2 Data Types
management:
• IntDescriptorType The data type for logical interrupt

descriptors;
• IntDescriptorRefType The data type to refer variables of the

IntDescriptorType data type.
The only data types must be used for operations with interrupt masks.
OSEK OS provides the set of services for interrupt management. Also

some services may be used both on the task level and on the ISR level.
These services are shown in the Section 6-1 Interrupt Management

Services in the OSEK OS.

Programming Issues
R E Q U I R E D
Table 6-1. Interrupt Management Services in the OSEK OS
Interrupt Management Services
Registers the switching to the interrupt level and switch context to
EnterISR
the ISR stack
LeaveISR Registers the leaving of the ISR level
Enables interrupts in accordance with the given logical interrupt
EnableInterrupt
descriptor
Disables interrupts in accordance with the given logical interrupt
DisableInterrupt
descriptor
A G R E E M E N T
GetInterruptDescriptor Returns the current state of interrupts
Services allowed for use in ISR
ActivateTask Activates the specified task (puts it into the ready state)
GetTaskState Gets state of the task
SetEvent Sets event for the task
GetEvent Gets event of the task
Sends an unqueued message in WithCopy configuration to the
SendMessage
specified task
Delivers data of an unqueued message in WithCopy configuration to
ReceiveMessage
the application message copy
GetMessageStatus Returns the current status of the message
GetAlarmBase Gets alarm base characteristics
SetRelAlarm Sets relative alarm
SetAbsAlarm Sets absolute alarm
CancelAlarm Cancels alarm
GetAlarm Gets value in ticks before the alarm expires
CounterTrigger Increments a counter value
GetActiveApplicationMode Gets current application mode
6.7.4 Conventions
Within the application, an Interrupt Service Routine category should be

defined according to the following pattern:
ISR( ISRName )
{
...

R E Q U I R E D
The keyword ISR is the macro for compiler specific interrupt function
modifier, which is used to generate valid code to enter and exit ISR.
If the Interrupt Service Routine is defined by means of keyword ISR

usage, then it should be declared according to the following pattern:
DeclareISR( ISRName )
The same name shall be used for corresponding ISR object definition
(see Section 13.11 ISR Definition).
A G R E E M E N T
6.7.5 ISR Definition
To define common ISR parameters like ISR stack size and predefined
interrupt masks the corresponding OS properties should be specified in
the configuration file.
Definition of Interrupt related properties looks like:
OS <name> {
.....
IsrStackSize = <ISRStackSize>;
DisableInterruptMask = <DisableMask>;
EnableInterruptMask = <EnableMask>;
InitialMask = <InitialMask>;
TaskLevelMask = <TaskMask>;
.....
};
Definition of specific ISR object looks like:
ISR <ISRName>{
.....
CATEGORY = 2;
.....
};
See Section 13.3.3 Interrupt Related Properties and

Section 13.11 ISR Definition for the details.

Programming Issues
R E Q U I R E D
6.7.6 Constants
For initial interrupt mask the special constant is provided by the

operating system:
• INITIAL_INTERRUPT_DESCRIPTOR – the interrupt level to be

used during system startup, after user’s StartupHook and before
the first user task is running (see Section 11.5 Start-up
Routine). It is the same as InitialMask value.
A G R E E M E N T

R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 7. Resource Management
7.1 Contents
7.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
A G R E E M E N T
7.3 Access to Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
7.2 General
The resource management is used to coordinate concurrent accesses of
several tasks to shared resources, e.g. management entities
(scheduler), program sequences (critical sections), memory or hardware
areas. In general, the resource management is provided in all
Conformance Classes, but it is fully supported only beginning from the
BCC2 Conformance Class. In the lower Conformance Classes only the
scheduler is treated as the specific system resource which can be used
by tasks.
Resource management ensures that
• two tasks cannot occupy the same resource at the same time,
• priority inversion cannot arise while resources are used,
• deadlocks do not occur by use of these resources,
• access to resources never results in a waiting state.
The functionality of resource management is only required in the

following cases:
• full-preemptive tasks,
MOTOROLA Resource Management 85

Resource Management
R E Q U I R E D
• non-preemptive scheduling, if resources are also to remain

occupied beyond a scheduling point (except the scheduler
resource);
• non-preemptive scheduling, if the user intends to have the
application code executed under other scheduling policies too.
Resources cannot be occupied by more than one task at a time. The

resource that is now occupied by a task must be released before other
tasks can get it. The OSEK operating system ensures that tasks are only
transferred from the ready state into the running state if all resources
A G R E E M E N T
which might be occupied by that task during its execution have been
released. Consequently, no situation occurs in which a task tries to
access an occupied resource. The special mechanism is used by the
OSEK Operating System to provide such behavior, see
Section 7.3.1 Priority Ceiling Protocol for details.
The waiting state is not admissible for Extended Tasks while a resource
is occupied. It means that the task occupying a resource is not allowed
to call the WaitEvent service.
In case of multiple resource occupation, the task must request and

release resources following the LIFO principle (stack). For example, if
the task needs to get the communication hardware and then the
scheduler to avoid possible preempts, the following code may be used:
GetResource( SCI_res ); /* occupy the SCI resource */

... /* user’s code */
GetResource( RES_SCHEDULER ); /* occupy the scheduler resource */
ReleaseResource( RES_SCHEDULER ); /* release the scheduler */
ReleaseResource( SCI_res ); /* release the SCI resource */
OSEK OS resource management allows the user to prevent such

situations as priority inversion and deadlocks which are the typical
problems of common synchronization mechanisms in real-time
applications (e.g., semaphores).
86 Resource Management MOTOROLA

Resource Management
Access to Resources
R E Q U I R E D
7.3 Access to Resources
Before they are used, resources must be defined by the user at the
system configuration stage via the RESOURCE definition, see
Section 13.6 Resource Definition. Then the resource is declared in
the source file, where it will be used by means of a system declaration
statement DeclareResource (see Section 17.5 Resource
Management Services). After that, the task can occupy and release the
resource using the GetResource and ReleaseResource services. While
the resource is occupied, i.e., while the code between these services is
A G R E E M E N T
executed, this resource cannot be requested by another task.
In the OSEK Operating System, resources are ranked by priority. Each

resource is assigned statically to a user defined priority, which is called
Ceiling Priority. It is possible to have resources with the same
priorities, but the resource Ceiling Priority must be identical to or higher
than the highest task priority with access to this resource. This resource
feature supports the Priority Ceiling Protocol.
7.3.1 Priority Ceiling Protocol
The Priority Ceiling Protocol is implemented in the OSEK Operating

System as a resource management discipline.
The priority ceiling protocol elevates the task requesting a resource to a
priority level. This priority can simply be calculated during system
generation. As shown in Section 7.2 General the Ceiling Priority is:
• Identical to or higher than the highest task priority with access to

this resource (task T1);
• Lower than all other tasks of higher priority than task T1.
When a task occupies a resource, the system temporarily changes its

priority. It is automatically set to the Ceiling Priority by the resource
management. Any other task which might occupy the same resource
does not enter the running state due to its lower or equal priority. If the
resource occupied by the task is released, the task returns to its former
priority level. Other tasks which might occupy this resource can now
enter the running state.

Resource Management
R E Q U I R E D
The example shown in Figure 7-1 illustrates the mechanism of the

Priority Ceiling Protocol.
Ceiling release release

priority resource resource
running running
suspended ready running running suspended
suspended ready running suspended

A G R E E M E N T
ready running suspended
running ready running
request resource request resource
Figure 7-1. Priority Ceiling Protocol
In the figure above, Task 1 has the highest priority and Task 4 has the
lowest Priority. The resource has a priority greater than or equal to the
Task 1 priority. When Task 4 occupies the resource, it gets a priority not
less than Task 1, therefore it cannot be preempted by ready Task 1 until
it releases the resource. Just after the resource is released, Task 4 is
returned to its low priority and becomes ready, and Task 1 becomes the
running task. When Task 1, in its turn, occupies the resource, its priority
is also changed to the Ceiling Priority.
7.3.2 Scheduler as a Resource
The OSEK operating system treats the scheduler as a specific resource

which is accessible to all tasks. Therefore, a standard resource with the
predefined identifier RES_SCHEDULER is generated, and it is
supported in all Conformance Classes. If a task calls the services
GetResource or ReleaseResource with this identifier as a parameter,
the task will occupy or release the scheduler in the manner of a simple
resource. See the code example in Section 7.2 General.

Resource Management
Programming Issues
R E Q U I R E D
If a task wants to protect itself against preemptions by all other tasks, it
can occupy the scheduler exclusively. When it is occupied, interrupts are
received and processed normally. However, it prevents the rescheduling
of tasks.
NOTE: If a non-preemptive task gets the scheduler as a resource it must release

it before the point of rescheduling!
NOTE: If task got the scheduler and tries to yield CPU via the Schedule service
then Schedule service returns immediately without doing anything.
A G R E E M E N T
The following system configuration options control the resource

management in the OSEK OS:
• Resources this option defines whether resource

management is provided by the OS or not.
• FastResource the option can be specified by the user to
increase the system performance. If it is turned
on, the system will work faster. But this option
may be used only for debugged applications,
because errors related to incorrect access and
priority are not signalled. If this option is turned
on, less ROM and RAM are needed for
resources. But, if resource priorities have a
large difference (e.g. first resource has priority
1 and the second resource has priority 20) this
option does not lead to RAM saving.
• ResourceAccessCheck
the option defines whether E_OS_ACCESS
error code is returned by GetResource service
or not. If it is TRUE, then error code will be
returned in EXTENDED status based on task
definition in OIL-file. If the system has

Resource Management
R E Q U I R E D
STANDARD status or FastResource option

turned on or more than 8 resources (including
Scheduler) are defined in application, then this
option should be set to FALSE.
7.4.2 Data Types
The OSEK OS establishes the following data type for the resource
management:
A G R E E M E N T
• ResourceType the abstract data type for referencing a

resource;
The only data type must be used for operations with resources.
OSEK OS grants a set of services for the user to manage resources.

Detailed descriptions of these services are provided in
Section 17.5 Resource Management Services. Here only a brief list
of them is given.
This call serves to occupy the resource (critical section of the code, assigned
GetResource(1)
to the resource)
Releases the resource assigned to the critical section (to leave the critical
ReleaseResource
section)
1. E_OS_ACCESS error code is not returned by GetResource service if more than 8 resources (including
RES_SCHEDULER) are defined in the application or FastResource configuration option is turned on or Re-
sourceAccessCheck configuration option is turned off.
7.4.4 Resource Definition
To define a resource, the following definition statement should be

specified in the generation file:
RESOURCE <ResourceID> {
PRIORITY = <ResourcePriority>;
};

Resource Management
Programming Issues
R E Q U I R E D
For more details see Section 13.6 Resource Definition.
To refer to a resource, the declaration statement DeclareResource

should be used to declare the resource before its use.
DeclareResource looks like the following:
DeclareResource( ResourceType <ResourceID> )
This declaration is equivalent to the external declaration of variables.
A G R E E M E N T

Resource Management
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 8. Counters and Alarms
8.1 Contents
8.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
A G R E E M E N T
8.3 Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.4 Alarms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.2 General
The OSEK operating system comprises a two level concept to make use
of recurring events like periodic interrupt of timers, interrupt of the
sensors on rotating angles, or any recurring software events. To manage
such a situation, counters and alarms are provided by the OSEK
Operating System. The recurring events (sources) can be registered by
counters. Based on counters, the OSEK OS offers an alarm mechanism
to the application software. Counters and alarms are provided by the
OSEK OS in all Conformance Classes. Counter concept and counter
management system services are based in the ‘OSEK Operating
System, Concept’ v. 1.00, September 1995 and ‘OSEK Operating
System, Application Program Interface’ v. 1.00, September 1995.
MOTOROLA Counters and Alarms 93

Counters and Alarms
R E Q U I R E D
source source source source

1:1 n:1 1:n
counter counter counter counter
alarm alarm alarm alarm

alarm alarm
ActivateTask SetEvent
A G R E E M E N T
Task Task
Figure 8-1. Counters and alarms
8.3 Counters
Any event in the system can be linked with a counter, so that when the
event has occurred, the counter value is changed. A counter is identified
in the system via its symbolic name, which is assigned to the counter
statically at the configuration stage.
A counter is represented by a current counter value and some counter

specific parameters: counter initial value, conversion

constant and maximum allowed counter value. They are
defined by the user. The latter two parameters are constants and they
are defined at system generation time. The counter initial value is the
dynamic parameter. The user can initialize the counter with this value
and thereafter on task or on interrupt level advance it using the system
service CounterTrigger.
The maximum allowed counter value specifies the number after which
the counter rolls over. When a counter reaches its maximum allowed
possible value (or rolls over the predefined size - byte etc.), it starts
counting again from zero.
NOTE: The maximum allowed counter value is never really reached by a

counter. It means that if, for instance, value 5 is specified as the
maximum allowed one, 5 can never be read as a current counter value.
94 Counters and Alarms MOTOROLA

Counters and Alarms
Counters
R E Q U I R E D
If an alarm should be set for value 5, the maximum allowed counter value
must be 6.
The user also defines the maximal size of all counters in the system -
they can be byte-, word- or longword-sized. This is defined via the
system properties CounterSize.
The conversion constant can be used to convert the counter value into
an appropriate user specific unit of measurement, e.g. seconds for
timers, angular degrees for rotating axles. The conversion is done by the
user’s code and this parameter can be treated as a counter-specific
A G R E E M E N T
reference value.
The operating system provides the standard service GetCounterInfo to

read these counter specific values. Also the service GetCounterValue is
designed to read the current counter value.
At least one counter always exists in the system. This counter is used as
a system timer (the internal system clock). The system timer is a
standard counter with the following additions:
• the user must always define the system timer in an application;

• special constants are defined to describe counter parameters and
to decrease access time;
• the user defines the source of hardware interrupts for the system
counter.
In the system definition statement for the system timer the user should
define one of possible hardware interrupt sources. Parameters to tune
the hardware can be also defined by the user in this statement. This
possibility allows the user to exactly tune the system (see SECTION 15
Platform-Specific Features for details).
If hardware related parameters are defined, the code to initialize the

system timer hardware and the interrupt handler are automatically
provided for the user as a part of OSEK OS. In that case the user does
not have to care about handling of this interrupt and he/she can not
change the provided code. If the parameters are not defined the user
has to provide the code to initialize the hardware and handle the

Counters and Alarms
R E Q U I R E D
interrupt. In this case in ISR for the specified interrupt the service
CounterTrigger must be used to advance the counter.
NOTE: The system timer will not be triggered if the EntryExitISR property is
turned OFF!
The system timer has a predefined conversion constant that equals to

the number of ticks required to reach 10 milliseconds.
Hardware interrupts which are used to trigger counters have to be

handled in usual manner. To perform any actions with the counter the
A G R E E M E N T
application software processing the event should call the system service
CounterTrigger. This service must be called within the ISR frame
created by the EnterISR and LeaveISR services. It is not allowed to use
CounterTrigger in ISR category 1 (see section Section 6.4 ISR
Categories).
The user is free to assign one source exactly to one counter (1:1
relationship), several sources to one counter (n:1 relationship), or one
source to several counters (1:n relationship), see Figure 8-1. Meaning
that it is possible to advance the same counter in different software
routines.
User can alternatively increment the value of a counter using

AdvanceCounter service. This service advances the current value of the

counter by the number of ticks specified (CounterTrigger increments
counter by 1). If alarms are linked to the counter, the system checks
whether they expired during a specified number of ticks and performs
appropriate actions (task activation and event setting).
NOTE: AdvanceCounter service is not allowed to be used in ISR.
NOTE: AdvanceCounter service is not defined in the OSEK OS v.2.0 rev.1

specification. This is an extension of OSEK OS.
8.4 Alarms
The alarm management is built on top of the counter management. The
alarm management allows the user to perform link task activation or

Counters and Alarms
Alarms
R E Q U I R E D
event setting to a certain counter value. These alarms can be defined
as either single (one-shoot) or cyclic alarms.
The OSEK OS allows the user to set alarms (relative or absolute), cancel
alarms and read information out of alarms by means of system services.
Alarm is referenced via its symbolic name which is assigned to the alarm
statically at the configuration stage.
Examples of possible alarm usage are:
– ‘Activate a certain task, after the counter has been advanced
A G R E E M E N T
60 times’, or
– ‘Set a certain event, after the counter has reached a value of
90’.
The counter addressed in the first example might be derived from a timer
which is advanced every second. The task in the example is then
activated every minute. The counter addressed in the second example
might be derived from a rotating axle. The event is set on a 90 degree
angle.
The OSEK OS takes care of the necessary actions of managing alarms

when a counter is advanced.
Alarms are defined statically as with all other system resources. The
assignment of alarms to counters, as well as the action to be performed
when an alarm expires (task and event), are also defined statically. An
application can use an alarm after it has been defined and assigned to a
counter. Alarms may be either in the stop state or running state. To run
an alarm, the special system services are used, which set dynamic
alarm parameters to start it.
Dynamic alarm parameters are
• the counter value when an alarm has to expire.

• the cycle value for cyclic alarms.
An alarm can be started at any moment by means of system services

SetAbsAlarm or SetRelAlarm. An alarm will expire (and predefined
actions will take place) when a specified counter value is reached. This
counter value can be defined relative to the actual counter value or as

Counters and Alarms
R E Q U I R E D
an absolute value. The difference between relative and absolute alarms

is the following:
• Relative alarm expires when the specified number of counter ticks

has elapsed, starting from the current counter value at the
moment the alarm was set.
• Absolute alarm expires when the counter reaches the specified
number of ticks, starting from zero counter value no matter which
value the counter had at the moment the alarm was set. If the
specified number of ticks is less than the current counter value, the
A G R E E M E N T
counter will roll over and count until the specified value. If the
specified value is greater than the current value, the alarm will
expire just after the counter reaches the desired number. This is
illustrated by Figure 8-2. In the latter case, the total time until the
alarm expires is the sum of T1 and T2.
current specified maximum allowed

0 counter value absolute value counter value
T1
specified current
0 absolute value counter value
T2 T1
Figure 8-2. Two cases for the absolute alarm
If a cycle value is specified for the alarm, it is logged on again

immediately after expiry with this relative value. Specified actions (task
activation or event setting) will occur when the counter counts this
number of ticks, starting from the current value. This behavior of the
cyclic alarm is the same both for relative and absolute alarms. If the cycle
value is not specified (it equals zero) the alarm is considered as a single
one.

Counters and Alarms
Programming Issues
R E Q U I R E D
The following system configuration options affect the counter and alarm
management:
• Counters This option defines whether counters are

provided by the OS or not.
• CounterSize This option defines the size of all counters. The
A G R E E M E N T
valid values are 8, 16 and 32 which conform to
the byte, word or long word size of counters.
• Alarms This option defines whether alarms are
provided by the OS or not.
• AlarmList If this option is turned on, the running alarms
are linked into a list which decreases the time
for alarm handling.
• AlarmDeltaList If this option is turned on, the running alarms
are linked into an ordered alarm delta-list which
significantly decreases the time for
CounterTrigger service if too many alarms are
connected with the same counter (more than
10). The time for alarm management services
will be increased. Note that this option will be
turned off if the AlarmList option is turned on.
• CyclicAlarm If this option is turned on, the cyclic alarms are
supported. Otherwise, no one alarm may be
cyclic, which decreases RAM usage for alarm
control blocks as well as decreasing code
usage, and advances timing of alarms services.
This option is turned on by default.
• MinAlarmRAM If this option is turned on, the alarm handling is
optimized for memory (RAM). Otherwise, alarm
handling is optimized for speed. When turned

Counters and Alarms
R E Q U I R E D
on, the alarm control block is significantly

decreased, especially when AlarmList option is
turned off. This option is turned off by default.
8.5.2 Data Types
The following data types are established by OSEK OS to work with

counters:
• CtrRefType the data type references a counter

A G R E E M E N T
• TickType the data type represents a counter value in

system ticks
• TickRefType the data type references data corresponding to
the data type TickType
• CtrInfoType this data type represents a structure for storage
of counter characteristics. This structure has
the following fields:
– maxallowedvalue maximum possible allowed count value;
– ticksperbase number of ticks required to reach a
counter-specific significant unit;
– mincycle minimum allowed number of ticks for a
cyclic alarm (only for system with

Extended Status).
All fields have the data type TickType. The following code may illustrate
usage of this data type:
CtrInfoType CntData;
TickType maxV, minC, cons;
GetCounterInfo( CntID, &CntData );
maxV = CntData.maxallowedvalue;
minC = CntData.ticksperbase;
cons = CntData.mincycle;
• CtrInfoRefType this data type references data corresponding to
the data type CtrInfoType.
The following data type is established by OSEK OS to work with alarms:

Counters and Alarms
Programming Issues
R E Q U I R E D
• AlarmBaseType this data type represents a structure for storage
of alarm characteristics. It is the same as
CtrInfoType;
• AlarmBaseRefType
this data type references data corresponding to
the data type AlarmBaseType;
• AlarmType the data type represents an alarm element.
8.5.3 Counters and Alarm Generation
A G R E E M E N T
To generate a counter in an application, the COUNTER definition is
used, it looks like the following:
COUNTER <CounterID> {
MINCYCLE = <mincycle>;
MAXALLOWEDVALUE = <maxallowedvalue>;
TICKSPERBASE = <ticksperbase>;
};
To define system timer hardware-specific parameters, the following

properties should be defined in the OS definition statement:
OS <name> {
.....
SysTimer = <SysTimerSupport>;
HardwareType = <TypeOfTimer>;
Prescaler = <PrescalerDefined>;
PrescalerValue = <PrescalerValue>;
TimerModulo = <TimerModuloDefined>;
TimerModuloValue = <TimerModuloValue>;
.....
};
The system timer hardware parameters are described in detail in the

section Section 13.3.5 Counters and Alarms Related Attributes.
ALARM <AlarmID> {
ACTION = <Acion>;
COUNTER = <CounterID>;
TASK = <TaskID>;
[ EVENT = <Event>; ]
};

Counters and Alarms
R E Q U I R E D
Detailed counter and alarm generation statements are described in

Section 13.8 Counter Definition and Section 13.9 Alarm Definition.
The declaration statements DeclareCounter and DeclareAlarm should

be used to declare an element (counter or alarm) before it is used:
DeclareCounter( CtrRefType <CounterID> )
DeclareAlarm looks like the following:

DeclareAlarm( AlarmType <AlarmID> )
A G R E E M E N T
These declarations are equivalent to the external declaration of

variables.
OSEK OS grants a set of services for the user to manage counters and
alarms. Detailed descriptions of these services are provided in
Section 17 System Services. Here only a brief list is given.
Table 8-1. Counter and Alarm Management Run-time Services

InitCounter Sets the initial value of the counter

CounterTrigger Increments the counter value
GetCounterValue Gets the counter current value
GetCounterInfo Gets counter parameters
AdvanceCounter(1) Alternatively increments the value of a counter
SetRelAlarm Sets the alarm with a relative start value
SetAbsAlarm Sets the alarm with an absolute start value
Cancels the alarm: the alarm is transferred into the STOP

CancelAlarm
state
GetAlarm Gets the time left before the alarm expires
GetAlarmBase Gets alarm parameters

1. This service is not defined in the OSEK OS v.2.0 rev.1 specification. This is an extension
of OSEK OS.

Counters and Alarms
Programming Issues
R E Q U I R E D
Examples of the run-time service usage are provided in
8.5.5 Constants
For the system counter, which is always a time counter, special

constants are provided by the operating system:
• OSMAXALLOWEDVALUE
maximum possible allowed value of the
A G R E E M E N T
system timer in ticks;
• OSTICKSPERTIME, number of ticks that are required to reach
10 OSTICKPERBASE milliseconds in the
system counter;
• OSTICKDURATION duration of a tick of the system counter in
nanoseconds;
• OSMINCYCLE minimum allowed number of ticks for a
cyclic alarm (only for system with
Extended Status).

Counters and Alarms
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 9. Events
9.1 Contents
9.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .105
A G R E E M E N T
9.3 Events and Scheduling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .106
9.2 General
Within the OSEK operating system, tasks can be synchronized via
occupation of a resource (see Section 7 Resource Management).
Another means of synchronization is the event mechanism, which is
provided for Extended Tasks only. Special fields in the task node of an
Extended Task are provided for event management in the OSEK OS
(see Section 4.7.2 Task Control Block). Events are the only
mechanism allowing a task to enter the waiting state.
An event is an object managed by the OSEK Operating System, which
is able to store binary data. The interpretation of the event is up to the
user. Examples are: the signalling of a timer’s expiry, the availability of a
resource, the receipt of a message, etc.
Within the operating system, events are not independent objects, but
allocated to Extended Tasks. Each Extended Task has a definite
number of events – 8 or less (in fact, the byte size is used for event
management in the current OSEK OS implementation.). Events are
represented by two event masks – byte-sized fields in the task node
(See Section 4.7.2 Task Control Block). One field is the mask of
events the task is waiting for. This mask can be set and cleared only by
the task-’owner’ (a ‘private’ mask). The second field (a ‘public’ mask)
contains the mask of the events, which are set for the task by other
tasks. When activating an Extended Task, all its events are cleared.
MOTOROLA Events 105

Events
R E Q U I R E D
An Extended Task can wait for several events simultaneously and

setting at least one of them causes the task to be transferred into the
ready state. When a task wants to wait for one event or several ones, the
corresponding bits in its ‘private’ event mask are set. The system service
WaitEvent is designed to force a task to wait for an event. When another
task sets an event, it sets the specified bits of the ‘public’ event mask,
and if some bits in both ‘private’ and ‘public’ masks are the same, the
task is transferred into the ready state. The task can clear its own events
by clearing the ‘private’ event mask.
A G R E E M E N T
Various system services are available to manipulate events, depending

on whether the dedicated task is the ‘owner’ of the event or another task,
which does not necessarily have to be an Extended Task. All tasks can
set any events of any Extended Task. Only the appropriate Extended
Task (the owner of the particular event mask) is able to clear events and
to wait for the setting (receipt) of events. Basic Tasks must not use the
operating system services for clearing events or waiting for them.
An alarm can also be set for an Extended Task, which sets an event at
a certain time. Thus, the Extended Task can delay itself (see example in
Section 17.7.7 Examples of Using Events).
It is not possible for an interrupt service routine or a Basic Task to wait

for an event, since the receiver of an event is an Extended Task in any
case. On the other hand, any task or ISR can set an event for an
Extended Task, and thus inform the appropriate Extended Task (its
identification must be known) about any status change via this event.
To have events in the system, the configuration option Events must be

turned on.
9.3 Events and Scheduling

An event is an exclusive signal which is assigned to an Extended Task.
For the scheduler, events are the criteria for the transition of Extended
Tasks from the waiting state into the ready state. The operating system
provides services for setting, clearing and interrogation of events, and
for waiting for events to occur.
106 Events MOTOROLA

Events
Events and Scheduling
R E Q U I R E D
Extended Tasks are in the waiting state if an event for which the task is
waiting has not occurred. If an Extended Task tries to wait for an event
and this event has already occurred, the task remains in the running
state.
Figure 9-1 illustrates the procedures which are effected by setting an

event: Extended Task 1 (with higher priority) waits for an event.
Extended Task 2 sets this event for Extended Task 1. The scheduler is
activated. Subsequently, Task 1 is transferred from the waiting state into
the ready state. Due to the higher priority of Tasks 1 this results in a task
switch, Task 2 being preempted by Task 1. Task 1 resets the event.
A G R E E M E N T
Thereafter Task 1 waits for this event again and the scheduler continues
execution of Task 2.
Scheduler
Event of
Extended task 1 set
reset reset
Extended task 1
waiting running reset event wait for event waiting
Extended task 2
running set event ready running
Figure 9-1. Synchronization by events in case of full-preemptive
scheduling
If non-preemptive scheduling is supposed, rescheduling does not take

place immediately after the event has been set, as shown in Figure 9-2.
MOTOROLA Events 107

Events
R E Q U I R E D
Scheduler
Event of
Extended task 1 set
reset reset
Extended task 1
waiting ready reset event running wait for event waiting
Extended task 2
running set event rescheduling ready running
A G R E E M E N T
Figure 9-2. Synchronization by events in case of full-preemptive

scheduling
The only system configuration option Events controls event

management in the system. If it is turned off events are not implemented.
9.4.2 Data Types
The OSEK Operating System establishes the following data types for the
event management:
• EventMaskType The data type of the event mask;

• EventMaskRefType The data type to refer to an event mask.
The only data types must be used for operations with events.
9.4.3 Events Definition
To generate a counter in an application the EVENT definition is used, it

looks like the following:
EVENT <Event> {
108 Events MOTOROLA

Events
Programming Issues
R E Q U I R E D
MASK = 0x01;
};
To refer to an event the declaration statement DeclareEvent should be

used to declare the event before it is used.
DeclareEvent looks like the following:

DeclareEvent( EventMaskType <Event> )
A G R E E M E N T
OSEK OS grants a set of services for the user to manage events. A
detailed description of these services is provided in Section 17.7 Event
Management Services. Here only a brief list is given.
Table 9-1. Event Management Run-time Services

SetEvent Sets events of the given task according to the event mask
ClearEvent Clears events of the calling task according to the event mask
GetEvent Gets the current event setting of the given task
WaitEvent Transfers the calling task into the waiting state until specified events are set
Examples of the run-time services usage are provided in section
Section 17.7 Event Management Services.
9.4.5 Additional Usage
Note that it is possible to use bits in memory fields assigned for events
for some internal task’s needs as bit flags. In case of using events in the
system in every Extended task’s control block special fields are created.
If a task uses less than eight events, it is possible to use SetEvent and
ClearEvent system services with appropriate masks to manipulate the
internal task’s bit flags.
See the following example:
DeclareTask( TASK_A )
DeclareTask( TASK_C )
MOTOROLA Events 109

Events
R E Q U I R E D
/* event masks for internal flags */

/* (generated by SG tool) */
DeclareEvent( X_FLG ) /* 0x80 */
DeclareEvent( Y_FLG ) /* 0x40 */
DeclareEvent( Z1_FLG ) /* 0x20 */
DeclareEvent( Z2_FLG ) /* 0x10 */
TASK( TASK_A )
{
EventMaskType x, y, z1, z2;
z1 = Z1_FLG; z2 = Z2_FLG;
int speed;
A G R E E M E N T
...
if (speed == LIMIT)
{
x = X_FLG;
SetEvent( TASK_A, x );
}
GetEventMask( TASK_A, &x );

if ((x & X_FLG) != 0 ) ClearEvent( z1 );
else SetEvent( TASK_A, z2 );
if ((x & Y_FLG) == 0 ) ChainTask( TASK_C );
...
}
In the example the task uses four most significant bits of the event field
as its internal bit flags. Least significant bits are free and they can be
used for ‘external’ OSEK OS events. But such approach requires more
attention from the user to avoid occasionally changing of ‘internal’ events
instead of ‘external’ ones and visa versa.
Note that access to that binary data is performed only via the system
services for event management.
110 Events MOTOROLA

R E Q U I R E D
Section 10. Communication
10.1 Contents
10.2 Message Concept. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .111
A G R E E M E N T
10.3 Unqueued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .113
10.4 Queued Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .115
10.2 Message Concept

In the OSEK Operating System, communication between application
tasks takes place via messages. Communication concept and message
management system services are based on the ‘OSEK Communication’
v. 2.1, revision 1, June 1998. Messages are stored in Message
Objects (MO) which are handled by the operating system. A
distinction is made between the following:
• Unqueued Messages and
• Queued Messages
An Unqueued Message represents the current value of a system

variable, e.g. engine temperature, wheel speed, etc. Unqueued
Messages are not buffered but overwritten with their actual values. The
receive operation reads the Unqueued Message value. Thereby the
message data is not consumed.
In contrast, a Queued Message contains an event information, e.g.

‘engine temperature exceeds a certain limit’. Queued Messages are
buffered with the send operation and consumed with a receive
operation.
MOTOROLA Communication 111

Communication
R E Q U I R E D
In OSEK OS, message objects are referenced by tasks via the unique
identifiers defined by the user at the configuration stage.
The OSEK Operating System ensures data consistency of message

data during task operation, uniform in all types of scheduling. The
received message data remains unchanged until a further receive
operation is performed, unless the task or function using the data
overwrites the data with a direct access operation.
OSEK supports two types of communication between tasks: 1:1 and 1:N
A G R E E M E N T
communication.
• 1:1 communication means that only one task receives the

message;
• 1:N communication means that N tasks receive the same
message.
Both types of messages, Unqueued and Queued Messages, can be

used for 1:1 and 1:N communication, for local (ECU-internal) and
network communication.
As an option, task activation or event signalling can be defined statically

to be performed at message arrival to notify a task. Task activation or
event signalling can be used to inform tasks that want to act immediately
on new message information. There is no special operating system

service to wait for messages, but the normal event mechanism is used.
Only one notification method can be assigned for certain messages.
Alarms can be assigned statically to message objects (only one alarm

per message object). If the message does not arrive during the time
period specified via the ALARMRESETTIME property in the MESSAGE
definition statement, the alarm counter expires and an associated task is
activated or an event is signalled. Whenever a message arrives, the
alarm is restarted. This feature can be used to supervise whether
Unqueued Messages are updated or Queued Messages arrive on time.
It is possible to assign both an alarm and task notification (task activation

or event signalling) to a particular message object.
112 Communication MOTOROLA

Communication
Unqueued Messages
R E Q U I R E D
Table 10-1. Features of the Message Concept
Unqueued Message QueuedMessage
No buffering Buffering in a FIFO-queue
No consumption of message Consumption of messages
Direct access possible in non-preemptive

No direct access possible (always copies)
systems (no copies)
Static definition of task activation or event signalling
Static definition of a message alarm
A G R E E M E N T
OSEK OS communication services provide all means for local message
transfer within single ECU. To transfer data over the network, the OSEK
Communication System (COM) will be used, which is designed to handle
all other types of communication through the network. And OSEK OS
communication services provide an interface for application tasks to
exchange data. Thus, messages serve as interface for both ECU
internal and network communication. Uniform services with identical
interfaces are offered (network transparency).
10.3 Unqueued Messages

Unqueued Messages represent the current value of a state variable.
Tasks can have three various access type to Unqueued Messages –
read only (receive), write only (send) and full read/write access. The
send operation overwrites the current value of a message, i.e.
Unqueued Messages are not buffered. The receive operation reads the
current value of a Unqueued Message whereby the message data is not
consumed.
These services ensure:
• the consistent writing and reading of message data within the

send and receive operation (also in preemptive systems) and
• the consistency of data while tasks and functions (subprograms)
use the message data.

Communication
R E Q U I R E D
An Unqueued Message can have a default value which is assigned

statically to the message at the configuration stage. This value is
returned when the message is received first time without prior send
operation (see Section 13.10.1 Object Attributes and example in
Section 10.5.5 Usage of Messages for details regarding Unqueued
Message default value).
Unqueued Messages may be either with or without a local copy of a

message. It indicates statically with message property WithCopy set to
TRUE or set to FALSE respectivelly. Last case is called WithoutCopy for
A G R E E M E N T
convenience. The distinction between these kinds of Unqueued

Messages is the following:
• When the WithCopy configuration is used, the Unqueued

Message item is copied from the task data space into the message
item for send operation, and from the message item to the task
data space for receive operation. The message body is copied
consistently, i.e. the operating system provides atomic behavior of
the send-receive operations. The default value is copied from the
user’s-defined area into the message body during system start-up.
• When the WithoutCopy configuration is used, the Unqueued
Message item is not copied from the task data space into the
message item. Instead, the task-sender updates the message
body directly via de-referencing of the pointer and writing the data
at the pointer address, and the task-receiver uses the message
body by means of de-referencing the pointer and reading the data.
The operating system doesn’t provide atomic behavior of the
send-receive operations, and this consistency is to be provided by
the user’s code.
Unqueued Messages are used similar to C-language variables (direct

access e.g. in a C-language assignment or in a C-language expression).
The access privileges (send, receive or send/receive) defined for a
message also determine which direct access operations are allowed.
1:N communication for Unqueued Messages does not have any

difference from 1:1 communication, since any task can read the
Unqueued Messages if its identifier is known.

Communication
Queued Messages
R E Q U I R E D
To have Unqueued Messages in the system the configuration option
UnqueuedMessages must be turned on.
10.4 Queued Messages

In contrast to Unqueued Messages, Queued Message objects can
temporarily store several messages. The temporary storage follows the
FIFO principle, i.e. messages are received in the same order as they
were sent. During the send operation the message item is copied from
the task data space into the message FIFO area at the write pointer.
A G R E E M E N T
During the read operation the message item is copied from the FIFO
area at the read pointer into the receiving task space. The data is copied
consistently, i.e. the operating system provides atomic behavior of the
send-receive operations. The FIFO area is circular. It is illustrated in
Figure 10-1. Message “msg1” is consumed from the Queued Message
object by a task, and other message items are “moved” in the Queued
MO towards the top (in fact, read and write pointers are changed). After
the message item “msg1” was consumed, new message “msg5” is
written by a task at the empty location (the last one). If an Queued
Message object has no memory capacity left to store the new message,
the oldest message is overwritten - in Figure 10-1 “msg2” is overwritten
by the message item “msg6” in spite that “msg2” has not been
consumed. The overwriting process is indicated both to sender and
receiver in systems with Extended Status by means of return codes
while send or receive services are executed by a task.
A Queued Message is characterized by the length of a single message

item and by the depth of a queue. These parameters are defined by the
user at the configuration stage.

Communication
R E Q U I R E D
“msg1” is consumed
by a task “msg1”
read read read
pointer pointer pointer
... “msg2” “msg2”
write
“msg2” “msg3” pointer “msg3”
write “msg3” write “msg4” “msg4”

pointer pointer ...
“msg4” “msg5”
A G R E E M E N T
1 2 3
“msg5” “msg6”
New message “msg5” New message “msg6”
is written by a task into will overwrite “msg2” of
the Queued MO the Queued MO
Figure 10-1. Operations with Queued Messages
Event communication includes an implicit synchronization of the

communication partners since an Queued Message must be sent before
it can be received. When the receive operation is performed, an Queued
Message is removed from the message object and is thus consumed.
In case of multiple receivers (1:N communication) OSEK OS ensures

that no receiver may receive a new message, until all receivers will
complete the reception of the current message. The last receiver
consumes the message.
To have Queued Messages in the system, the configuration option

QueuedMessages must be turned on.
The following system configuration options are intended to control

communication features:

Communication
Programming Issues
R E Q U I R E D
• UnqueuedMessages This option allows Unqueued Messages
in the system;
• UnqueuedMsgDefaultValue
This option allows Unqueued Messages
to have default values;
• QueuedMessages This option allows Queued Messages in
the system;
• QueuedMsgOneToN If this option is turned on, 1:N Queued
Messages are allowed;
A G R E E M E N T
• ActivateOnMsg If this option is turned on task activation
on message arrival is supported;
• AlarmOnMsg If this option is turned on an alarm can be
linked to message arrival;
• SetEventOnMsg If this option is turned on event setting is
allowed on message arrival.
10.5.2 Identifiers
The following names are used in the OSEK Operating System for work
with messages:
• SymbolicName This is an unique name representing a
message. It only can be used in
conjunction with calls of the message
service. A SymbolicName need not be a
data type. Variables or constants of
SymbolicName can be declared or used.
• AccessName This is a unique name defining access to
a message object. Depending on the
chosen configuration, a distinction is
made between the following AccessName
scheme:
WithCopy configuration:
A application variable exists as a local
copy of the message. The name of the

Communication
R E Q U I R E D
variable is the AccessName. This variable

contains a copy of the corresponding
message object.
WithoutCopy configuration:
The message object data is accessed via
the AccessName. This AccessName is a
static link: it refers directly to the message
object data. The AccessName refers to
the same data (RAM) as the message
object.
A G R E E M E N T
10.5.3 Message Definition
Each message in an application is generated by means of using

statements like the following:
MESSAGE <MsgName> {
ACTION = <MessageAction>;
TYPE = <MessageType>;
ITEMTYPE = <type>;
ITEMS = <BufferSize>;
ALARMRESETTIME = <TimeOut>;
ALARMRESET = <AlarmId>;
StartupAlarm = <Start>;
TASK = <TaskId>;
EVENT = <EventMask>;
ReceiverNum = <NumberOfReceivers>;
DefaultValue = <InitialValue>;
};
The MESSAGE definition statement defines either Unqueued or Queued

message according to TYPE property setting. The TASK and EVENT
references are designed to link the action with the message arrival. The
ALARMRESET attribute is used to link an alarm with message arrival –
when the message arrives the alarm is restarted. In detail message
configuration statements is described in Section 12 System
Configuration.
There is no constructional elements defined for messages.

Communication
Programming Issues
R E Q U I R E D
OSEK OS grants a set of services for the user to manage tasks. Detailed
descriptions of these services are provided in section
Section 17.8 Communication Management Services. Here only a
brief list is presented.
Table 10-2. Task Management Run-time Services

SendMessage Updates the unqueued message
A G R E E M E N T
ReceiveMessage Gets the unqueued message
Sets the given message object status as busy if it is

GetMessageResource
not already so
ReleaseMessageResource Sets off the message object from busy
GetMessageStatus Returns the current status of the message
Examples of the run-time services usage are provided in

10.5.5 Usage of Messages
Messages are identified via a symbolic name. This identifier is used for
references to the message when the system service is used.
If the message is used in the WithCopy configuration, then the variable

to hold message data is defined within the user’s code by means of using
the regular C-language definitions. Because system generator always
create typedef declaration for every message, it is recommended to use
this declaration for definition of variables which hold message data. By
convention, this typedef consists of prefix OSMSG and name of the
message <MsgName>, defined in MESSAGE description in OIL file.
For example, if the user defines the message MsgA having type int, then
user’s code may access message using the following statements:
OSMSGMsgA _MsgA;
ReceiveMessage( MsgA, _MsgA );

Communication
R E Q U I R E D
if( _MsgA == 2 ) { _MsgA = 1; }

SendMessage( MsgA, _MsgA );
If the message is configured without WithCopy property, then the pointer

to the message body should be defined within the user’s code using
regular C-language statements. Again, because system generator
creates typedef declaration for message item, it is recommended to use
this declaration for definition of pointer, which is used access message
data.
For example, if the user defines the WithoutCopy message MsgB, having
A G R E E M E N T
the type int, then user’s code may access message using the following
statements:
OSMSGMsgB*_MsgB = (OSMSGMsgB*)&OSMsgB->msg;
ReceiveMessage( MsgB, _MsgB );

if( *_MsgB == 2 ) { *_MsgB = 1; }
SendMessage( MsgB, _MsgB );
The following example demonstrates Unqueued Message default value

definition.
/* Source C-file */
const int myMsgADefValue = 0; /* MsgA default value */
/* Configuration OIL-file */
MESSAGE MsgA {
TYPE = UNQUEUEDMESSAGE;
ITEMTYPE = "int";
ITEMS = 1;
DefaultValue = "&myMsgADefValue";
};

R E Q U I R E D
Section 11. Error Handling and Special Routines
11.1 Contents
11.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
A G R E E M E N T
11.3 Hook Routines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .121
11.4 Error Handling. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .126
11.5 Start-up Routine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .128
11.6 Application Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
11.7 System Shutdown. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .130
11.2 General
The OSEK Operating System provides the user with tools for error
handling and simple debugging at run time. These are special hook
routines with names specified by OSEK OS that are to be developed by
the user. In this section, error handling at the system configuration stage
is not considered; it is described in Section 12 System Configuration.
11.3 Hook Routines

The OSEK Operating System supports system specific hook
routines to allow user-defined actions within the OS internal
processing.
These hook routines in OSEK OS are:
• Called by the operating system, in a special context depending on

the implementation of the operating system;
MOTOROLA Error Handling and Special Routines 121

Error Handling and Special Routines
R E Q U I R E D
• Higher priority than all tasks;

• Using an implementation-dependent calling interface;
• Part of the operating system, but user defined;
• Implemented by the user;
• Standardized in interface per OSEK OS implementation, but not
standardized in functionality (environment and behavior of the
hook routine itself), therefore usually hook routines are not
portable;
A G R E E M E N T
• Only allowed to use a subset of API functions;

• Optional.
In the OSEK OS hook routines are intended for
• System startup. The corresponding hook routine (StartupHook) is

called after the operating system startup and before the scheduler
is running;
• Tracing or application dependent debugging purposes as well as
user defined extensions of the context switch;
• Error handling. The corresponding hook routine (ErrorHook) is
called if a system call returns a value not equal to E_OK;
• System shutdown. The corresponding hook routine

(ShutdownHook) is called.
The OSEK OS provides the following hook routines – ErrorHook,

PreTaskHook, PostTaskHook, StartupHook, ShutdownHook,
IdleLoopHook1. The user must create the code of these routines, OSEK
OS only provides description of function prototypes.
• ErrorHook – this hook is called by the Operating System at the end

of a system service which has a return value not equal to E_OK
(see Section 11.4.1 Error Interface). It is called before returning
to the task level or the ISR level.
1. IdleLoopHook hook routine is not introduced in OSEK OS standard. It is an extension of OSEK

OS.
122 Error Handling and Special Routines MOTOROLA

Hook Routines
R E Q U I R E D
• PreTaskHook – this hook is called before the operating system
enters the context of the task. This hook is called from the
scheduler when it passes control to the given task. It may be used
by the application to trace the sequences and timing of the tasks’
execution.
• PostTaskHook – This hook is called after the operating system
leaves the context of the task. It is called from the scheduler when
it switches from the current task to another. It may be used by the
application to trace the sequences and timing of tasks’ execution.
A G R E E M E N T
• StartupHook – This hook is called after the operating system
startup and before the scheduler is running. It may be used by the
application to perform initialization actions, task activation, alarm
setting.
• ShutdownHook – This hook is called when the service ShutdownOS
has been called. It is called before the Operating System shuts
down itself.
• IdleLoopHook – This hook is called from scheduler idle loop (see
Section 5.2 General). It is not possible to call any OSEK OS
directives from this hook. Hardware dependent code (like
manipulation with COP registers) may be placed here.
Time stamps can be integrated individually into the application software
with the help of hook routines OSPreTask and OSPostTask. The user
can set time stamps enabling him to trace the program execution at the
following locations before calling operating system services:
• When activating or terminating tasks;

• At explicit points of rescheduling ( ChainTask, Schedule);
The Operating System does not need to include a time monitoring

feature which ensures that each task or a specific task, e.g. with the
lowest priority, has been activated after a defined maximum time period.
The user can optionally use the hook routines or establish a watchdog
task that takes ‘one-shot displays’ of the operating system status.
See examples of programming techniques using the hook routines in

Section 17.9 Operating System Execution Control.

R E Q U I R E D
Some system services may be called by the hook routines:
Table 11-1. OSEK OS system services for hook routines

Hook routines
Service Error PreTask PostTask Startup Shutdown
Hook Hook Hook Hook Hook
DeclareTask allowed allowed allowed allowed allowed
ActivateTask -- -- -- allowed --
A G R E E M E N T
TerminateTask -- -- -- -- --
ChainTask -- -- -- -- --
Schedule -- -- -- -- --
GetTaskId allowed(1) allowed allowed -- --
GetTaskState allowed allowed allowed -- --
GetTCBInfo allowed(2) allowed allowed -- --
EnterISR -- -- -- -- --
LeaveISR -- -- -- -- --
EnableInterrupt -- -- -- -- --
DisableInterrupt -- -- -- -- --
GetInterruptDescriptor allowed allowed allowed -- --

DeclareResource -- -- -- -- --
GetResource -- -- -- -- --
ReleaseResource -- -- -- -- --
DeclareEvent allowed allowed allowed -- --
SetEvent -- -- -- -- --
ClearEvent -- -- -- -- --
GetEvent allowed allowed allowed -- --
WaitEvent -- -- -- -- --
InitCounter -- -- -- -- --
CounterTrigger -- -- -- -- --
AdvanceCounter -- -- -- -- --
GetCounterValue -- -- -- -- --

Hook Routines
R E Q U I R E D
Table 11-1. OSEK OS system services for hook routines
Hook routines
Service Error PreTask PostTask Startup Shutdown
Hook Hook Hook Hook Hook
GetCounterInfo -- -- -- -- --
DeclareAlarm allowed allowed allowed -- --
GetAlarmBase allowed allowed allowed -- --
GetAlarm allowed allowed allowed -- --
A G R E E M E N T
SetRelAlarm -- -- -- -- --
SetAbsAlarm -- -- -- -- --
CancelAlarm -- -- -- -- --
SendMessage -- -- -- -- --
allowed for
ReceiveMessage unqueued -- -- -- --
messages
GetMessageResource -- -- -- -- --
ReleaseMessageResource -- -- -- -- --
GetMessageStatus allowed -- -- -- --
GetActiviveApplicationMode allowed allowed allowed allowed allowed
StartOS -- -- -- -- --
ShutdownOS -- -- -- -- --
1. It may happen that currently no task is running. In this case the service returns the task Id INVALID_TASK.
2. It may happen that currently no task is running. In this case the service returns E_NOFUNC return value if OSEK
OS has the Extended Status.

R E Q U I R E D
NOTE: It is not possible to call any OSEK OS services from IdleLoopHook hook
routine.
11.4 Error Handling
11.4.1 Error Interface
The hook routine ErrorHook is provided to handle temporarily and

A G R E E M E N T
permanently occurring errors within the OSEK Operating System. Its

basic framework is predefined and must be completed by the user. This
gives the user a choice of efficient centralized or decentralized error
handling.
Three different kinds of errors are distinguished in OSEK OS:
• Application errors – the Operating System could not execute the

requested service correctly, but assumes the correctness of its
internal data. In this case, centralized error treatment is called.
Additionally, the Operating System returns the error by the status
information for decentralized error treatment.
• Fatal errors – the Operating System can no longer assume
correctness of its internal data. In this case OSEK OS calls the

centralized system shutdown.
The special system routine ShutdownOS is intended to shut down the

system in case of the fatal error. ShutdownOS may be called both by the
user and by the system on experiencing a fatal error. These service
routines are provided by the OSEK Operating System as opposed to the
ErrorHook routine, which should be written by the user. User hook
ShutdownHook is called by ShutdownOS.
The OSEK OS error service is called with a parameter that specifies the
error. It is up to the user to decide what to do, depending on which error
has occurred. The OSEK Operating System specifies the following
errors:

Error Handling
R E Q U I R E D
Table 11-2. OSEK OS Error codes
Error Name Value Description
Common Error Codes
E_OK 0 No error, successful completion
E_OS_ACCESS 1 Access to the service/object denied
E_OS_CALLEVEL 2 Access to the service from the ISR is not permitted
E_OS_ID 3 The object ID is invalid
E_OS_LIMIT 4 The limit of services/objects exceeded
E_OS_NOFUNC 5 The object is not used, the service is rejected
A G R E E M E N T
E_OS_RESOURCE 6 The task still occupies the resource
E_OS_STATE 7 The state of the object is not correct for the required service
E_OS_VALUE 8 A value outside of the admissible limit
E_OS_SYS_STACK 10 Internal stack overflow
E_COM_BUSY 1 Message in use by application task/function
E_COM_ID 3 Invalid message name passed as parameter
E_COM_LIMIT 4 Overflow of FIFO associated with queued messages
Rejected service call, message object locked due to a pending
E_COM_LOCKED 7
operation
E_COM_NOMSG 9 No message available
Errors committed by the user in direct conjunction with the Operating
System can be intercepted to a large extent via the Extended Status of
the Operating System, and displayed. This results in an extended
plausibility check on calling OS services.
11.4.2 Extended Status
The OSEK Operating System version with Extended Status requires

more execution time and memory space than the run time version, due
to the additional plausibility checks it offers. However, many errors can
be found in a test phase. After they have all been eliminated, the system
can be recompiled with the run time version.
The following example can illustrate Extended Status usage:

R E Q U I R E D
• If a task is activated in the run time, either ‘OK’ or ‘Task already

activated’ is returned. Moreover, in the Extended Status version,
the additional status like ‘Task not defined’, ‘Maximum number of
tasks already activated’ or ‘Stack overflow’, etc. can be returned.
These extended messages must no longer occur in the target
application at the time of execution, i.e., the corresponding errors
are not intercepted in the operating system’s run time version.
11.4.3 Possible Error Reasons

A G R E E M E N T
Errors in the application software are typically caused by:
• Errors on handling the operating system, i.e. incorrect

configuration / initialization / dimensioning of the operating system
or non-observance of restrictions regarding the OS service.
• Error in software design, i.e. unwise choice of task priorities,
generation of deadlocks, unprotected critical sections, incorrect
dimensioning of time, inefficient conceptual design of task
organization, etc.
11.5 Start-up Routine

The special system routine StartOS is implemented in the OSEK

Operating System to allocate and initialize all dynamic system and
application resources in RAM. These routines are called from the main()
function of the application with the application mode as parameter (see
Section 11.6 Application Modes) and pass the control to the
scheduler to schedule the first task to be running. User hook
StartupHook is called after operating system startup and before the
scheduler is running. See Appendix A Sample Application for details.
The figure below shows system startup.

Start-up Routine
R E Q U I R E D
(Re-)Start
OS executes
hardware- first user
call to operation OS executes OS kernel
specific task is
StartOS system StartupHook is running
initialization code running
initialization code
During StartupHook all

user interrupts are
disabled
A G R E E M E N T
Figure 11-1. System startup in the OSEK OS
After returning from the StartupHook hook routine, the operating system
enables interrupts according to INITIAL_INTERRUPT_DESCRIPTOR
(see Section 6.7.6 Constants), and starts the scheduler.

R E Q U I R E D
11.6 Application Modes

Application modes are supported to allow OSEK OS to come under
different modes of operation. The minimum number of application
modes is one (SG tool generates an application mode with name “Mode“
by default). Once the operating system has been started, it is not allowed
to change the application mode. Each application mode consists of its
own set of tasks. There is no limitation to having a task or ISR running in
different modes. Sharing a task/ISR between different modes is
recommended if the same functionality is needed again.
A G R E E M E N T
NOTE: If the system is running in a specific application mode, then it is not

possible to affect a task from another application mode (it may lead to
inappropriate application behavior).
Special OIL statements should be used to define different application

modes (see Section 13.12 Different Application Modes Definition).
After system shutdown, it is possible to start an application in another

application mode (with another set of tasks), therefore run-time
reconfiguration is supported.
NOTE: After application re-start either in the same or in another application

mode internal OSEK OS data will only be initialized. The user is
responsible for proper initialization of user’s data on application re-start.
NOTE: Application mode consists of own set of tasks. All other OSEK OS
system objects like Alarms, Messages, Stack Pools etc. are shared
between different application modes.
11.7 System Shutdown

The special ShutdownOS service exits in OSEK OS to shut down the
operating system. This service could be requested by the application or
requested by the operating system due to a fatal error.
When ShutdownOS service is called with a defined error code, the

operating system will shut down and call the hook routine
ShutdownHook. The user is free to define any system behavior in
ShutdownHook e.g. not to return from the routine. If ShutdownHook

Programming Issues
R E Q U I R E D
returns, the operating system jumps to the next statement following the
initial call to StartOS. After this, the OSEK OS may be started again in a
specified application mode.
NOTE: After the return from ShutdownOS service all interrupts will be disabled.
A G R E E M E N T
The following configuration options affect error handling and hook
routines:
• ErrorHook If this option is turned on, the ErrorHook is

called by the system for error handling
• PreTaskHook If this option is turned on, the
PreTaskHook is called by the system
before context switching
• PostTaskHook If this option is turned on, the
PostTaskHook is called by the system
before context switching
• StartupHook If this option is turned on, the StartupHook
is called by the system at the end of the
system initialization
• ShutdownHook If this option is turned on, the
ShutdownHook is called by the system
when the OS service ShutdownOS has
been called
• IdleLoopHook If this option is turned on, the
IdleLoopHook is called from scheduler
idle loop

R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 12. System Configuration
12.1 Contents
12.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .133
A G R E E M E N T
12.3 Application Configuration File . . . . . . . . . . . . . . . . . . . . . . . . .134
12.4 OIL Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .134
12.2 General
The OSEK Operating System is fully statically configured one. All
system properties, the number of system objects and their parameters
(characteristics of tasks, counters, alarms, messages, etc.), run time
behavior are defined by the user. Such approach allows the user to
create various range of applications with exactly defined characteristics.
Different memory and performance requirements can be easily satisfied
with such modular approach.
All application parameters are defined in the special configuration file.
This file must conform some grammar rules. It is processed by the
separate System Generator utility (SG) 1. The System
Generator analyzes statements in the configuration file and builds output
C-language files needed to compile and link an application with the
specified features. During its execution SG reports to the user about the
errors. The System Generator produces header and source code files
that defines all properties and objects in terms of the C language. These
files are to be compiled and linked together with the user’s source code.
1. One version of SG is delivered - the 32-bit version (‘sysgen.exe’) for Windows NT and Win-
dows 95.
MOTOROLA System Configuration 133

System Configuration
R E Q U I R E D
12.3 Application Configuration File

Application configuration file contains the statements which
define the system properties and objects. Such file can have any
extension and the extension ‘.oil’ is suggested by default. The file of this
format is processed by the SG utility.
As a result of application configuration file processing SG produces

three types of standard C-language files as it is described in
Section 14.3.1 Application Configuration. SG produces two header
A G R E E M E N T
files and one source file. These files provides the code for all system
tables, descriptors, arrays etc. both in ROM and RAM according to the
user specified application configuration.
12.4 OIL Concept

OSEK Implementation Language (OIL) is the specially designed
language for development of embedded applications based on OSEK
concept. OIL is used to describe the application structure (application
configuration) as a set of system objects with defined links. OIL allows
the user to write an application configuration as a text file. These files
have predefined structure and special (standard) grammar rules.
All system objects specified by OSEK and relationships between them

can be described using OIL. OIL defines standard types for system
objects. Each object is described by a set of attributes and references.
All keywords, attributes, object names, and other identifiers are case-
sensitive.
12.4.1 OIL File
The OIL file contains two parts - one for the definition of implementation
specific features (Implementation Definition) and another one for the
definition of the structure of the application located on the particular CPU
(Application Definition).
In the very beginning of an OIL file the number of the version of OIL is
indicated. The keyword OIL_VERSION is used for this purpose. Two OIL
134 System Configuration MOTOROLA

OIL Concept
R E Q U I R E D
versions are supported at the moment - version 2.0 corresponds to the
Standard OIL format and version 2.0e corresponds to the Extended OIL
format. For example:
OIL_VERSION = "2.0e";
12.4.2 Standard OIL Format
The Standard OIL is intended to configure OSEK OS Operating System

(OS) with single application mode (SG generates single application
A G R E E M E N T
mode with name ‘Mode’ by default). The Standard OIL is considered to
be a part of OSEK OS specification v.2.0. It strictly defined by the
“OSEK/VDX System Generation OIL: OSEK Implementation
Language”, version 2.0, OSEK group, 16.12.1997.
12.4.3 Extended OIL Format
Extended OIL format includes extensions needed to control additional

features like Object Library, multiple application configuration definition,
and Constant Tables. For details regarding Extended OIL format please
refer to OSEK Builder User’s Manual. To establish different application
modes in OSEK OS application it is necessary to use Extended OIl
format in application configuration file.
12.4.4 Implementation Definition
The Implementation Definition defines implementation specific features

for the particular OSEK implementation for which this application is
developed.
The user can limit the given set of values for object attributes (e.g.
restrict the possible OS conformance classes).
It is not allowed to exclude any standard attributes from the particular

OSEK implementation. Additional non-standard attributes can be
defined for the objects for the particular OSEK implementation.
If no implementation definition is included in the OIL file then the

complete set of standard attributes and standard attribute values is

R E Q U I R E D
considered to be defined for the application. Otherwise it defines value

ranges for the attributes allowed by the OSEK implementation.
If some standard attributes have no restrictions for a particular

implementation then the description of this attribute can be omitted in the
corresponding implementation definition.
The include mechanism (see Section 12.4.5.2 Include Directive) can

be used to define the implementation definition as a separate file. Thus
corresponding implementation definition files can be developed and
A G R E E M E N T
delivered with particular OSEK implementations and then included in

user’s OIL files. The Motorola OSEK OS implementation is described in
the “mot20.oil” file which are delivered in the package.
12.4.4.1 Implementation Definition Grammar
Implementation Definition part starts with keyword IMPLEMENTATION

and implementation name.
The structure for Implementation Definition part is shown using the

following syntax:
IMPLEMENTATION <name> {
<object_descriptions>
};
All objects within Implementation Definition part are described using the
same syntax.
<object_type> {
<property_definitions>
};
Object type is defined by the object keyword. For Motorola OSEK OS

implementation the following object types are implemented:
OS, TASK, ISR, STACK, RESOURCE, EVENT, COUNTER, ALARM, MESSAGE
The set of object properties are to be defined within the object

description. Both implementation specific attribute and reference shall
be defined before it is used.
The attribute definition has the following structure:

OIL Concept
R E Q U I R E D
<attr_type> [ WITH_AUTO ] [ <attr_range> ] <attr_name> [ = <default_value>
] ;
The attribute type and attribute value range (if it exists) shall be defined.
The range of attribute values can be defined in two ways: either the
minimum and maximum allowed attribute values are defined (the [0..12]
style) or the list of possible attribute values are presented (like C
enumeration type).
The WITH_AUTO specifier can be combined with any type. If

WITH_AUTO can be specified it means that this attribute can have the
A G R E E M E N T
value AUTO and the possibility of automatic assignment.
Data types defined for OIL are listed below. Note that these data types
are not necessarily the same as the corresponding C data types.
• INT – Any integer number.

• ENUM – The list of possible values shall be presented. Any value
from the list can be assigned to this attribute.
• BOOLEAN – The attribute of this type can have either TRUE or
FALSE value.
• STRING – Any 8-bit character sequence enclosed in double-
quotes, but not containing double-quotes can be assigned to this
attribute. If the ‘\’ symbol is placed before the EOL symbol (End-
Of-Line) in the string then the next line is the continuation of the
previous one. This is identical to the same rule for long text strings
in the C language.
A reference is a special type of value intended to define links between

system objects. The reference definition has the following structure:
<object_type> <reference_name> [ <multiple_specifier> ];
The reference type is taken from the referenced object (e.g. a reference
to a task shall use the TASK keyword as reference type). A reference
can ‘point to’ any system object.
Multiple reference is the possibility to refer to several objects of the same

type with one OIL statement. For example the task can refer to several
events. If the reference shall be defined as a 'multiple' reference then the
'[]' brackets shall be present after the reference name.

R E Q U I R E D
12.4.5 Application Definition
In the application definition the OSEK application is composed from a set

of system objects. In general the application can contain more than one
system object of the same type.
Since an application is performed on CPU the entity called CPU is

introduced as the top of the description. This entity encompasses all
local objects such as tasks, messages, etc. Therefore, CPU can be
considered as a container for application objects. This concept is
A G R E E M E N T
introduced to provide future OIL evolution towards to distributed system

support. This entity is identified by the keyword CPU.
12.4.5.1 Object Definition
All objects are described using the same syntax.
<object_type> <object_name> {
<property_definitions>
};
Objects are labeled by keywords which shall be written in upper case.

Object attributes and references are also labeled by the keywords. The
keywords are introduced in Section 13 System Objects Definition.
After an object keyword the object name must follow. Name is combined
from any symbols up to 32 symbols long.
A set of attributes and references belonging to an object is enclosed in

curly brackets, like in C language.
All assignments are made via the ‘=’ operator. Each statement ends with
semicolon - ‘;’ like in the C language. A reference is represented as a
reference type keyword assigned with a name of the object referenced.
If multiple reference pointed to the set of object the object names are
listed via comma inside the curly brackets, for example task referencing
to own events:
EVENT = { MyEvent1, MyEvent2};

OIL Concept
R E Q U I R E D
12.4.5.2 Include Directive
The preprocessing directive to include other OIL files is allowed in any

place of the OIL file. This statement has the same syntax as in ANSI-C:
#include <filename.oil>
#include "[path]filename.oil"
The filename can be optionally preceded by a directory specification.

The quoted form means that a header file is being looked for in the
current directory first, then along the path specified by the “/I” command-
line option, then along paths specified by the special environment
A G R E E M E N T
variable. The angle-bracket form means that a header file is being
looked for first along the path specified by the “/I” command-line option,
then along paths specified by the special environment variable.
12.4.5.3 Comments
An OIL file may contain comments. The ’/*’ and ’//’ characters define the
start of a comment. Any characters after ’//’ are considered as a
comment and the end of line (EOL) terminates the comment. Any
characters after ’/*’ are considered as comments and the end of the
comment is defined by ’*/’. Nested comments are not allowed in OIL.
12.4.5.4 File Structure
Any file in the Standard OIL format describes an application for a single
CPU and, in general, must have the following structure:
OIL_VERSION = <version>;
IMPLEMENTATION <name> { // Implementation definition
<OBJECT_TYPE> {
...list of implementation specific object attributes...
};
...
};
CPU <name> { // Definition of the application on CPU

<OBJECT_TYPE> <object_name>
{ // System object definition
<ATTRIBUTE> = <value>;
<REFERENCE> = <object_name>;
<REFERENCE> = { <object_name>, ... };
... list of object attributes and references ...

R E Q U I R E D
};
... list of objects ...
}
12.4.6 Configuration File Rules
The application configuration files must conform some simple rules to be

successfully processed. The rules are:
• Each object has the unique name;

A G R E E M E N T
• An object can have a set of attributes which define object

properties;
• An object can have a set of references to other system objects;
• Each object shall be described only once, any type of redefinitions
is not allowed;
• All statements must be written without errors;
• It is recommended to avoid conflicting statements (e.g., the
system property TaskOwnStack is not set, but the own task stack
is defined for a task) since it leads to error or warning messages.

R E Q U I R E D
Section 13. System Objects Definition
13.1 Contents
13.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .141
A G R E E M E N T
13.3 OS Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .142
13.4 Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156
13.5 Stack Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .159
13.6 Resource Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .160
13.7 Event Definition. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
13.8 Counter Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161
13.9 Alarm Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .163
13.10 Message Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .164
13.11 ISR Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .167
13.12 Different Application Modes Definition . . . . . . . . . . . . . . . . . .168
13.2 General
All objects that are controlled by the Operating System - tasks,
resources, alarms, messages, counters, ISRs and even the OS itself -
are considered as system objects. Each of them has its unique
characteristics defined by the user. To specify parameters for each
system object the special statements are used for each object. All
statements are described below in detail.
Some parameters represents memory addresses. They are defined

either automatically or by the user. If the user does not need to control
memory address such parameters should be omitted in definition
statements. In this case SG automatically creates the code to allocate
MOTOROLA System Objects Definition 141

System Objects Definition
R E Q U I R E D
memory areas. If the user explicitly specifies the address then the
symbolic name (e.g. MyTaskStack) should be provided in the
corresponded position. This name must be defined in a user’s file (e.g.
an array can be defined for memory area) and declared as external
name before the generated source files will be used. Such techniques is
demonstrated in sample application, see Apppendix A Sample
Application.
13.3 OS Definition
A G R E E M E N T
Description:
The object Operating System is the mandatory one for any

application. It defines OS and its properties for the application. The
keyword OS is used for this object type. See Section 3 Operating
System Architecture for more detailed information about OS. The
sample of Operating System definition is:
OS sampleOS {
CC = BCC2;
STATUS = STANDARD;
};
Below the list of all additional attributes which can be defined for an
object of the OS type follows. Brief explanations are provided. This list is
divided into parts which correspond to appropriate system objects.
13.3.1 Global System Attributes
This group of attributes represents system features which are common

for the whole system.
• OSVERSION (ENUM)
Defines the version of OSEK OS specification which OS supports.
This attribute can have values 1 or 2. In the current OSEK OS
implementation it is necessary to specify 2 as OSVERSION value.
• TargetMCU (ENUM)
Specifies the CPU type. Possible values are HC08, HC12,
CPU32, MPC, MCORE and WINNT.
142 System Objects Definition MOTOROLA

OS Definition
R E Q U I R E D
• DEBUG_LEVEL (ENUM)
Specifies the ORTI support in OS. The attribute can have values
0 or 1. If the system has the DEBUG_LEVEL = 0 the static ORTI
support is switched off. If the system has the DEBUG_LEVEL = 1
this mode is considererd to be a debudding mode (see
Section 18 ORTI Implementation for the details).
• ORTIRunningTask (BOOLEAN)
Specifies that the running task identification in run-time support
will be used. This attribute will be ignored if DEBUG_LEVEL = 0
(see Section 18 ORTI Implementation for the details).
A G R E E M E N T
• ORTICurrentService (BOOLEAN)
Specifies that the OSEK OS system calls identification in run-time
support will be used. This attribute will be ignored if
DEBUG_LEVEL = 0 (see Section 18 ORTI Implementation for
the details).
• HCBasePage (BOOLEAN)
Defines that the base memory page will be used for system
variables. This option may reduce the OS code size by means of
the direct addressing mode usage when possible. This is a target
specific attribute.
• HCBankCode (BOOLEAN)
Specifies that the banked memory model support will be used.
This is a target specific attribute. Defines that memory bank
switching is supported by the system.
• HCAltRegISR (BOOLEAN)
This attribute is only applicable if TargetMCU is MCORE. It
specifies that Alternative Register File will be used for ISR
processing.
• CC (ENUM)
The CC attribute specifies the Conformance Class which is
supported by the OS. This attribute has the type ENUM. The
possible values are the following:
– BCC1
– BCC2
– ECC1

R E Q U I R E D
– ECC2
– AUTO
• STATUS (ENUM)
The STATUS attribute specifies the debugging ability of OS. If the
system has the EXTENDED status some additional checks are
performed to detect run-time errors. This mode is considered to be
a debugging mode. Standard status OS performs only very limited
set of checks, the performance is increased and the amount of
consumed memory is decreased. This attribute has the type
A G R E E M E N T
ENUM. The possible values are the following:

– STANDARD
– EXTENDED
• SimpleScheduler (BOOLEAN)
If the attribute is TRUE the simplified scheduler will be used in the
system, if each task has an unique priority and task multiply
activation mechanism is not used. It reduces the OS code and
increases system performance.
• UseMainStack (BOOLEAN)
If the attribute is TRUE the same stack area is used for the
main() function (during start-up), for the scheduler stack and for
the ISR stack, e.g. the effective top of stack is the top of stack
when OS startup is called within main(). Therefore, user should

avoid using of local variables in main() to keep top of stack as high
as possible.
• HCLowPower (BOOLEAN)
If the attribute is TRUE an instruction that puts CPU in low power
mode is used instead of the scheduler’s idle loop.
• HCLowPowerMode (ENUM)
This attribute defines LowPowerMode which will be used by the
scheduler (for some targets) (see Section 15 HC12 Platform-
Specific Features for more information).

OS Definition
R E Q U I R E D
• EntryExitISR (BOOLEAN)
If the attribute is FALSE it is assumed that there are no interrupt
service routines in the system at all and the Operating System
does not have any interrupt handling mechanisms. Interrupt
management services are not supported.
• InterruptMaskControl (BOOLEAN)
If the attribute is FALSE (while the EntryExitISR attribute is TRUE)
interrupt masks are not controlled by the operating system.
Services EnableInterrupt, DisableInterrupt, GetInterruptDescriptor
are not supported.
A G R E E M E N T
• NodeNumber (INT)
The attribute of the type INT specifies the maximum number of
tasks in the non-suspended state, available in the system. In fact,
this parameter specifies the number of task control blocks,
allocated in the system.
• SchedStackSize (INT)
The attribute of the type INT specifies the size (in bytes) of the
scheduler’s idle loop stack. It should not be less than the interrupt
stack frame. If the system property UseMainStack is set this
attribute (and SchedStackAddress also) is ignored.
• SchedStackAddress (STRING)
The attribute of the type STRING specifies the bottom of the
scheduler stack. This address can be defined explicitly to provide
a way to optimize stack allocation. In this case it is presented as
an array of characters named by SchedStackAddress attribute
value. This array should be defined in a user’s source file and
declared in a user’s header which is to be included into the system
configuration source file (see Section 14.3.2 Source Files).
• MaxPrio (INT)
The attribute of the type INT specifies the number of task priorities
in the system. This parameter is ignored if the attribute
SimpleScheduler is TRUE, since in this case it must be equal to
the number of tasks.
• NodeStackSize (INT)
The attribute of the type INT specifies the size of the stack (in
bytes) per each task node. The total size of the memory area for

R E Q U I R E D
task nodes’ stacks is defined as multiplication of this parameter by

the NodeNumber value. This parameter is ignored if the attribute
NodeStack is FALSE.
• NodeStackAddress (STRING)
The attribute of the type STRING specifies the bottom of task
nodes’ stacks. This address can be defined explicitly to provide a
way to optimize stacks allocation. In this case it is presented as an
array of characters named by NodeStackAddress attribute value.
This array should be defined in a user’s source file and declared
A G R E E M E N T
in a user’s header which is to be included into the system

configuration source file (see Section 14.3.2 Source Files). This
parameter is ignored if the attribute NodeStack is FALSE.
• UseCommonArea (BOOLEAN)
This attribute, if turned TRUE, causes system to reduce stack
usage for certain services (those ones requiring more stack
space). This leads to static memory objects (‘common area’) using
prior to stack space and could significantly reduce RAM space
overhead (see Section 15 HC12 Platform-Specific Features
for more information).
• CopyrightNotice (BOOLEAN)
The attribute specifies whether copyright notice should be
incorporated into OS ROM code.

• Reconfig (BOOLEAN)
If the option is turned on, the number of different application
modes (different sets of tasks) may be established in the same
OSEK OS application (see Section 11.6 Application Modes). In
this case it is possible to change application mode after system
shutdown. If Reconfig option is set, then Extended OIL format
should be used to define application modes. If it is not necessary
to have a number of application modes in the same application,
then it is recommended to turn this property off. It decreases the
needed amount of RAM and increases execution speed.

OS Definition
R E Q U I R E D
• ExtendedContext (BOOLEAN)
Defines whether OS has to support task context extension or not.
Valid only if the target MCU has the corresponding hardware
support (MPC505) or it is necessary due to specific compiler
behavior (HC08).
• UseMoveBlockInstruction (BOOLEAN)
Defines whether OS has to use CPU memory move block
instructions or not. This attribute is intended for MPC only.
A G R E E M E N T
13.3.2 Task Related Attributes
This group of attributes controls task features.
• SCHEDULE (ENUM)
The SCHEDULE attribute specifies the kinds of scheduling which
are supported by the OS. This attribute allows for a cross-check of
the requirements of the tasks and the capabilities offered by the
operating system. The possibility of automatic assignment for this
attribute is supported. The possible values are the following:
– NON
– FULL
– MIXED
– AUTO
• MultiplyActivation (BOOLEAN)
The attribute controls the multiply activation ability for
Conformance Classes. If the attribute is FALSE multiply activation
is disabled for tasks.
• TaskIndexMethod (BOOLEAN)
If the attribute is TRUE then the intermediate vector of the pointers
to tasks control blocks is used (fast and deterministic access to
task nodes).
• NodeStack (BOOLEAN)
The attribute defines the presence of task node stacks in the
system. If it is FALSE there are no task node stacks implemented.

R E Q U I R E D
• StackPool (BOOLEAN)
The attribute defines the presence of stack pools in the system. If
it is FALSE there are no stack pools implemented.
• PersistentNode (BOOLEAN)
If the attribute is TRUE a persistent task control block may be
assigned to the task.
• PersistentStack (BOOLEAN)
If the attribute is TRUE a persistent stack buffer may be assigned
to the task.
A G R E E M E N T
• TaskOwnStack (BOOLEAN)
The attribute defines that a task may have its own stack.
• UseSameContext (BOOLEAN)
If the attribute is TRUE the same run time context frame is used
both for non-preemptive and preemptive tasks in mixed-
preemptive systems.
• TaskBasePage (BOOLEAN)
If the attribute is TRUE, the task control blocks are placed into the
base page memory. It increases the system performance since
CPU accesses the base page faster than extended memory. In
this case the user is responsible for the needed amount of RAM in
the base page for the desired number of task nodes.
• ChainTaskItself (BOOLEAN)
The attribute can be set as FALSE if no tasks that chain itself. It
decreases the task control block size.
• NonPreemptCtxRegNum (INT)
The attribute specifies the number of extended registers to be
included into non-preemptive task context. It should contain value
from 1 till 18. Intended for MPC505 only. Valid only if
ExtendedContext = TRUE.
• SaveNonPreemptCtxExt (STRING)
The attribute specifies the assembler macro for saving extended
registers into non-preemptive task context. It should be a STRING
which contains inline assembler statements for saving extended
registers. Intended for MPC505 only. Valid only if

OS Definition
R E Q U I R E D
• RestoreNonPreemptCtxExt (STRING)
The attribute specifies the assembler macro for restoring
extended registers from non-preemptive task context. It should be
a STRING which contains inline assembler statements for
restoring extended registers. Intended for MPC505 only. Valid
only if ExtendedContext = TRUE.
• PreemptCtxRegNum (INT)
included into preemptive task context. It should contain value from
1 till 18. Intended for MPC505 only. Valid only if ExtendedContext
A G R E E M E N T
= TRUE.
• SavePreemptCtxExt (STRING)
registers into preemptive task context. It should be a STRING
which contains inline assembler statements for saving extended
registers. Intended for MPC505 only. Valid only if
• RestorePreemptCtxExt (STRING)
extended registers from preemptive task context. It should be a
STRING which contains inline assembler statements for restoring
extended registers. Intended for MPC505 only. Valid only if
13.3.3 Interrupt Related Properties
This group of attributes defines parameters of ISR execution.
• IsrStackSize (INT)
The attribute of the type INT specifies the size (in bytes) of the ISR
stack. If the attribute UseMainStack is TRUE this attribute (and
ISRStackAddress also) can be omitted.
• IsrStackAddress (STRING)
The attribute of the type STRING specifies the bottom of the ISR
stack. This address can be defined explicitly to provide a way to
optimize stack allocation. In this case it is presented as an array of
characters named by IsrStackAddress attribute value. This array

R E Q U I R E D
should be defined in a user’s source file and declared in a user’s

header which is to be included into the system configuration
source file (see Section 14.3.2 Source Files).
• DisableInterruptMask (INT)
The attribute of the type INT specifies the value of the interrupt
mask, which corresponds to all interrupts disabled.
• EnableInterruptMask (INT)
mask, which corresponds to all interrupts enabled.
A G R E E M E N T
• TaskLevelMask (INT)
mask, which, typically, corresponds to the middle level of enabled
interrupts in the system.
• InitialMask (INT)
mask, which, typically, corresponds to the initial level of enabled
interrupts during the system startup.
• ISRCategory1 (BOOLEAN)
The attribute specifies whether the ISR of category 1 is supported
by OS or not. Currently this attribute does not affect OS code.
by OS or not. Currently this attribute does not affect OS code.
by OS or not.
• ISRCtxRegNum (INT)
saved into ISR stack frame. It should contain value from 1 till 18.
Intended for MPC505 only, not implemented yet. Valid only if
• SaveISRCtxExt (STRING)
registers into ISR stack frame. It should be a STRING which

OS Definition
R E Q U I R E D
contains inline assembler statements for saving extended
registers. Intended for MPC505 only, not implemented yet. Valid
• RestoreISRCtxExt (STRING)
extended registers from ISR stack frame. It should be a STRING
which contains inline assembler statements for restoring extended
registers. Intended for MPC505 only, not implemented yet. Valid
A G R E E M E N T
• UnorderedExceptions (BOOLEAN)
The attribute allows handling of unordered exceptions. Intended
for MPC only.
13.3.4 Resources and Events Related Attributes
The attributes control resources and events.
• Resources (BOOLEAN)
This attribute defines whether resource management is provided
by OS or not.
• FastResource (BOOLEAN)
The attribute can be specified by the user to increase the system
performance. If it is TRUE the system will work faster. But this
attribute may be used only for debugged applications, because
errors related to incorrect access and priority are not signalled. If
this attribute is TRUE less amount of ROM and RAM is needed for
resources. But, if resource priorities have a big difference (e.g. first
resource has priority 1 and the second resource has priority 20)
this attribute does not lead to RAM saving.
• ResourceAccessCheck (BOOLEAN)
Defines whether E_OS_ACCESS error code is returned by
GetResource service or not. If it is TRUE, then error code will be
returned in EXTENDED status based on task definition in OIL-file.
If the system has STANDARD status or FastResource property
turned on or more than 8 resources (including Scheduler) are
defined in application, then this attribute should be set to FALSE.

R E Q U I R E D
• Events (BOOLEAN)
This attribute defines whether event management is provided by
OS or not.
13.3.5 Counters and Alarms Related Attributes
This group of attributes controls counters and alarms features.
• Counters (BOOLEAN)
This attribute defines whether counters are provided by OS or not.
A G R E E M E N T
• CounterSize (ENUM)
This attribute defines the size of all counters. The valid values are
8, 16 and 32 which conform to byte, word and long word size of
counters.
• Alarms (BOOLEAN)
This attribute defines whether alarms are provided by OS or not.
• AlarmList (BOOLEAN)
If the attribute is TRUE the running alarms are linked into a list
which decreases the time for alarm handling.
• AlarmDeltaList (BOOLEAN)
If the option is turned on the running alarms are linked into ordered
alarm delta-list which significantly decreases the time for

CounterTrigger service if too much alarms are connected with the
same counter (more than 10). The time for alarm management
services like SetAbsAlarm, SetRelAlarm, GetAlarm will be
increased.
• CyclicAlarm (BOOLEAN)
If the option is turned on, the cyclic alarms are supported.
Otherwise, no one alarm may be cyclic, which decreases RAM
usage for alarm control blocks, as well as decreases code usage
and advances timing of alarms services. This option is turned on
by default.

OS Definition
R E Q U I R E D
• MinAlarmRAM (BOOLEAN)
If the option is turned on, the alarm handling is optimized for
memory (RAM). Otherwise, alarm handling is optimized for speed.
When turned on, the alarm control block is significantly decreased,
especially when AlarmList option is turned off.
• TimerHardware (ENUM)
This attribute is intended to select the hardware interrupt source
for the system counter (among the accessible MCU devices). See
Section 15 HC12 Platform-Specific Features and
Apppendix E Quick Reference for details about possible
A G R E E M E N T
meanings of these parameters.
• SysTimer (BOOLEAN), Prescaler (BOOLEAN), PrescalerValue
(INT), TimerModulo (BOOLEAN), TimerModuloValue (INT)
The set of parameters to tune the selected hardware interrupt
source is introduced:
SysTimer, Prescaler, PrescalerValue, TimerModulo,
TimerModuloValue. One or more parameters can be here in
accordance with the hardware features. For more details see
Section 15 HC12 Platform-Specific Features. This
parameter(s) can be omitted.
13.3.6 Messages Related Attributes
These are additional attributes to control local messages.
• UnqueuedMessages (BOOLEAN)
The attribute allows Unqueued Messages in the system.
• UnqueuedMsgDefaultValue (BOOLEAN)
The attribute allows Unqueued Messages to have default values.
• QueuedMessages (BOOLEAN)
The attribute allows Queued Messages in the system.
• QueuedMsgOneToN (BOOLEAN)
If the attribute is TRUE, 1:N Queued Messages are allowed.
• ActivateOnMsg (BOOLEAN)
If the attribute is TRUE task activation on message arrival is
supported.

R E Q U I R E D
• AlarmOnMsg (BOOLEAN)
If the attribute is TRUE an alarm can be linked to message arrival.
• SetEventOnMsg (BOOLEAN)
If the attribute is TRUE event setting is allowed on message
arrival.
13.3.7 Hook Routines Related Attributes
These attributes define hook routines support in the system.

A G R E E M E N T
• ErrorHook (BOOLEAN)
If the attribute is TRUE the user’s hook for error handling is
supported by the system (the ErrorHook hook routine).
• PreTaskHook (BOOLEAN)
If the attribute is TRUE the user’s hook for context switching is
supported by the system (the PreTaskHook hook routine).
• PostTaskHook (BOOLEAN)
If the attribute is TRUE the user’s hook for context switching is
supported by the system (the PostTaskHook hook routine).
• StartupHook (BOOLEAN)
If the attribute is TRUE the user’s hook is called by the system at
the end of the system initialization (the StartupHook hook routine).

• ShutdownHook (BOOLEAN)
If the attribute is TRUE the user’s hook is called by the system
when the OS service ShutdownOS has been called (the
ShutdownHook hook routine).
• IdleLoopHook (BOOLEAN)
If the attribute is TRUE the user’s hook to be called from scheduler
idle loop is supported by the system (the IdleLoopHook hook
routine).
• InternalErrorHandler (BOOLEAN)
The attribute defines whether the internal error handler is
implemented.

OS Definition
R E Q U I R E D
• UserCommand1 (STRING)
The attribute defines entry point of the user's hook #1 to be called
from the OS Dispatcher thread (for OS/NT with interrupt emulation
only).
only).
A G R E E M E N T
only).
13.3.8 OS Service Related Attributes
The group of attributes is designed to exclude particular OS services. All

these attributes has the BOOLEAN type. If an attribute is FALSE the
corresponded service is excluded from the OS code. Names of these
attributes are the same as corresponding OS service names. E.g., if the
attribute InitCounter is set as FALSE it means that this service will be
unavailable in an application. This is the list of such attributes:
• Task management services:
ActivateTask, TerminateTask,ChainTask,
ChainTaskItself, Schedule, GetTaskId, GetTaskState,
GetTCBInfo
• Resource management services:
GetResource, ReleaseResource
• Event management services:
SetEvent, ClearEvent, GetEvent, WaitEvent
• ISR management services:
EnterISR, LeaveISR, EnableInterrupt, DisableInterrupt,
GetInterruptDecsriptor
• Counter related services:
InitCounter, CounterTrigger, AdvanceCounter,
GetCounterValue, GetCounterInfo

R E Q U I R E D
• Alarm related services:

SetRelAlarm, SetAbsAlarm,CancelAlarm, GetAlarm,
GetAlarmBase
• Communication services:
SendMessage, ReceiveMessage, GetMessageResource,
ReleaseMessageResource, GetMessageStatus
• Execution control:
GetActiveApplicationMode, ShutdownOS
A G R E E M E N T
13.4 Task Definition

Description:
This statement is used to define task data. Several statements can be in

the configuration file, each statement defines one task.
This object presents a task. Attributes of this object type define task
properties. Links with other system objects are defined via references.
The keyword TASK is used for this object type. See Section 4 Task
Management for more detailed information about OSEK tasks. The
sample of a task definition is:
TASK TaskA {
TYPE = EXTENDED;
PRIORITY = 2;
SCHEDULE = NON;
ACTIVATION = 5;
STACKSIZE = 64;
AUTOSTART = TRUE;
EVENTS = { event1, event2, event3 };
};
13.4.1 Object Attributes
The object has the following attributes:
• TYPE (ENUM)
This attribute has the type ENUM. The OSEK task may be one of
the following types:
– BASIC

Task Definition
R E Q U I R E D
– EXTENDED
• PRIORITY (INT)
The priority of the task is defined by the value of the PRIORITY
attribute. The bigger value of the PRIORITY attribute corresponds
to the higher priority. This attribute has the INT type. The default
value range is from 0 to 255.
• SCHEDULE (ENUM)
The run-time behavior of the task is defined by this attribute. If the
task may be preempted by another one at any point of execution
A G R E E M E N T
- this task attribute shall have the FULL value (preemptive task). If
the task can be preempted only at specific points of execution
(explicit rescheduling points) the attribute shall have the NON
value (non-preemptive task). This attribute has the type ENUM
with the values:
– FULL
– NON
• ACTIVATION (INT)
The maximum number of registered activation requests for the
task. This attribute has the INT type. The default value range is
from 1 to 255. The maximum number can be constrained in the
implementation specific definition part. The value 1 means that a
task cannot be multiple activated, only single activation is allowed.
• STACKSIZE (INT)
This attribute defines the size of the task stack. It depends on the
CPU family and functionality of the task. The attribute has the type
INT. No default value range is defined. The maximum stack size
can be constrained by the implementation.
• AUTOSTART (BOOLEAN)
This attribute determines whether the task is activated during the
system start-up procedure or not. It has the BOOLEAN type, so
the possible values are TRUE and FALSE.
• StackMethod (ENUM)
This attribute specifies the stack allocation method. The attribute
(the ENUM type) has three available values. NODESTACK means
that task node stack is implicitly assigned to be used by the task
(during the task activation). POOLSTACK means that a stack

R E Q U I R E D
should be dynamically allocated to the task from the stack pool

during task activation. OWNSTACK (the default attribute value)
means that a stack is explicitly assigned to the task (in this case
the address of the top of the stack will be calculated by the system
generation utility). Note that to get a correct OIL file the value must
correspond to the appropriate OS attribute (NodeStack, StackPool
and TaskOwnStack).
• StackAddress (STRING)
The attribute of the type STRING specifies the bottom of the task
A G R E E M E N T
stack. This address can be defined explicitly to provide a way to

optimize stack allocation. In this case it is presented as an array of
characters named by StackAddress attribute value. This array
should be defined in a user’s source file and declared in a user’s
header which is to be included into the system configuration
source file (see Section 14.3.2 Source Files).
• MemoryBank (INT)
The attribute (INT type) defines the memory bank for the task
code.
• InterruptMask (INT)
The attribute (INT type) defines the starting task’s interrupt mask.
If this parameter is omitted, then the value of the TaskLevelMask
attribute is used
• PersistentNode (BOOLEAN)
If the attribute is TRUE a persistent task node is assigned to the
task.
• PersistentStack (BOOLEAN)
If the attribute is TRUE a persistent stack buffer is assigned to the
task.
13.4.2 Object References
A task in OSEK OS has the set of allowed references. A reference is

presented as the symbolic name of an object that is referenced to by the
task. The following references are allowed:

Stack Definition
R E Q U I R E D
• RESOURCE (multiple)
If the task accesses a resource at run-time this resource shall be
pointed. The resource Ceiling priority is calculated as the highest
priority of tasks accessing this resource (or higher one).
• EVENT (multiple)
An extended task can have a set of events. These events can be
cleared and waited for by the task. All task events shall be pointed
to define the event mask in case of auto-assignment (see section
Section 13.7 Event Definition).
A G R E E M E N T
• MESSAGESENT (multiple)
If a task sends a message (has write access to a message) this
message shall be specified as the reference. The symbolic name
of the message shall be pointed.
• MESSAGERECEIVED (multiple)
If a task receives a message (has read access to a message) this
message shall be specified as the reference. The symbolic name
of the message shall be pointed.
NOTE: It is not mandatory to reference messages which are sent or received by

the task. But it is recommended to do to simplify application consistency
verification and to eliminate possible errors, especially in case of 1:N
communication.
• StackPool (single)
If a task uses the stack from a stack pool the reference to the
dedicated stack pool must be provided. The symbolic name of the
stack pool shall be pointed.
NOTE: If a task uses a stack from the stack pool the value of the task attribute
STACKSIZE is ignored.
13.5 Stack Definition

Description:
This statement is used to define stack pool data. Several statements can
be in the configuration file, each statement defines one pool. The
keyword for this object is STACK. See Section 4.7.4 Task Stack for

R E Q U I R E D
more information about the task stack. The sample of a stack definition
is:
STACK StackTaskA {
StackSize = 128;
NumberOfStacks = 5;
StackAreaAddress = 0x400;
};

A G R E E M E N T
The attributes of the STACK object reflect these physical parameters of

a pool. They are:
• StackSize (INT)
The attribute represents the size of a stack buffer, it has the type
INT.
• NumberOfStacks (INT)
The attribute corresponds the number of buffers in the pool, it also
has the type INT.
• StackAreaAddress (STRING)
The attribute specifies the start address of the pool memory area
and it has the type STRING. This optional parameter serves for
explicit memory allocation for the task stack pool.
13.6 Resource Definition

Description:
This object is intended for the resource management. The resource

object has no standard attributes and references. The resource Ceiling
priority is calculated automatically on the basis of information about
priorities of tasks using the resource. The keyword RESOURCE is used
for this object type. Section Section 7 Resource Management
describes resource concept in OSEK. The sample of a resource
definition is:
RESOURCE ResAccess {
};

Event Definition
R E Q U I R E D
• PRIORITY (INT)
The priority of the resource is defined by the value of the
PRIORITY attribute. The bigger value of the PRIORITY attribute
corresponds to the higher priority. This attribute has the INT type.
This attribute has the possibility of automatically assignment. In
this case the resource Ceiling priority is calculated automatically
on the basis of information about priorities of tasks using the
A G R E E M E N T
resource.
13.7 Event Definition

Description:
This object is intended for the event management. The event object has
no references. The keyword EVENT is used for this object type. Section
Section 9 Events describes events in OSEK. The sample of an event
definition is:
EVENT event1 {
MASK = 0x01;
};

• MASK (INT)
The event is represented by its mask. The attribute has the type
INT. The event mask is the number which range can be defined in
the implementation specific definition part. The other way to
assign event mask is to declare it as AUTO. In this case event
masks will be assigned automatically according to their
distribution among the tasks.
13.8 Counter Definition

Description:

R E Q U I R E D
This object presents OSEK Operating system counters. Attributes of this

object type define counter properties. A counter has no references, it is
referenced to by other object. The keyword COUNTER is used for this
object type. OSEK counters are described in section
Section 8.3 Counters. The sample of a counter definition is:
COUNTER Timer {
MINCYCLE = 16;
MAXALLOWEDVALUE = 128;
TICKSPERBASE = 90;
};
A G R E E M E N T
The object has the following standard attributes:
• MAXALLOWEDVALUE (INT)
The attribute defines the maximum allowed counter value. When
the counter reaches this value it rolls over and starts count again
from zero. The attribute has the type INT.
• MINCYCLE (INT)
The attribute specifies the minimum allowed number of counter
ticks for a cyclic alarm linked to the counter. (In fact, this parameter
has a sense only for systems with extended OS status since it is
checked in this case only.) The attribute has the type INT.
• TICKSPERBASE (INT)
For the system timer (if specified) this is the number of ticks that
are required to reach 10 milliseconds. This value cannot be
derived automatically from other counter related attributes (see
also PrescalerValue, TimerModuloValue
Section 13.3.5 Counters and Alarms Related Attributes). For
the rest counters this attribute specifies the number of ticks
required to reach a counter-specific value (the interpretation is up
to the user). The attribute has the type INT.
• TICKDURATION (INT)
For the system timer (if specified) this is the duration of a tick in
nanoseconds. The attribute has the type INT.

Alarm Definition
R E Q U I R E D
• SystemTimer (BOOLEAN)
This attribute specifies whether the counter is the system timer. By
default this attribute has the value FALSE. Note, however, that
only one counter must be defined as the system timer.
13.9 Alarm Definition

Description:
This object presents OS alarms. An alarm has no standard attributes.
A G R E E M E N T
Links with other system objects are defined via references. The
referenced counter and task must be already defined.The keyword
ALARM is used for this object type. See section Section 8.4 Alarms for
information about alarms. The sample of an alarm definition is:
ALARM WakeTaskA {
ACTION = SETEVENT;
COUNTER = Timer;
TASK = TaskA;
EVENT = event1;
};
An alarm has the following allowed references:
• ACTION (single)
This attribute has the type ENUM. The ACTION may be one of the
following types:
– ACTIVATETASK
– SETEVENT
• COUNTER (single)
An alarm shall be assigned to a particular counter to have an
ability to operate.
• TASK (single)
The reference points to a task which is to be notified via activation
or event setting when the alarm expires.

R E Q U I R E D
• EVENT (single)
An event which is to be set when the alarm expires is pointed here.
The event is considered as an inseparable pair of the task and the
event belonging to this task, so the reference to the task which
owns the events shall be also defined for this alarm.
13.10 Message Definition

Description:
A G R E E M E N T
This object is intended to present either a Unqueued or an Queued

message. Attributes of this object type define message properties. Links
with other system objects are defined via references. The keyword
MESSAGE is used for this object type. Messages concept is described
in section Section 10 Communication. The sample of a message
definition is:
MESSAGE Msg4TaskA {
ITEMTYPE = "int";
ITEMS = 1;
ALARMRESETTIME = 20;
ALARMRESET = DrvAlarm;
ACTION = SETEVENT;
TASK = TaskA;
EVENT = event1;
};
• ACTION (ENUM)
This attribute has the type ENUM. The ACTION may be one of the
following types:
– ACTIVATETASK
– SETEVENT
– NONE

Message Definition
R E Q U I R E D
• TYPE (ENUM)
In accordance with the OSEK specification there are two types of
messages: Unqueued and Queued. The possible value of this
attribute are the following:
– UNQUEUEDMESSAGE
– QUEUEDMESSAGE
• ITEMTYPE (STRING)
The message item can have the own type which has to be any C
data type. Any ANSI-C type specifier is allowed. It is the standard
C type identifier - char, int, float, double with any type
A G R E E M E N T
modifiers (signed, unsigned, short, long) and also
structure or union specifier (starting struct or union), enum
specifier (starting enum), typedef name (any valid C-language
identifier) enclosed in the double quotas. To use an array of
standard C-language type the user must define the new type via
typedef operator. In case of user’s defined data types or
enumerations such definitions must be in the user’s code before
using files produced by SG
• ITEMS (INT)
The queued message can have more than one item. This attribute
specifies the capacity of the FIFO queue, i.e. the number of
message items into the FIFO queue. The unqueued message
always has only one item.
• ALARMRESETTIME (INT)
Alarm can be assigned to a message which is restarted at
message arrival (alarm restart will happen as a result of
SendMessage service execution). The time period for this alarm is
defined by this attribute. The units are ticks of the counter
assigned for the alarm.
• StartupAlarm (BOOLEAN)
This attribute specifies whether the alarm referenced by the
message must be restarted during system start-up. By default this
attribute has the value FALSE, it means that the alarm is not
restarted during start-up. Restarting of the alarm may be used to
trap the loss of the first message.

R E Q U I R E D
• DefaultValue (STRING)
This attribute presents the address of the ROM-based variable,
which holds the default value of the unqueued message. This
variable must have the type <ITEMTYPE>, and must be located in
the user’s code. The parameter may be omitted.This attribute is
intended for unqueued messages only.
• ReceiverNum (INT)
The attribute defines the number of local task-receivers of the
message. If it has a value greater than 1, then it is assumed, that
A G R E E M E N T
several tasks may receive a message item from the message

queue.
• WithCopy (BOOLEAN)
The attribute defines that unqueued message is used with copy
(TRUE) or without copy (FALSE).
A message in OSEK OS has the set of allowed references. A reference

is presented as the symbolic name of an object that is referenced to by
the message. The following references are allowed (identified via
keywords):
• ALARMRESET (single)
The reference points to an alarm which is to be restarted when the
message arrives (alarm restart will happen as a result of
SendMessage service execution).
• TASK (single)
The reference points to a task which is to be notified via activation
or event setting when the message arrives.
• EVENT (single)
An event which is to be set when the alarm expires is pointed here.
The event is considered as an inseparable pair of the task and the
event belonging to this task, so the reference to the task which
owns the events shall be also defined for this message.

ISR Definition
R E Q U I R E D
13.11 ISR Definition
Description:
This object presents an Interrupt Service Routine. The keyword ISR is

used for this object type. The sample of an Interrupt Service Routine
definition is:
ISR TimerISR{
CATEGORY = 2;
}
A G R E E M E N T
This object has the following attributes:
• CATEGORY (ENUM)
Specifies category of the Interrupt Service Routine. Possible
values are: 1, 2 or 3 (see Section 6.4 ISR Categories for
Interrupt Service Routine Categories details).
• TYPE (ENUM)
This attribute is only valid if TargetMCU global system attribute is
MCORE and HCAltRegISR global system attribute is TRUE. It
chooses between Fast Interrupt exception and all other
exceptions. The possible values of this attribute are the following:
– FAST
– NORMAL

• MESSAGESENT (multiple)
Only a message which is sent by ISR can be referenced. If ISR
sends a message (has write access to a message) this one shall
be specified as the reference. The symbolic name of the
appropriate message object shall be pointed.

R E Q U I R E D
13.12 Different Application Modes Definition

Description:
It is possible to introduce different application modes inside one CPU

container by means of additional container object named CFG
(configuration). This object is introduced in Extended OIL format (see
Section 12.4.3 Extended OIL Format).
A set of CFG statements can be represented inside one CPU to

establish different application modes. The CFG statement contains a set
A G R E E M E N T
of objects. To define application mode it is necessary to collect

application mode dependent tasks inside corresponding CFG
statement. It is possible to share a task between different application
modes. In this case it is necessary to include corresponding task
definition into all affected CFG objects. The CFG statement has the
syntax similar to CPU syntax.
All application modes should be enumerated in special CFGACTIVE

statement located inside the scope of corresponding CPU.
The following is the OIL example of CPU description with two application
modes and five tasks. Task TC code is shared between application
modes.
OIL_VERSION = "2.0e"; /* Force SG to use Extended */

/* OIL format */
INCLUDE “mot20.oil”
CPU cpu1 {
CFGACTIVE = { ModeA, ModeB }; /* Two application modes */
/* “ModeA”, “ModeB” are */
/* defined */
....
CFG ModeA { /* Application mode “ModeA” */
TASK TC { ... }; /* TC code is shared between both modes */
TASK TA1 { ... }; /* ModeA specific task TA1 */
TASK TA2 { ... }; /* ModeA specific task TA2 */
};
CFG ModeB { /* Application mode “ModeB” */
TASK TB1 { ... }; /* ModeB specific task TB1 */
TASK TC { ... }; /* TC code is shared between both modes */
TASK TB2 { ... }; /* ModeB specific task TB2 */
};
STACK POOL { ... }; /* Stack pool definition */
COUNTER Timer { ... };/* Counter definition */

Different Application Modes Definition
R E Q U I R E D
ALARM Alarm { ... }; /* Alarm definition */
....
};
A task may have different properties in different application modes. Only

TASK statements may be used inside CFG object in case of application
mode definition. See Section 17.9.5 Examples of Application Modes
Usage for details regarding different application modes definition.
A G R E E M E N T

R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Section 14. Building of Application
14.1 Contents
14.2 Application Structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .171
A G R E E M E N T
14.3 Action Sequence to Build an Application . . . . . . . . . . . . . . . .172
14.4 Sample Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .178
14.2 Application Structure

An application developed on the OSEK Operating System basis has a
defined structure. An application consists of the Operating System
kernel and several user’s tasks and ISRs, which interact with the kernel
by means of system services and internal mechanisms. ISRs receive
control from hardware interrupt sources via the vector table. Tasks are
controlled by the scheduler. They may use all means for intertask
communications granted by OSEK OS to pass data and synchronize
each other.
Tasks and ISRs are considered as system objects. Resources,

Unqueued and Queued messages, counters, and alarms are also
considered as system objects, because they are controlled by the
Operating System. An application typically also has configuration tables
for different system objects, stack buffer pools and other entities. To
create an application, the user should develop the desired application
structure with all necessary objects and define interactions between
them.
All global Operating System properties, system objects and their

parameters are defined by the user statically and cannot be redefined at
run time. Special application configuration file is designed to perform
such definition and the special tool that processes this file. See
Section 12 System Configuration. After processing, files with system
MOTOROLA Building of Application 171

Building of Application
R E Q U I R E D
object descriptors are created automatically. These files provide the

code for all required ROM and RAM structures, arrays, tables, variables,
etc. for all system objects defined in the configuration file. Memory
allocation is performed during start-up procedure.
14.3 Action Sequence to Build an Application

To build an application using the OSEK Operating System the user
should perform a set of actions. These actions are relatively simple since
A G R E E M E N T
the most important requirement is a clear understanding of the

application’s algorithm. The actions include creating the application
configuration file, processing this file by the System Generator, writing
the user’s source code, compiling all files and linking the application files
together with the OSEK OS code. This process is shown in Figure 14-1.
172 Building of Application MOTOROLA

Action Sequence to Build an Application
R E Q U I R E D
Application
configuration
file User’s source
code
System
Generator
OSEK
A G R E E M E N T
Files produced by SG OS kernel
Compiler
Linker
Executable file
– user defined files – files produced by SG

– OSEK Operating
System components – development software
Figure 14-1. Application building process
14.3.1 Application Configuration
Applications built using OSEK OS are configured statically via the

special configuration file written in OIL. Section 12 System
Configuration describes the structure of such file and
Section 13 System Objects Definition describes all possible
statements in detail. This configuration file defines system specific
parameters as well as system objects. Such a file can have any
extension and the extension “.oil” is suggested by default.
The configuration file has to be processed by the special utility named

System Generator (SG). This utility is delivered as one of the parts of the

R E Q U I R E D
OSEK Operating System. This tool runs as a simple MS-DOS

application and produces header and source files.
The following command is used to run SG:
sysgen [-options] oil_file
The following command line options are intended to control SG:
Table 14-1. System Generator command line options

A G R E E M E N T
Option Description Default value

-c* Defines * as the data file name Input file name with “.c” extension
Input file name with “.h”
-h* Defines the header file name
extension
-i* Defines the path for include files No
Defines * as the name of CPU for which output files are
-n* First CPU in the file
generated
For supporting backward compatibility previous version of
-o No
SG utility which treats the lesser value as the higher priority
-p* Defines the property file name “osprop.h”
-t* Defines the pathname for property template file “osprop.tpl”
For verification mode only. When this option is defined the
-v No
generation is not performed
The location of the property template file can be pointed either in

command line or via the SYSGEN_TEMPLATE environment variable.
In addition to command line option the OSB_INCLUDE_DIR

environment variable can be used to specify the set of directories to
search for include files.
The SG utility produces three types of standard C-language files which

are to be compiled and linked together with OS kernel code and user’s
source code:
1. The header file which describes the current configuration of the

operating system, in other words, system properties. This file
contains the preprocessor directives #define and #undef. This
file is used at compile time to build the OS kernel with the specified
properties. The default filename is “osprop.h” but the user can

R E Q U I R E D
assign another name (see Section 14.3.2 Source Files).
2. The header file which contains definitions of data types and
constants, and external declarations of variables which are
needed to describe system objects. This file is used to compile
application files. By default, System Generator uses the input file
name for this output file with “.h” extension.
3. The source file which contains initialized data and memory
allocation for system objects. This file is compiled with “osprop.h”
and other header files and then linked together with other
application and OS files. By default, System Generator uses the
input file name for this output file with “c” extension.
A G R E E M E N T
NOTE: As a rule, the user is not allowed to edit files produced by the System
Generator. It may lead to data inconsistency, compilation errors or
unpredictable application behavior.
14.3.2 Source Files
OSEK Operating System is delivered to the user as a set of source files.

Header and source files of the Operating System are located in the
predefined directories after OSEK OS installation, as it is described in
Section 2.5.2 Installation. Paths to these directories have to be
provided by the user.
The OS source code is compiled and linked together with other
application’s files. The header file “osprop.h” describing system
properties defines which functionality will have the OS kernel in run time.
This file must be included in all user’s and OS’ source files. Since the
user can specify another name for this file the special macro OSPROPH
is designed to substitute the name. The following code can be used in all
user’s files (it is used in all OS source files):
#if !defined (OSPROPH)

#include <osprop.h>
#else /* !defined (OSPROPH) */
#include OSPROPH
#endif /* !defined (OSPROPH) */
The compiler command line (see Section 14.3.3 Compiling and

Linking) in this case should have the option like this:

R E Q U I R E D
-dOSPROPH="<filename>".
<filename> is the name of the file with system properties definitions.
But the user is allowed to use some other method to include the property
definition header file in his/her source code.
Among other files SG generates configuration C-file containing

definitions and initialization of OSEK OS configuration data and
A G R E E M E N T
corresponding header H-file. Configuration C-file is a separate module,

however, in some particular OSEK OS configurations, it could contain
references to user defined data and structures (e.g. user’s message
structure types). This requires a method to provide SG generated
configuration C-file with such user defined types and data declarations.
Thus SG generates the following code in configuration C-file:
#if defined(APPTYPESH)
#include APPTYPESH /* user’s header file */
#endif /* defined(APPTYPESH) */
The compiler command line (see Section 14.3.3 Compiling and

Linking) in this case should have the option like this:
-dAPPTYPESH="<filename>".
<filename> is the name of the file with user defined structures and
data declarations.
In the example below two variables and one data type are defined by the
user which are referenced in files generated by SG. Variables are
defined in the user’s file “user.c” and referenced in the produced file
“cfg.c”. The data type is defined in the user’s file “user.h” and referenced
in the produced file “cfg.c”. The user’s code can be the following:
USER.H file:
typedef struct tagMSG MSGTYPE;

struct tagMSG
{
TickType timeStamp;
int x;
};
extern MSGTYPE MsgA;

R E Q U I R E D
#define MYISRSTACKSIZE100
extern char MyIsrStack[MYISRSTACKSIZE];
USER.C file:
#include "user.h" /* include user defined data type */

...
char MyIsrStack[MYISRSTACKSIZE];
...
int varA = 22; /* user defined variables */
int varB = 0;
A G R E E M E N T
...
CFG.C file (generated by SG):
...
#if defined(APPTYPESH)
#include APPTYPESH /* user’s header file */
#endif /* defined(APPTYPESH) */
...
/* SG generated code referring to user’s type and data */
...
The compiler command line has the following option:
-dAPPTYPESH="USER.H".
Other variants are also possible.
The code of user’s tasks and functions should be developed according
to common rules of the C language. But some exceptions exist:
• The keyword TASK and ISR should be used to define a task and
ISR correspondingly;
• For objects controlled by the OSEK Operating System the data
types defined by the system must be used. The data types are
described at the end of previous sections and in

R E Q U I R E D
14.3.3 Compiling and Linking
When all needed header and source files are created or produced by the
System Generator an application can be compiled and linked (for details
see Appendix 15 HC12 Platform-Specific Features).
Linking process is controlled by the typical linker directive file.
14.4 Sample Application

A G R E E M E N T
In Appendix A Sample Application the code of an OSEK OS based

application is provided. This code is a simple demonstration of Operating
System mechanisms. It also demonstrates how to write the configuration
file and source code.

R E Q U I R E D
Section 15. HC12 Platform-Specific Features
15.1 Contents
15.2 Compiler-Specific Features . . . . . . . . . . . . . . . . . . . . . . . . . .179
A G R E E M E N T
15.3 Interrupt Flag Manipulation Specific Features . . . . . . . . . . . .180
15.4 HC12 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .182
15.5 Task Stack Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .192
15.2 Compiler-Specific Features

To use OSEK OS after installation the Cosmic C-compiler for
MC68HC12 should be installed on the computer. It is necessary to call
the DOS prompt under Windows NT to run the NMAKE utility.
15.2.1 OSEK OS Environment Variables
It is recommended to add environment variables and paths to access
compiler directories and OSEK directory. Installation procedure
suggests the user to set these variables automatically and place it into
OSEK OS Environment Configuration file (MAKE.BAT by default). If they
were not set during installation the user should do it manually.These
variables are the following:
OSEKDIR = [...]\OSEK – path to the OSEK directory
For the Cosmic compiler:
CXPATH = [...]\H6812 – path to the Cosmic header files directory
CXLIB = [...]\LIB – path to the Cosmic library files directory
MOTOROLA HC12 Platform-Specific Features 179

HC12 Platform-Specific Features
R E Q U I R E D
See the file "makefile" in the OSEK\SAMPLE directory for additional

information.
15.2.2 Cosmic Software
In case of optimization-related errors in the compiler’s code generation

It is recommended to switch off optimizer by use “-no” option for
compiler. (The “-no” option is used in the sample makefile for debug
version of the executable code).
A G R E E M E N T
Definitions for Cosmic C-compiler
The user should set the next compiler definitions to provide the selection
of the Cosmic platform and the selection of the board being used:
• OSCOSMIC12 for the selection of the Cosmic platform.

• OSHC12A4 for selection of the board HC812A4EVB.
• OSHC12B32 for selection of the board M68HC12B32EVB.
• OSHC12D60 for selection of the board M68EVB912D60.
• OSHC12D128 for selection of the board M68EVB912D60 with
DA128 chip.
15.3 Interrupt Flag Manipulation Specific Features

CPU12 exceptions include resets, an unimplemented opcode trap, a
software interrupt instruction, X-bit interrupts and I-bit interrupts.
Exceptions can be classified by the effect of the X and I interrupt mask
bits in Condition Code Register (CCR) on recognition of a pending
request. Resets, the unimplemented opcode trap, and the SWI
instruction are not affected by the X and I mask bits. COP resets have
register values to enable/disable. Interrupt service requests from the
XIRQ pin are inhibited when X = 1, but are not affected by the I bit. All
other interrupts are inhibited when I = 1.
This version of the OSEK Operating System manipulates with CCR X-bit
and I-bit only (external interrupt registers are not affected), therefore it is
not possible to use OSEK services from interrupts below XIRQ.
180 HC12 Platform-Specific Features MOTOROLA

Interrupt Flag Manipulation Specific Features
R E Q U I R E D
HC12 OS services for interrupt flag manipulation simply disable and
enable interrupts and inquire the current status of the interrupt flags
(CCR X-bit and I-bit). If a task is preempted by other task or suspended
its interrupt mask is saved. When the task is resumed its saved interrupt
mask is restored. When a task is activated it has either the interrupt
mask specified in the task definition statement (attribute InterruptMask
in OIL-file) or the interrupt mask specified in the interrupt definition
statement (attribute TaskLevelMask in OIL-file - common mask value for
all tasks which have undefined InterruptMask attribute)
In OSEK OS v.2.0 it is necessary to use logical interrupt
A G R E E M E N T
descriptors(logicmask).
For OS/12 the following logicmask values are valid:
0x10 – I-bit interrupts are enabled (CCR I-bit is cleared, X-bit is set);
0x40 – X-bit interrupts are enabled (CCR X-bit is cleared, I-bit is set);
0x50 – I-bit and X-bit interrupts are enabled (CCR I-bit and X-bit are
cleared);
0x00 – internal interrupts are disabled (CCR I-bit and X-bit are set).
Physical interrupt mask (value of CCR I-bit and X-bit) is ( ~logicmask

)&0x50.
All other bits of CCR are not affected in OSEK system services.
Notice, that system services (EnableInterrupt, DisableInterrupt,

GetInterruptMask) proceeds their parameter as full mask (8-bit) to be
applied to CCR but affected on X-bit and I-bit only. GetInterruptMask
returns mask that can be safely provided to other system services.
DisableInterrupt inverts mask argument before set it. E.g. call
DisableInterrupt( 0x00) sets interrupt mask 0x10 (logicmask).
NOTE: It is possible to use EnterISR()/ExitISR() services from internal interrupts

only (as mentioned above).

R E Q U I R E D
15.4 HC12 Features
15.4.1 Base Page Memory Usage
In general, the system configuration option HCBasePage is of

considerable importance for the OSEK Operating System for HC12
MCU. The average size of the OSEK OS kernel version with
HCBasePage turned on is significantly smaller than the size of the
version with extended addressing (HCBasePage is turned off). Exact
A G R E E M E N T
characteristics are provided in Appendix C Memory Requirements.

This feature can be important for applications with exacting
requirements for memory and performance. Also the task control blocks
can be placed into the base page memory, if the system configuration
option TaskBasePage is turned on. In this case the user is responsible
for the needed amount of RAM in the base page for the desired number
of task control blocks (the Cosmic linker option to control the segment
size “-m##” can be used for this purpose). This system property
increases the overall system performance.
However, it should be kept in mind that not all MCUs based on CPU12
core have base page available for data. For example, MC68HC812A4
uses base page for registers, and using of base page for OSEK OS
should be avoided (i.e. both options described above must be turned off)
NOTE: The current OSEK Operating System for HC12 has this feature
implemented for Cosmic software only.
15.4.1.1 Mapping RAM and REGISTERS
In MCUs based on CPU12, RAM and REGISTERS areas may be

mapped to any 2K space. This feature is especially important for MCUs
like HC12D60, where RAM and register areas by default start from
address 0, and 512 bytes of RAM are lost therefore.
The following compilation-time variables are used for start addresses:
• _BASE defines the start address of the REGISTERS area,

• _BASERAM defines the start address of the RAM area.

HC12 Features
R E Q U I R E D
Any of these variables or both should be set in compiler options, and
memory allocation should be adjusted in linker directives. As very first
step of reset handling the INITRM register should be set equal to bits
15:11 of the _BASERAM value, and INITRG register should be set equal
to bits 15:11 of the _BASE value.
These technique is demonstrated in the sample for Cosmic software.

Two variables are defined in makefile:
• basereg defines the start address of the REGISTERS area (i.e.

value of _BASE variable),
A G R E E M E N T
• baseram defines the start address of the RAM area (i.e. value
_BASERAM variable).
If basereg or baseram are set in makefile, the compiler options and linker
directives are adjusted, and initialization of INITRM and INITRG
registers is made automatically (corresponding procedure is defined in
“vector.c” file).
15.4.2 Interrupt Vector Table
The interrupt vector table is defined in the file “vector.c” which is

delivered with the OSEK Operating System and located in the
[...]\OSEK\SAMPLE directory. This file is the example of the interrupt
vector table coding. The user should copy this file into the project
directory and there modify it as needed.
If D-Bug12 monitor is used for development (like for

MC68HC812A4EVB), the vector table is arranged according to the
logical vector numbers used by the D-Bug12 v1.0.2 monitor. The real
setting of the vectors is performed in main() function via D-Bug12
SetVector function. The sample contains the code needed to set vectors
properly for the MC68HC812A4EVB. If the application will be started
without D-Bug12, it may be necessary to re-arrange the vector table
according to the physical order of the interrupts vectors in the vector
table. For example, if SDI is used for development (like for
M68EVB912D60), the vector table is arranged according to physical
location of the vector numbers.

R E Q U I R E D
15.4.3 The Banked Memory Model Support
15.4.3.1 Banked Memory Model Overview
In general, the system configuration option HCBankCode specifies that

memory bank switching is supported by the OSEK OS. This property is
hardware-dependent and compiler-dependent. The hardware-
dependent means that it can be applied only to some micro controllers
of the M68HC12 family (MC68HC912DA128/DG128/DT128) which
have the ability to extend the address range of the CPU beyond the
A G R E E M E N T
64KB limit given by the 16 CPU address lines. The compiler-dependent

means that the mechanism of the near and far functions must be
supported by compiler.
In case of HCBankCode is set to TRUE the user’s application part of

code (the task code) will be placed into expanded memory (into the
memory banks) and OSEK OS will provide task bank value
saving/restoring while OSEK OS manipulates with TASKs allocated to
the different banks. OSEK OS code and data will be allocated to non-
banked memory together with interrupt handlers.
In current version of OSEK OS these properties are implemented for

Cosmic C-compilers and the board M68EVB912D60 with DA128 chip
(the user should set OSHC12D128 compiler definition).
The following diagram illustrates the memory paging scheme:

HC12 Features
R E Q U I R E D
Address (hex)
$0000
– start-up code
Non-banked – OSEK OS code
memory – ISR
$FFFF
$08000
Bank 0
A G R E E M E N T
$0BFFF
$18000
– task code
Bank 1 – any functions called
$1BFFF from the task/ISR
– other application code
•••
$68000
Bank 6
$6BFFF
Figure 15-1. Banked Memory Model
15.4.3.2 Configuration of the Application for Banked Memory
In general, the following steps should be performed to configure

application for banked memory:
1. Identify application code to be allocated in various banks.

Typically, task code as well as application library code may be
located in the banked memory;
2. Emphasize the banked code in the source files. Compiler
#pragma directive is used to start banked section, which is
identified by the section name. Alternative way is to do not
explicitly identify banks in the code, and allow linker to do re-
location of the code into the banks;
3. Turn on the HCBankCode property in the configuration file. (Note
that MemoryBank property of the tasks is ignored, and may have
any value therefore. It is designed for future extensions);

R E Q U I R E D
4. Alter compiler options to make all the functions banked by default.

The non-banked functions should have near modifier;
5. In the linker directive file locate banked sections into the physical
banks.
More details may be found in the sample code and makefile, as well in
the compiler User’s manuals.
15.4.3.3 Cosmic Compiler Issue

A G R E E M E N T
The compiler supports bank switching for code only, using the internal
window mechanism provided by the MC68HC12 processor, or using any
external user provided mechanism. Bank switching is supported via:
@far type qualifier to describe a function relocated in a different bank.

Calling such a function implies a special calling sequence, and a special
return sequence. Such a function has to be defined @far and referenced
as @far in all the files using it. The compiler also provides a specific
option +modf to automatically consider all the functions to be @far.
Linker options are required to ensure proper physical and logical

addresses computations. The linker is also able to automatically fill
banks without any need to take care of the page boundaries.
Compiler pragma for banked memory
The following #pragma directive is used to start banked section bank1:
#pragma section (bank1)
Compiler options for banked memory
The following compiler option is used to make all functions banked by

default (except implicitly defined as near):
-m modf:hmodf.h
+modf
Linker directives for banked memory
The following directive is used to locate the banked section bank1 in the
physical bank #1:

HC12 Features
R E Q U I R E D
+seg .bank1 -b 0x18000 -p1
15.4.4 Recommendations on System Properties
15.4.4.1 UseMainStack property
It is recommended to turn ON this property. It reduces the needed

amount of RAM for stacks, since the same memory area is used during
start-up (for main() program), for the interrupt stack and for the
scheduler stack. Moreover, the size of the OS code is also reduced
A G R E E M E N T
(ROM for the Operating System).
However, the user is responsible for allocation appropriate stack in the

linker directive file. (This file is used as an inline text in the sample
makefile).
15.4.4.2 UseSameContext Property
It is recommended to turn ON this property to use only preemptive

context for all tasks. It is important for CPU12 so the code to process the
non-preemptive context is quite big, and it leads to additional ROM and
RAM consuming and reduces system performance. When this property
is ON, task switching is performed faster and the required ROM amount
is reduced. Use of different contexts (preemptive and non-preemptive)
have a sense for CPUs with many registers if some of them are not
included into the non-preemptive context.
15.4.4.3 InterruptMaskControl Property
It is better to keep this property turned OFF, if it is not absolutely

necessary to control “I” bit of the Condition Code Register. Using of this
property increases the amount of ROM for the OS code and requires
additional time for all system services. Generally, this property is
intended for CPUs with several interrupt priority levels, e.g. CPU16.

R E Q U I R E D
15.4.4.4 CounterSize Property
In spite that CPU12 processes 16-bits variables, the best performance

is achieved when operands are byte-sized. Therefore, it is
recommended to use 8-bit counters (CounterSize = 8) to increase
overall performance and reduce the needed amount of RAM. Of course,
it is possible to use 16-bit and 32-bit counters, but it leads to additional
RAM and time consuming, especially in case of 32-bit counters!
15.4.4.5 Unused Services

A G R E E M E N T
To reduce ROM consuming it is recommended to exclude OS services

which are not used in the application from the OS code with the help of
“excluding” system properties. It helps to save memory.
15.4.5 System Timer Hardware
The special OS attributes are introduced to define hardware interrupt

source and desired parameters for counter considered to be system
timer.
In the table below all possible values to define these parameters are
listed.

HC12 Features
R E Q U I R E D
Table 15-1. Parameters to define System Timer hardware
PrescalerValue
TimerHardware TimerModuloValue
bit7 bit6 bit5 bit4 bit3 bit2 bit1 bit0
MC68HC812A4
TIMTOI BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 N/A
TIMOC0 BCSC BCSB BCSA MCSB MCSA PR2 PR1 PR0 0...65535
A G R E E M E N T
RTI BCSC BCSB BCSA MCSB MCSA RTR2 RTR1 RTR0 N/A
MC68HC912B32, MC68HC912D60, MC68HC912DA128
TIMTOI N/A N/A N/A N/A N/A PR2 PR1 PR0 N/A
TIMOC0 N/A N/A N/A N/A N/A PR2 PR1 PR0 0...65535
RTI N/A N/A N/A N/A N/A RTR2 RTR1 RTR0 N/A
additionally for MC68HC912D60, MC68HC912DA128
MDC N/A N/A N/A N/A N/A N/A MCPR1 MCPR0 0...65535
The bits 7:6:5 of the prescaler contain the values to be set in the base
clock select bits BCSC:BCSB:BCSA of the clock control register
CLKCTL. The bits 4:3 of the prescaler contain the values to be set in the
module clock select bits MCSB:MCSA of the clock control register
CLKCTL. The bits 2:1:0 of the prescaler contain the values to be set
either in the timer prescaler select bits PR2:PR1:PR0 of the timer
interrupt mask 2 register TMSK2 or in the base clock select bits

R E Q U I R E D
RTR2:RTR1:RTR0 of the real-time interrupt control register RTICTL.

The bits 1:0 of prescaler can also contain the values to be set in the
Modulus Counter Prescaler select bits MCPR1:MCPR0 of the MCCTL
register.
NOTE: MC68HC912B32 MCU does not allow the following values of prescaler
bits PR2:PR1:PR0: 1:1:0 and 1:1:1.
Thus, the system definition statements for the OSEK Operating System
A G R E E M E N T
for HC12 MCU family has the following form:
OS <name> {
...
SysTimer = <SysTimerDefined>;
TimerHardware = <HardwareType>;
Prescaler = <PrescalerDefined>;
PrescalerValue = <HardwarePrescaler>;
TimerModulo = <ModuloDefined>;
TimerModuloValue = <HardwareModulo>;
...
};
For example, the system timer is based on the Output Compare channel
5 interrupt, with no Prescaler and Modulo Counter value equals 1024. In
this case the definition statement can be the following:
OS <name> {
...
SysTimer = TRUE;
TimerHardware = TIMTOI;
Prescaler = FALSE;
...
};
Another example, the system timer based on the Real-Time Interrupt,

with Prescaler value equals 1 and no Modulo value. In this case the
definition statement can be the following:
OS <name> {
...
SysTimer = TRUE;
TimerHardware = RTI;
Prescaler = TRUE;
PrescalerValue = 0x01;

HC12 Features
R E Q U I R E D
TimerModulo = FALSE;
...
};
NOTE: The system timer will not be triggered if the EntryExitISR property is
turned OFF!
15.4.6 Scheduler Architecture
If an application does not use resources, it is strongly recommended to
A G R E E M E N T
use simplified scheduler (the property SimpleScheduler must be turned
ON). In this case all tasks running concurrently must have different
priorities.That is, two tasks may have the same priority if they are never
both in ready state and they must have different priorities otherwise. The
simple scheduler uses prioritized table of task nodes and works faster. It
requires less amount of ROM and RAM than the standard scheduler.
If an application uses resources or claims to have more than one ready

task per priority, the SimpleScheduler option should be turned off. In this
case the POSIX-like scheduler is used. To reduce RAM consuming the
number of priorities should be kept as small as possible.
15.4.7 Alarms Configuration
If the application does not use cyclic alarms, it is recommended to turn

CyclicAlarm property OFF. In this case the cyclic field is excluded from
the alarm control block, which decreases RAM usage. In addition, the
code to handle cyclic alarms is also excluded from the system,
decreasing ROM usage and improving performance of the alarm
services. As a side effect, stack usage is also decreased, because there
is no need to pass cycle parameter for SetAbsAlarm and SetRelAlarm
services, and less stack space is required for internal computations.
To decrease RAM usage, the AlarmList property may be turned OFF. In

this case, the alarms are collected together in one table, and linked to
the counter. Therefore, the fields, which are required for list handling, are
eliminated from the alarm control block. However, to keep performance
the number of alarms attached to one counter, should be minimized. To

R E Q U I R E D
reach that, additional counters may be added, and alarms may be

rearranged.
If the RAM size is limited, it is highly recommended to turn

MinAlarmRAM property ON. In this case alarm control block size is
significantly decreased, especially when AlarmList property may be
turned OFF. However, the performance is slightly decreased, because
some static data are not mirrored in RAM. It should be also kept in mind,
that in this case alarms are referenced differently than in case when
MinAlarmRAM property is turned OFF.
A G R E E M E N T
15.5 Task Stack Size

Generally, the recommended minimal task stack size equals:
• 24 bytes for extended tasks if no task activation, messages, and

there are no interrupts in the system;
• 32 bytes for extended tasks if no task activation, messages and
interrupts are supported in the system;
• 48 bytes for other cases.
In order to reduce amount of memory, needed for task stacks,

UseCommonArea property may be turned ON. In this case the global

data area is used for parameters and local variables for most internal
system functions. (For operating system calls convenient compiler
generated calls are used).
In particular, UseCommonArea property allows to save stack space

while calling the following services:
• ActivateTask - up to 4 bytes;
• CounterTrigger - up to 12 bytes;
• SetRelAlarm/SetAbsAlarm - up to 4 bytes.

R E Q U I R E D
Section 16. Application Troubleshooting
16.1 Contents
16.2 System Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .193
A G R E E M E N T
16.3 Using OS Extended Status for Debugging . . . . . . . . . . . . . . .193
16.4 Context Switch Routines. . . . . . . . . . . . . . . . . . . . . . . . . . . . .194
16.5 Stack Errors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
16.6 Known Problems. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .195
In this section some advice is given which may be useful for developers
working with the OSEK Operating System.
16.2 System Generation

The System Generator is used to generate the code for the OSEK
Operating System kernel and all application objects (tasks, messages,
etc.). This tool processed the configuration file created by the user and
reports about inconsistencies and errors in it. Most of possible mistakes
in application configuration process can be eliminated with the help of
SG. See Section 12 System Configuration and Section 14 Building
of Application about system generation process.
If an undocumented problem arises please provide us with the detailed

description of it and we will help to resolve the problem. See
Section 2.6 Technical Support Information for contact information.
16.3 Using OS Extended Status for Debugging

It is strongly recommended to use Operating System Extended Status
when you develop an application to analyze return codes of system
MOTOROLA Application Troubleshooting 193

Application Troubleshooting
R E Q U I R E D
services. Such method is more memory and time consuming but it

allows the user to save time for errors eliminating. Error codes returned
by the OSEK OS services covers most of possible errors that can arise
during development. Therefore it is useful to check these codes after a
service call to avoid error that can lead to the system crash. For
example, a task can perform the TerminateTask service while it is still
occupying a resource. This service will not be performed and the task will
remain active (running). In case of Extended Status the
E_OS_RESOURCE error code is returned and it is possible to detect
this situation. But in the system without Extended Status there is no
A G R E E M E N T
additional check and this error is not indicated and the application
behavior will be unpredictable!
When all errors in an application will be eliminated you may turn off the
Extended Status and remove additional status checks from the
application to get the reliable application of the smaller size.
16.4 Context Switch Routines

Breakpoints, traces and time stamps can be integrated individually into
the application software with the help of context switch hook routines
PreTaskHook and PostTaskHook.
Example: The user can set time stamps enabling him to trace the
program execution at the following locations before calling operating
system services:
• When activating or terminating tasks;

• When setting or clearing events in the case of Extended Tasks;
• At explicit points of the schedule (ChainTask, Schedule);
• At the beginning or the end of ISR;
• When occupying and releasing resources or at critical locations.
The Operating System needs not include a time monitoring feature

which ensures that each or only, e.g. the lowest-priority task has been
activated in any case after a defined maximum time period.
194 Application Troubleshooting MOTOROLA

Stack Errors
R E Q U I R E D
The user can optionally use hook routines or establish a watchdog task
that takes “one-shot displays” of the operating system status.
16.5 Stack Errors

Stack errors may be due to the stack pointer being incorrect or to stack
contents being incorrect. Stack content problems are possible when
using pointers into stack variables, but stack pointer problems seem to
be more common. The symptom of either problem is usually a task or
ISR executing normally, but then when a return is performed, the
A G R E E M E N T
program executes at some incorrect address.
Problems with a program running wild may sometimes be caught by

always filling the unused program memory with $00, which the HC12
‘test’ opcode does, and setting a breakpoint at the illegal opcode vector
address.
ISRs using OS services or reenabling interrupts should begin with the

EnterISR service and end via the LeaveISR service (see
Section 6 Interrupt Processing). If the number of EnterISR and
LeaveISR invocations do not match (e.g., in case of nested interrupts),
the stack will be incorrect. See also Section 6 Interrupt Processing
about using variables in ISRs.
Tasks should have enough stack for their execution, therefore it is
recommended to pay attention on task definition statements to provide
each task with a needed amount of stack. See Section 15 HC12
Platform-Specific Features.
16.6 Known Problems

None.
MOTOROLA Application Troubleshooting 195

R E Q U I R E D
A G R E E M E N T
196 Application Troubleshooting MOTOROLA

R E Q U I R E D
Section 17. System Services
17.1 Contents
17.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .197
A G R E E M E N T
17.3 Task Management Services . . . . . . . . . . . . . . . . . . . . . . . . . .199
17.4 ISR Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . .210
17.5 Resource Management Services . . . . . . . . . . . . . . . . . . . . . .220
17.6 Counters and Alarms Management Services . . . . . . . . . . . . .225
17.7 Event Management Services . . . . . . . . . . . . . . . . . . . . . . . . .242
17.8 Communication Management Services . . . . . . . . . . . . . . . . .249
17.9 Operating System Execution Control . . . . . . . . . . . . . . . . . . .259
17.2 General
This section provides detailed description of all OSEK OS run-time
services including hook routines. Also declarations of system objects –
the constructional elements – are described here. The services are
arranged in logical groups – for the task management, the interrupt
management, etc.
Examples of code are also provided for every logical group. These
examples have no practical meaning, they only show how it is possible
to use OS calls in an application.
The following scheme is used for service description:
Declaration element:
Syntax: Operating System interface in ANSI-C syntax.
Input List of all input parameters.
MOTOROLA System Services 197

System Services
R E Q U I R E D
Description: Explanation of the constructional element.
Particularities: Explanation of restrictions relating to the utilization.
Conformance: Specifies the lowest Conformance Class where the

declaration element is provided.
Service description:
Syntax: Operating System interface in ANSI-C syntax. The

return value of the service is always of data type
A G R E E M E N T
StatusType.
Input: List of all input parameters.
Output: List of all output parameters. Transfers via the

memory use the memory reference as input
parameter and the memory contents as output
parameter. To clarify the description, the reference is
already specified among the output parameters.
Description: Explanation of the functionality of the operating

system service.
Particularities: Explanations of restrictions relating to the utilization

of the service.
Status: List of possible return values.
Standard: List of return values provided in the operating

system’s standard version. Special case – service
does not return.
Extended: List of additional return values in the operating

system’s extended version.
Conformance: Specifies the lowest Conformance Class where the

service is provided.
The specification of operating system services uses the following

naming conventions for data types:
...Type: describes the values of individual data.
198 System Services MOTOROLA

System Services
Task Management Services
R E Q U I R E D
...RefType: describes the identifier referencing an object1.
It is also possible to see all predefined OSEK OS data types in system

header files.
17.3 Task Management Services
17.3.1 Data types
A G R E E M E N T
management:
• TaskType The abstract data type for task identification;

• TaskRefType The data type to refer variables of the
TaskType data type;
• TaskStateType The data type for variables to store the state
of a task;
• TaskStateRefType The data type to refer variables of the
TaskStateType data type.
17.3.2 Constants
The following constants are used within the OSEK Operating System to
indicate task states:
• RUNNING Constant of data type TaskStateType for

task state running
• WAITING Constant of data type TaskStateType for
task state waiting
• READY Constant of data type TaskStateType for
task state ready
• SUSPENDED Constant of data type TaskStateType for
task state suspended
1. E.g., a pointer or an index

System Services
R E Q U I R E D
The following constant is used within the OSEK OS to indicate task:
• INVALID_TASK Constant of data type TaskType for a not

defined task
17.3.3 Conventions
Within the application of the OSEK OS a task should be defined

according to the following pattern:
A G R E E M E N T
TASK ( TaskName )
{
...
}
The name of the task function will be generated from TaskName by

macro TASK.
The only data types must be used for operations with tasks.
17.3.4 Task Declaration
To refer to a task the constructional element should be used to declare

the task before references to it:
Syntax:
DeclareTask( TaskType <TaskName> )
Input:
• <TaskName> – a reference to the task
Description:
DeclareTask serves as an external declaration of a task. The function

and use of this service are similar to that of the external declaration of
variables.
Particularities: none
Conformance: BCC1, BCC2, ECC1, ECC2

System Services
R E Q U I R E D
17.3.5 ActivateTask
Syntax:
StatusType ActivateTask( TaskType <TaskName> );
Input:
• <TaskName> – a reference to the task.
Output:
• None.
A G R E E M E N T
Description:
The specified task TaskName is transferred from the suspended state

into the ready state. All needed actions for task initialization are
accomplished by the system according to information from the task
configuration table (e.g., dynamic stack and node allocation).
Particularities:
The service may be called both on the task level (from a task) and the
interrupt level (from ISR). This service may be called also by
StartupHook hook routine.
In the case “call from ISR”, the operating system will reschedule tasks
only after the ISR completion.
If the system configuration option ActivateTask is turned off the service

is excluded from the OSEK OS code.
Status:
• Standard:
– E_OK – no error;
• Extended:
– E_OS_ID – the task identifier TaskName is
invalid;
– E_OS_LIMIT – too many task activations of the
specified task or there is no enough
resources to activate the task.

System Services
R E Q U I R E D
17.3.6 TerminateTask
Syntax:
StatusType TerminateTask( void );
Input:
• None.
A G R E E M E N T
Output:
• None.
Description:
This service causes the termination of the calling task. The calling task
is transferred from the running state into the suspended state and
releases all occupied system resources (that is, the stack, the task node,
etc.) except task has multiply activation requests.
Particularities:
The resources occupied by the task must have been released before.
If the call was successful, TerminateTask does not return to the call level
and the status can not be evaluated. If the service TerminateTask is
called successfully, it enforces a rescheduling.
If the system with extended status is used, the service returns in case of
error, and provides a status which can be evaluated in the application.
If the system configuration option TerminateTask is turned off the

service is excluded from the OSEK OS code.
Status:
• Standard:
– No return to the caller.
• Extended:
– E_OS_RESOURCE – the task still occupies resources;

System Services
R E Q U I R E D
– E_OS_CALLEVEL – a call at the interrupt level.
17.3.7 ChainTask
Syntax:
StatusType ChainTask( TaskType <TaskName> );
Input:
A G R E E M E N T
• <TaskName> – a reference to the sequential succeeding
task to be activated.
Output:
• None.
Description:
This service causes the termination of the calling task. After termination
of the calling task a succeeding task <TaskName> is activated
sequentially. Using this service, it ensures that the succeeding task only
starts to run after the calling task has been terminated.
Particularities:
If the succeeding task is identical with the current task, this does not
result in multiple requests. In this case the task will be terminated and
after that activated again. It can be used, e.g. if multiple activation is
disabled but it is needed to restart a task. If it is not needed to have such
tricks the system property ChainTaskItself can be turned off to decrease
the task control block size.
The resources occupied by the calling task must have been released
before.
If called successfully, ChainTask does not return to the call level and the
status can not be evaluated. In this case a rescheduling is enforced.

System Services
R E Q U I R E D
If the version with Extended Status is used, the service returns in case
of error to the calling task, and provides a status which can be evaluated
by the application.
If the system configuration option ChainTask is turned off the service is

excluded from the OSEK OS code.
Status:
• Standard:
– If the service is called successfully, then no return to the caller;
A G R E E M E N T
• Extended:
– E_OS_ID – the task identifier is invalid;
– E_OS_LIMIT – too many activations of
<TaskName> or there is not enough
resources to activate the task.
– E_OS_RESOURCE – the calling task still occupies
resources;

17.3.8 Schedule
Syntax:
StatusType Schedule( void );
Input:
• None.
Output:
• None.
Description:
If a higher-priority task is ready, the current task is put into the ready
state and a higher-priority task is executed. Otherwise the calling task is

System Services
R E Q U I R E D
continued without delay. By means of using this service the task
explicitly yields control to a higher-priority ready task (if any exists).
Particularities:
In not full-preemptive systems Schedule enables a processor

assignment to other tasks in application-specific locations. Schedule
does not cause rescheduling if task owns RES_SCHEDULER as
resource (See Section 17.5.4 GetResource).
If the system configuration option Schedule is turned off the service is
A G R E E M E N T
Status:
• Standard:
– E_OK – no error.
• Extended:
17.3.9 GetTaskId
Syntax:
StatusType GetTaskId( TaskRefType <TaskName> );
Input:
• None.
Output:
• <TaskName> – a reference to the task which is currently

active. The system saves the task reference
into the variable <TaskName>.
Description:
This system service returns the name (<TaskName>) of the task which
is currently active.

System Services
R E Q U I R E D
Particularities:
This service is useful, for instance, in the case if two or more tasks
shares the same piece of code and in some point of the code the coming
actions depend on which task is executed in the moment. This service
may be called by ErrorHook, PreTaskHook and PostTaskHook hook
routines. If the name of the task can not be evaluated (no task currently
active), the value INVALID_TASK will be returned.
If the system configuration option GetTaskId is turned off the service is

A G R E E M E N T
Status:
• Standard:
• Extended:
17.3.10 GetTaskState
Syntax:
StatusType GetTaskState( TaskType <TaskName>,

TaskStateRefType <State> );
Input:
Output:
• <State> – a reference to the state of task

<TaskName>.
Description:
Returns the state of the specified task <TaskName> (running, ready,

waiting, suspended) at the time of calling GetTaskState.

System Services
R E Q U I R E D
Particularities:
interrupt level (from ISR). This service may be called by ErrorHook,
PreTaskHook and PostTaskHook hook routines.
Within a full-preemptive system, calling this operating system service

only provides a meaningful result if the task runs in an interrupt disabling
state at the time of calling. When a call is made from a task in a full-
preemptive system, the result may already be incorrect at the time of
evaluation.
A G R E E M E N T
If the system configuration option GetTaskState is turned off the service
is excluded from the OSEK OS code.
Status:
• Standard:
• Extended:
– E_OS_ID – the task identifier is invalid.
17.3.11 GetTCBInfo
Syntax:
StatusType GetTCBInfo( TaskControlBlockRefType

<TaskControlBlock>);
Input:
• None.
Output:
• <TaskControlBlock> – a reference to a memory block

where contents of the running task
control block are to be copied.
Description:

System Services
R E Q U I R E D
Copies contents of the running task control block by the address

specified in <TaskControlBlock> parameter.
This service is not defined in the OSEK OS v.2.0 rev. 1 specification.

This is an extension of OSEK OS.
Particularities:
interrupt level (from ISR). This service may be called by ErrorHook,
PreTaskHook and PostTaskHook hook routines.
A G R E E M E N T
If called by PreTaskHook hook routine this service copies contents of a

control block of a task transiting to the running state, that is task being
started or resumed.
If called by PostTaskHook hook routine this service copies contents of a

control block of a task transiting to the waiting, ready or suspended state,
that is task being terminated or preempted.
There is no memory control performed. User is responsible to ensure

that <TaskControlBlock> parameter points to appropriate memory block.
The system configuration option GetTCBInfo must be turned on to

include this service in the OSEK OS code.
Status:
• Standard:
• Extended:
– E_OS_NOFUNC – no running task, nothing done.
17.3.12 Examples for Task Management Services
The example below assumes three tasks TaskA, TaskB and TaskC.
These tasks use all OSEK OS task management services to coordinate
each other.

System Services
R E Q U I R E D
The following definitions can be made in the definition file (for HC08):
...
TASK TaskA {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 3;
StackMethod = OWNSTACK;
STACKSIZE = 64;
};
TASK TaskB {
TYPE = EXTENDED;
A G R E E M E N T
SCHEDULE = FULL;
AUTOSTART = FALSE;
PRIORITY = 2;
StackMethod = POOLSTACK;
StackPool = POOL1;
};
TASK TaskC {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 1;
StackMethod = NODESTACK;
};
...
The C-language file:
DeclareTask( TaskA )
DeclareTask( TaskB )
DeclareTask( TaskC )
TASK( TaskA )
{
TaskType task;
TaskControlBlockType tcb;
... /* any user’s code */
ActivateTask( TaskB ); /* activate TaskB */

Schedule(); /* yields CPU to a higher-priority task */
GetTaskId( &task );
/* copies contents of TaskA control */
GetTCBInfo( &tcb ); /* block to tcb variable */
if( task == TaskA ) ActivateTask( TaskC );

else ChainTask( TaskB );
TerminateTask();
}

System Services
R E Q U I R E D
TASK( TaskB )
{
TaskStateType state;
EventMaskType cc = 0x4;
GetTaskState( TaskC, &state ); /* check the state of TaskC */

switch( state ) /* and perform appropriate actions */
{
case READY: break;
case WAITING: SetEvent( TaskC, cc );
A G R E E M E N T
break;
case SUSPENDED: ChainTask( TaskC );
break;
}
}
TASK( TaskC )
{
TaskStateType stateA, stateB;
while( 1 )
{
GetTaskState( TaskA, &stateA );
GetTaskState( TaskB, &stateB );
if( stateA == READY && stateB == SUSPENDED ) ChainTask( TaskB );

if( stateB == READY && stateA == SUSPENDED ) ChainTask( TaskA );
if( stateA == READY && stateB == READY ) Schedule();
}
}
17.4 ISR Management Services
17.4.1 Data Types
The OSEK OS establishes the following data types for the interrupt
management:
• IntDescriptorType – the data type for logical interrupt

descriptors;

System Services
ISR Management Services
R E Q U I R E D
• IntDescriptorRefType – the data type to refer variables of the
IntDescriptorType data type.
17.4.2 Constants
• INITIAL_INTERRUPT_DESCRIPTOR
– constant of data type IntDescriptorType for
initial interrupt level (see
Section 11.5 Start-up Routine).
A G R E E M E N T
17.4.3 Conventions
Within the application an Interrupt Service Routine should be defined

according to the following pattern:
ISR( IsrName )
{
...
}
The keyword ISR is the macro for compiler specific interrupt function
modifier, which is used to generate valid code to enter and exit ISR.
If Interrupt Service Routine is defined by means of keyword ISR usage,

then it should be declared according to the following pattern:
DeclareISR1( IsrName )
The same name shall be used for corresponding ISR object definition
(see Section 13.11 ISR Definition).
17.4.4 EnterISR
Syntax:
StatusType EnterISR( void );
Input:
1. This service is not established by OSEK OS v.2.0 Spec. This is an extension of OSEK OS.

System Services
R E Q U I R E D
• None.
Output:
• None.
Description:
EnterISR establishes conditions needed to request OS services within

an interrupt service routine. Inside EnterISR the following activities are
executed if needed:
A G R E E M E N T
• Registration of the switching to the interrupt level inside the

operating system;
• A switch of the current context (to the ISR stack).
This function is called from the begin of the interrupt service routine,
when hardware registers are pushed onto the current stack either by
hardware or by compiler generated code. This way, the context of the
running task, or ISR, or scheduler idle loop is known on the function
entry. This context is named interrupt stack frame.
If the task is interrupted, then the pointer to the interrupt stack frame is
stored in the stack pointer field of the running task. After that the top of
the ISR stack is loaded into the CPU stack pointer, and value of the
nested interrupts counter is incremented.
If the ISR is interrupted, then the value of the system counter of nested
interrupts is advanced by one, and function returns to the caller.
If the scheduler idle loop is interrupted, then interrupt stack frame is

ignored, because LeaveISR function returns directly to the scheduler
idle loop. The top of the ISR stack is loaded into the CPU stack pointer,
and value of the system counter of nested interrupts is changed to one.
Particularities:
EnterISR establishes the possibility to use operating system services in

an ISR. It is necessary to place EnterISR before the first call of an
operating system service.

System Services
R E Q U I R E D
See description of interrupt categories in section Section 6.4 ISR
Categories.
This service is not implemented if the system configuration option

EntryExitISR or EnterISR are turned off in the configuration file.
Status:
• Standard:
– None.
• Extended:
A G R E E M E N T
– None.
17.4.5 LeaveISR
Syntax:
StatusType LeaveISR( void );
Input:
• None.
Output:
• None.
Description:
LeaveISR is the counterpart of EnterISR and resets the conditions to

request operating system services in an ISR. Inside LeaveISR the
following functions are executed if needed:
• Registration of the switching back from the interrupt level inside

the operating system;
• A switch of the current context (for example a switch from the ISR
stack back to the OS context or to the context of the task running
before).
In case of an error the function returns to the call level.

System Services
R E Q U I R E D
This function is called in the end of the interrupt service routine.
If the ISR was interrupted by the corresponding EnterISR, then the value
of the system counter of nested interrupts is decremented by one, and
the function returns to the caller, because the current ISR is considered
as nested one.
If the caller is the outermost ISR (task or scheduler idle loop was
interrupted), then the function calls the scheduler to update the pointer
to the running task. After this call the function loads the task stack pointer
A G R E E M E N T
into the CPU stack pointer in assumption, that task stack pointer
contains the address of valid interrupt stack frame. If there is no running
task, then functions goes directly to the scheduler idle loop. In any case
the value of the nested interrupts counter is decremented by one.
Particularities:
LeaveISR eliminates the possibility of using OS services in an ISR. It is

highly recommended to place LeaveISR at the end of the ISR.
See description of interrupt categories in section Section 6.4 ISR

Categories.

EntryExitISR or LeaveISR are turned off in the configuration file.
Status:
• Standard:
– None.
• Extended:
– None.
17.4.6 EnableInterrupt
Syntax:
StatusType EnableInterrupt( IntDescriptorType <Mask> );

System Services
R E Q U I R E D
Input:
• <Mask> – a mask of interrupts to be enabled. In the

mask, a “1” means “enable”.
Output:
• None.
Description:
This service enables interrupts specified by <Mask>. In the case if
A G R E E M E N T
several interrupts can be controlled simultaneously, this service allows
enabling of several interrupts.
Particularities:
The service may be called from an ISR and from the task level.
For HC12 this service is intended to control only the “I” bit in the
Condition Code Register.
This service should only be used with care. It destroys the contents of
CCR according to C language conventions. In case of use it is highly
recommended to know the reaction upon system behavior!
To save the current state of interrupts the application must use
GetInterruptDescriptor before.
This service is executed also in case of return of the state is not equal
E_OK.

EntryExitISR or EnableInterrupt are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_NOFUNC – at least one of the interrupts was not
disabled.

System Services
R E Q U I R E D
17.4.7 DisableInterrupt
Syntax:
StatusType DisableInterrupt( IntDescriptorType <Mask> );
Input:
• <Mask> – a mask of interrupts to be disabled. In the

A G R E E M E N T
mask, a “1” means “disable”.
Output:
• None.
Description:
This service disables interrupts specified by <Mask>. In the case if

several interrupts can be controlled simultaneously, this service allows
disabling of several interrupts.
Particularities:
For HC12 this service is intended to control only the “I” bit in the
This service should only be used with care. It destroys the contents of
CCR according to C language conventions. In case of use it is highly
recommended to know the reaction upon system behavior!
To save the current state of interrupts the application must use

GetInterruptDescriptor before.
This service is executed also in case of return of the state is not equal
E_OK.

EntryExitISR or DisableInterrupt are turned off in the configuration file.
Status:

System Services
R E Q U I R E D
• Standard:
• Extended:
– E_OS_NOFUNC – at least one of the interrupts was not
enabled.
17.4.8 GetInterruptDescriptor
A G R E E M E N T
Syntax:
StatusType GetInterruptDescriptor( IntDescriptorRefType <Mask> );
Input:
• None.
Output:
• <Mask> – a reference to the interrupt mask to be

filled. In the mask, a “1” means (Group of)
Interrupt is enabled”.
Description:
Query of interrupt status and returns the current CPU interrupt mask.
Particularities:
For HC12 this service is intended to get only the value of the “I” bit in the

EntryExitISR or GetInterruptDescriptor are turned off in the configuration
file.
Status:
• Standard:

System Services
R E Q U I R E D
• Extended:
– None.
17.4.9 Examples for Interrupt Management Services
Below examples for ISR category 1, 2 and 3 are presented.

A G R E E M E N T
...
OS myOS {
...
IsrStackSize = 64;
InterruptMaskControl = TRUE;
DisableInterruptMask = 0x0;
EnableInterruptMask = 0x8;
TaskLevelMask = 0x8;
...
};
TASK TaskB {
TYPE = EXTENDED;
SCHEDULE = FULL;
PRIORITY = 2;
AUTOSTART = FALSE;
StackPool = POOL1;
};
TASK IndTask {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 1;
STACKSIZE = 64;
};
COUNTER Ctr1 {
TICKSPERBASE = 1;
};
MESSAGE Temp {
ITEMTYPE = "char";
ITEMS = 1;
WithCopy = TRUE;

System Services
R E Q U I R E D
};
MESSAGE Wrn {
TYPE = QUEUEDMESSAGE;
ITEMTYPE = "MSGCTYPE";
ITEMS = 6;
ReceiverNum = 3;
};
ISR ISR1_handler {
CATEGORY = 1;
};
ISR ISR2_handler {
CATEGORY = 2;
};
A G R E E M E N T
ISR ISR3_handler {
CATEGORY = 3;
};
...
The C-language code can be the following (for HC08):
ISR category 1:
char CREG, DREG;

char data1;
DeclareISR( ISR1_handler )
...
ISR( ISR1_handler )
{
if( CREG != 0xC0 ) CREG |= 0x40;
else CREG |= 0x03;
DREG = data1;
}
ISR category 2:
TaskStateType stateB;
DeclareCounter( Ctr1 )
DeclareTask( TaskB )
...
ISR( ISR2_handler )
{
CounterTrigger( Ctr1 );
GetTaskState( TaskB, &stateB );
if( stateB == SUSPENDED ) ActivateTask( TaskB );
}
ISR category 3:
DeclareTask( IndTask )

System Services
R E Q U I R E D
OSMSGTemp _Temp;
OSMSGWrn _Wrn;
int temp;
ISR( ISR3_handler )
{
/* normal temperature, do nothing */
if( (temp >= LIMIT_L ) && (temp <= LIMIT_H) ) goto exit;
/* temperature is below critical value: */
if( LIMIT_L >= temp )
{ EnterISR();
SendMessage( Temp, _Temp ); /* send msg to notify */
A G R E E M E N T
goto leave;
}
/* temperature is higher critical value: */
if( (temp >= LIMIT_H) )
{ EnterISR();
SendMessage( Wrn, _Wrn ); /* send alarm message */
ActivateTask( IndTask );
leave: LeaveISR();
}
exit: ;
}
17.5 Resource Management Services

17.5.1 Data types
The OSEK OS establishes the following data type for the resource
management:
• ResourceType – the abstract data type for referencing a

resource;
The only data type must be used for operations with tasks.
17.5.2 Constants
• RES_SCHEDULER – constant of data type ResourceType (see
Section 7.3.2 Scheduler as a Resource).

System Services
Resource Management Services
R E Q U I R E D
17.5.3 Resource Declaration
To refer to a resource the constructional element should be used to

declare the resource before its using:
Syntax:
DeclareResource( ResourceType <ResName> )
Input:
• <ResName> – a reference to the resource.
A G R E E M E N T
Description:
DeclareResource serves as an external declaration of a resource. The

function and use of this service are similar to that of the external
declaration of variables.
17.5.4 GetResource
Syntax:
StatusType GetResource( ResourceType <ResName> );
Input:
Output:
• None.
Description:
This call serves to enter a critical section in the code that is assigned to
the referenced resource. A critical section must always be left using
ReleaseResource.
The E_OS_LIMIT error code is not processed yet.

System Services
R E Q U I R E D
Particularities:
This function is fully supported only beginning from the Conformance

Class BCC2. In the lower Conformance Classes only the standard
resource scheduler can be occupied via the constant
RES_SCHEDULER.
Corresponding calls to GetResource and ReleaseResource should

appear within the same function on the same function level. Generally,
critical sections should be short. Nested resource occupation is only
A G R E E M E N T
allowed if the inner critical sections are executed completely within the
surrounding critical section.
Regarding Extended Tasks, please note that WaitEvent within a critical

section is prohibited.
E_OS_ACCESS error code is not returned by GetResource service if

more than 8 resources (including RES_SCHEDULER) are defined in the
application or FastResource configuration option is turned on or
ResourceAccessCheck configuration option is turned off.

Resources or GetResource are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ID – the resource identifier is invalid;
– E_OS_ACCESS – the inadmissible access to
resource;
– E_OS_CALLEVEL – a call at the interrupt level is not
allowed;
– E_OS_LIMIT – too many resources are occupied in
parallel.

System Services
Resource Management Services
R E Q U I R E D
17.5.5 ReleaseResource
Syntax:
StatusType ReleaseResource( ResourceType <ResName> );
Input:
Output:
• None.
A G R E E M E N T
Description:
This call serves to leave the critical section in the code that is assigned
to the referenced resource. An ReleaseResource call is a counterpart of
an GetResource service call.
The E_OS_ID error code is generated in the following cases:
• the resource signature is invalid – this object is not resource;

• the resource is occupied by another task, the resource is not
released in this case;
• the resource is not the last occupied resource (a nesting
processing error), the resource is released (unlinked from the list)
in this case.
Particularities:
This function is fully supported only beginning from the Conformance

Class BCC2. In the lower Conformance Classes only the standard
resource scheduler can be released via the constant
RES_SCHEDULER.
For information on nesting conditions, see particularities of

GetResource. This service is not implemented if the system
configuration option Resources or ReleaseResource are turned off in the
configuration file.
Status:

System Services
R E Q U I R E D
• Standard:
• Extended:
– E_OS_ID – the resource identifier is invalid;
– E_OS_NOFUNC – an attempt to release a resource
which is not occupied;
allowed.
A G R E E M E N T
17.5.6 Examples of Using Resources
The example below presents resource management directives.
...
TASK TASK_A {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = FALSE;
PRIORITY = 3;
StackPool = POOL1;
};
TASK TASK_B {
TYPE = BASIC;
SCHEDULE = FULL;
PRIORITY = 2;
AUTOSTART = TRUE;
RESOURCE = { SCI_res };
STACKSIZE = 64;
};
TASK SCI_TASK {
TYPE = BASIC;
SCHEDULE = FULL;
PRIORITY = 1;
AUTOSTART = TRUE;
RESOURCE = { SCI_res };
};
RESOURCE SCI_res {

System Services
Counters and Alarms Management Services
R E Q U I R E D
}
};
...
The C-language code can be the following:
DeclareTask( SCI_TASK )
DeclareResource( SCI_res )
TASK( SCI_TASK )
{
...
GetResource( SCI_res ); /* occupy the SCI resource */
A G R E E M E N T
ActivateTask( TASK_B );
GetResource( RES_SCHEDULER ); /* occupy the scheduler resource */
ReleaseResource( RES_SCHEDULER ); /* release the scheduler */
ReleaseResource( SCI_res ); /* release the SCI resource */
TerminateTask();
}
17.6 Counters and Alarms Management Services
17.6.1 Data Types and Identifiers
The following data types are established by OSEK OS to work with
counters:
• CtrRefType – the data type references a counter

• TickType – the data type represent count value in
system ticks
• TickRefType – the data type references data
corresponding to the data type TickType
• CtrInfoType – the data type represents a structure for
storage of counter characteristics. This
structure has the following elements:
– maxallowedvalue – maximum possible allowed counter
value;

System Services
R E Q U I R E D
– ticksperbase – number of ticks required to reach a

counter-specific significant unit;
– mincycle – minimum allowed number of ticks
for a cyclic alarm (only for system with
Extended Status).
All elements have the data type TickType, and the structure looks like
the following:
typedef CtrInfoType tagCIT;

struct tagCIT
A G R E E M E N T
{
TickType maxallowedvalue;
TickType ticksperbase;
TickType mincycle;
};
• CtrInfoRefType – the data type references data
corresponding to the data type CtrInfoType
The following data type is established by OSEK OS to work with alarms:
• AlarmBaseType – the data type represents a structure for

storage of alarm characteristics. It is the
same as CtrInfoType;
• AlarmBaseRefType – the data type references data
corresponding to the data type

AlarmBaseType;
• AlarmType – the data type represents an alarm element.
17.6.2 Constants
For system counter, which is always a time counter, the special

constants are provided by the operating system:
• OSMAXALLOWEDVALUE
– maximum possible allowed value of the
system timer in ticks (see also
Section 13.8.1 Object Attributes);

System Services
R E Q U I R E D
• OSTICKSPERBASE – number of ticks that are required to reach
10 OSTICKPERTIMEmilliseconds in the
system counter (see also
Section 13.8.1 Object Attributes);
• OSTICKDURATION – duration of a tick of the system counter in
nanoseconds ( defined automatically by
System Generator utility (SG) (see
Section 12.2 General ), through
OSTICKSPERBASE value);
A G R E E M E N T
• OSMINCYCLE – minimum allowed number of ticks for a
cyclic alarm (only for system with Extended
Status, see also Section 13.8.1 Object
Attributes).
17.6.3 Counter and Alarm Declaration
To refer to a counter or alarm the declaration statements should be used

to declare the element (counter or alarm) before their using:
17.6.3.1 Counter Declaration
Syntax:
DeclareCounter( CtrRefType <CounterName> )
Input:
• <CounterName> – a reference to the counter
Description:
DeclareCounter serves as an external declaration of a counter. The


System Services
R E Q U I R E D
17.6.3.2 Alarm Declaration
Syntax:
DeclareAlarm( AlarmType <AlarmName> )
Input:
• <AlarmName> – a reference to the alarm
Description:
A G R E E M E N T
DeclareAlarm serves as an external declaration of an alarm. The

These declarations are equivalent to the external declaration of

variables.
17.6.4 InitCounter
Syntax:
StatusType InitCounter( CtrRefType <CounterName>,

TickType <Ticks> );
Input:
• <CounterName> – a reference to the counter;

• <Ticks> – a counter initialization value in ticks.
Output:
• None.
Description:
Sets the initial value of the counter with the value <Ticks>. After this call
the counter will advance this initial value by one via the following call of

System Services
R E Q U I R E D
CounterTrigger. If there are running attached alarms, then their state
stays unchanged.
Particularities:

Counters or InitCounter are turned off in the configuration file.
Status:
• Standard:
A G R E E M E N T
• Extended:
– E_OS_ID – the counter identifier is invalid;
– E_OS_VALUE – the counter initialization value
exceeds the maximum admissible
value;
– E_OS_CALLEVEL – a call at interrupt level (not
allowed).
17.6.5 CounterTrigger
Syntax:
StatusType CounterTrigger( CtrRefType <CounterName> );
Input:
Output:
• None.
Description:
Increments the current value of the counter. If the counter reaches the
value maxallowedvalue (see Section 17.6.1 Data Types and
Identifiers), it is reset to “zero”.

System Services
R E Q U I R E D
If alarms are linked to the counter, the system checks whether they
expired after this tick and performs appropriate actions (task activation
and event setting).
Particularities:
Call admissible both from interrupt and task levels.
Depending on the underlying hardware it is possible that parts of the

functionality of CounterTrigger may by done by the hardware. In this
case the remaining functionality of CounterTrigger has to be adapted.
A G R E E M E N T

Counters or CounterTrigger are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ID – the counter identifier is invalid.

17.6.6 AdvanceCounter
Syntax:
StatusType AdvanceCounter( CtrRefType <CounterName>,

TickType <Ticks> );
Input:

• <Ticks > – a number of ticks to be advanced.
Output:
• None.
Description:

System Services
R E Q U I R E D
Advances the current value of the counter.
If alarms are linked to the counter, the system checks whether they
expired during specified number of ticks and performs appropriate
actions (task activation and event setting).
This service is not defined in the OSEK OS v.2.0 rev. 1 specification.

This is an extension of OSEK OS.
Particularities:
Call admissible from task level only.
A G R E E M E N T
Counters or AdvanceCounter are turned off in the configuration file.
Status:
• Standard:
– E_OS_VALUE – specified value is greater than
maxallowedvalue.
• Extended:
– E_OS_ID – the counter identifier is invalid.
– E_OS_CALLEVEL – call at interrupt level is invalid.
17.6.7 GetCounterValue
Syntax:
StatusType GetCounterValue( CtrRefType <CounterName>,

TickRefType <Ticks> );
Input:
Output:
• <Ticks> – a counter value in ticks.

System Services
R E Q U I R E D
A reference to the return counter value in ticks.
Description:
The system service provides the current value of the counter

<CounterName> in ticks.
Particularities:

Counters or GetCounterValue are turned off in the configuration file.
A G R E E M E N T
Status:
• Standard:
• Extended:
– E_OS_CALLEVEL – a call at interrupt level (not allowed).
17.6.8 GetCounterInfo
Syntax:
StatusType GetCounterInfo( CtrRefType <CounterName>,

CtrInfoRefType <Info> );
Input:
Output:
• <Info> – a reference to the structure with constants

of the counter.
Description:
Returns the counter characteristics into the <Info> structure. For a

system counter special constants may be used instead of this service.

System Services
R E Q U I R E D
The return value <Info> is a structure in which the information of data
type CtrInfoType is stored.
Particularities:
The structure consists of two elements in case of the “Standard Status”,

and of three elements in case of the “Extended Status”.

Counters or GetCounterInfo are turned off in the configuration file.
Status:
A G R E E M E N T
• Standard:
• Extended:
– E_OS_CALLEVEL – a call at interrupt level (not
allowed).
17.6.9 SetRelAlarm
Syntax:
StatusType SetRelAlarm( AlarmType <AlarmName>,

TickType <Increment>,
TickType <Cycle> );
Input:
• <AlarmName> – a reference to the alarm;

• <Increment> – a relative value in ticks;
• <Cycle> – an alarm cycle value in ticks in case of
cyclic alarm. In case of single alarms, the
value cycle has to be equal zero.
Output:
• None.

System Services
R E Q U I R E D
Description:
The system service occupies the alarm <AlarmName> element. After

this service call the counter will count <Increment> ticks starting from the
current counter value at the moment of the call. After <Increment> ticks
have elapsed from that moment, the task assigned to the alarm
<AlarmName> is activated or the assigned event (only for Extended
Tasks) is set.
If <Cycle> is unequal 0, the alarm element is logged on again

A G R E E M E N T
immediately after expiry with the relative value <Cycle>. Otherwise, the
alarm triggers only once.
Particularities:
If the relative value <Increment> is very small, the alarm may

immediately expire, and the task may become ready. It is because the
certain time is needed for system activities to return to the calling task
after the <Increment> ticks for the counter have been set.
The alarm <AlarmName> must not already be in use. To change values

of alarms already in use the alarm has to be cancelled first.

Alarms or SetRelAlarm are turned off in the configuration file.
Status:
• Standard:
– E_OS_STATE – the alarm is already in use.
• Extended:
– E_OS_ID – the alarm identifier is invalid;
– E_OS_VALUE – the alarm initialization value or cycle
value is greater than the maximum
allowed value of the counter, or the
cycle value is less than the minimum
cycle value of the counter.
Conformance:

System Services
R E Q U I R E D
• BCC1, BCC2;
• Events: ECC1, ECC2.
17.6.10 SetAbsAlarm
Syntax:
StatusType SetAbsAlarm( AlarmType <AlarmName>,

TickType <Start>,
TickType <Cycle> );
A G R E E M E N T
Input:
• <AlarmName> – a reference to the alarm;

• <Start> –an absolute value in ticks;
• <Cycle> – an alarm cycle value in ticks in case of
cyclic alarm. In case of single alarms, cycle
has to be equal zero.
Output:
None.
Description:
The system service occupies the alarm <AlarmName> element. The
counter will count <Start> ticks starting from zero counter value. When
<Start> ticks are reached, the task assigned to the alarm <AlarmName>
is activated or the assigned event (only for Extended Tasks) is set.
If <Cycle> is unequal 0, the alarm element is logged on again

immediately after expiry with the relative value <Cycle>. Otherwise, the
alarm triggers only once.
Particularities:
Since the current counter value at the moment of the service call is most
likely not equal zero, there exist the some period of time while the
counter reaches its maximum allowed value and will be logged on again
(its value will become 0). Only starting from zero <Start> ticks will be
counted.

System Services
R E Q U I R E D
If the absolute value <Start> is very close to the current counter value,
the alarm may immediately expire, and the task may become ready.
(E.g., the current counter value at the moment of service call equals 253,
the maximum allowed counter value equals 255 and the <Start> value is
2.)
The alarm <AlarmName> must not already be in use.
To change values of alarms already in use the alarm has to be cancelled

first.
A G R E E M E N T

Alarms or SetAbsAlarm are turned off in the configuration file.
Status:
• Standard:
– E_OS_STATE – the alarm is already in use.
• Extended:
– E_OS_ID – the alarm identifier is invalid;
– E_OS_VALUE – the alarm initialization value or cycle
value is greater than the maximum
allowed value of the counter, or the

cycle value is less than the minimum
cycle value of the counter.
Conformance:
• BCC1, BCC2;
• Events: ECC1, ECC2.
17.6.11 CancelAlarm
Syntax:
StatusType CancelAlarm( AlarmType <AlarmName> );
Input:

System Services
R E Q U I R E D
• <AlarmName> – a reference to the Alarm.
Output:
None.
Description:
The service cancels the alarm (transfers it into the stop state).
Particularities:
A G R E E M E N T
Alarms or CancelAlarm are turned off in the configuration file.
Status:
• Standard:
– E_OS_NOFUNC – the alarm is not in use.
• Extended:
– E_OS_ID – the alarm identifier is invalid.
17.6.12 GetAlarmBase
Syntax:
StatusType GetAlarmBase( AlarmType <AlarmName>,

AlarmBaseRefType <Info> );
Input:
• <AlarmName> – a reference to the Alarm;
Output:
• <Info> – a reference to the structure with constants

of the alarm base.
Description:

System Services
R E Q U I R E D
Returns the alarm base characteristics into the <Info> structure. The
return value <Info> is a structure in which the information of data type
AlarmBaseType is stored.
Particularities:
The structure consists of two elements in case of the “Standard Status”,

and of three elements in case of the “Extended Status”.

Alarms or GetAlarmBase are turned off in the configuration file.
A G R E E M E N T
Status:
• Standard:
• Extended:
17.6.13 GetAlarm
Syntax:
StatusType GetAlarm( AlarmType <AlarmName>,

TickRefType <Ticks> );
Input:
• <AlarmName> – a reference to the Alarm;
Output
• <Ticks> – a reference to a variable ( or memory field

) which gets a relative value in ticks before
the alarm expires.
Description:
This service calculates the time in ticks before the alarm expires. If the
alarm is not started the E_OS_NOFUNC error code is generated.

System Services
R E Q U I R E D
Particularities:
It is up to the application to decide whether for example an alarm may

still be useful or not.
If <AlarmName> is not in use <Ticks> is 0.

Alarms or GetAlarm are turned off in the configuration file.
Status:
A G R E E M E N T
• Standard:
– E_OS_NOFUNC – the alarm is not in use.
• Extended:
17.6.14 Examples for Counter and Alarm Management
The example shows how counters and alarms can be used.
The following definitions are made in the definition file (for HC08):
...
TASK TaskTime {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = FALSE;
PRIORITY = 3;
StackPool = POOL1;
};
TASK TASK_B {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 2;
STACKSIZE = 64;
};
TASK TASK_X {
TYPE = BASIC;

System Services
R E Q U I R E D
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 1;
};
COUNTER TimeCnt {
TICKSPERBASE = 1;
};
COUNTER DgrCnt {
TICKSPERBASE = 1;
};
A G R E E M E N T
ALARM TimeAlm {
ACTION = ACTIVATETASK;
COUNTER = TimeCnt;
TASK = TASK_X;
};
ALARM DgrAlm {
ACTION = SETEVENT;
COUNTER = DgrCnt;
TASK = TASK_B;
EVENT = DgrAlmEvent;
};
EVENT DgrAlmEvent {
MASK = 0x01;
};
MESSAGE Norm {
ITEMTYPE = "int";
ITEMS = 6;
ReceiverNum = 3;
};
...
The alarm TimeAlm activates the task TASK_X when the counter
TimeCnt expires. The alarm DgrAlm sets the specified event for the
task TASK_B when the counter DgrCnt expires.
DeclareTask( TASK_B )
DeclareTask( TaskTime )
DeclareTask( TASK_X )
DeclareCounter( TimeCnt )
DeclareCounter( DgrCnt )
DeclareAlarm( TimeAlm )
DeclareAlarm( DgrAlm )
OSMSGNorm _Norm;

System Services
R E Q U I R E D
TASK( TaskTime )
{
TickType curTime;
TickType ticksToExpire;
OSBYTE i=0;
InitCounter( TimeCnt, 0 ); /* init time counter with 0 value */

AdvanceCounter( TimeCnt, 2 ); /* increments counter value by 2 */
while (i != 1) {
GetCounterValue( TimeCnt, &curTime ); /* read TimeCnt value */
if( curTime == CONST )
A G R E E M E N T
{ /* if desired value, activate TaskB */
ActivateTask( TASK_B );
SetRelAlarm( TimeAlm, 10, 0 );
/* activate TaskX when TimeCnt reaches 10 */
GetAlarm( TimeAlm, &ticksToExpire );
/* just for example: TimeAlm will
expire after ‘ticksToExpire’ ticks of TimeCnt */
}
if( curTime > CONST )TerminateTask();
/* if more than desired value, terminate the task */
}
}
TASK( Task_B )
{
OSMSGNorm _Norm;
EventMaskType evMask;
evMask = 0x01;
InitCounter( DgrCnt, 0 ); /* init degree counter with 0 value */
SetAbsAlarm( DgrAlm, 75, 15 ); /* set cyclic alarm */
WaitEvent( evMask );
/* wait for event which must be set by the alarm */
_Norm = 1; /* wake up and send the message that all is OK */
SendMesssage( Norm, _Norm);
TerminateTask();
}
ISR( Timer_Isr )
{
... /* reset the hardware */
EnterISR();
CounterTrigger( TimeCnt ); /* increment the counter */
LeaveISR();
}
ISR( Dgr_Isr )
{

System Services
R E Q U I R E D
... /* reset the hardware */

EnterISR();
CounterTrigger( DgrCnt ); /* increment the counter */
LeaveISR();
}
17.7 Event Management Services
17.7.1 Data Types

A G R E E M E N T
The OSEK Operating System establishes the following data types for the
event management:
• EventMaskType The data type of the event mask;

• EventMaskRefType The data type to refer to an event mask.
The only data types must be used for operations with events.
17.7.2 Event Declaration
To refer to a event the constructional element should be used to declare

the event before its using:
Syntax:
DeclareEvent( EventMaskType <Event> )
Input:
• <Event> – event name.
Description:
DeclareEvent serves as an external declaration of an event. The

Conformance: ECC1, ECC2

System Services
Event Management Services
R E Q U I R E D
17.7.3 SetEvent
Syntax:
StatusType SetEvent( TaskType <TaskName>,

EventMaskType <Mask> );
Input:
• <TaskName> – a reference to the task (the task’s name).

• <Mask> – an event mask to be set.
A G R E E M E N T
Output:
• None
Description:
This service is used to set one or several events of the desired task
according to the event mask. If the task was waiting for at least one of
the specified events, then it is transferred into the ready state. The
events not specified by the mask remain unchanged. Only an extended
task may be referenced to set an event.
Particularities:
Any events not set in the event mask remain unchanged.
It is possible to set events for the running task (task-caller).

Events or SetEvent are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ACCESS – the referenced task is not an
Extended Task;
– E_OS_STATE – the referenced task is in the
suspended state;

System Services
R E Q U I R E D
17.7.4 ClearEvent
Syntax:
StatusType ClearEvent( EventMaskType <Mask> );
Input:
• <Mask> – an event mask to be cleared.

A G R E E M E N T
Output:
• None.
Description:
The task which calls this service defines the event which has to be
cleared.
Particularities:
The system service ClearEvent is restricted to Extended Tasks.

Events or ClearEvent are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ACCESS – the calling task is not an Extended
Task;
allowed.

System Services
R E Q U I R E D
17.7.5 GetEvent
Syntax:
StatusType GetEvent( TaskType <TaskName>,

EventMaskRefType <Event> );
Input:
Output:
A G R E E M E N T
• <Event> – a pointer to the event mask to be filled.
Description:
The event mask which is referenced to in the call is filled according to the
current state of the events of the desired task.
It is possible to get event mask of the running task (task-caller).
Particularities:
The referenced task must be an extended task.

Events or GetEvent are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ACCESS – the referenced task is not an
Extended Task;
– E_OS_STATE – the referenced task is in the
suspended state;

System Services
R E Q U I R E D
17.7.6 WaitEvent
Syntax:
StatusType WaitEvent( EventMaskType <Mask> );
Input:
• <Mask> – an event mask to wait for.
Output:
A G R E E M E N T
• None.
Description:
The calling task is transferred into the waiting state until at least one of
the events specified by the mask is set.
Particularities:
This call enforces the rescheduling, if the wait condition occurs.

Events or WaitEvent are turned off in the configuration file.
Status:
• Standard:
• Extended:
– E_OS_ACCESS – the calling task is not an Extended
Task;
– E_OS_RESOURCE – the calling task occupies resources;
allowed.

System Services
R E Q U I R E D
17.7.7 Examples of Using Events
The example below shows how events can be used in the OSEK
Operating System.
...
TASK TASK_A {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 3;
A G R E E M E N T
STACKSIZE = 64;
};
TASK TASK_B {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = FALSE;
PRIORITY = 3;
StackPool = POOL1;
};
TASK TASK_C {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 1;
};
COUNTER DgrCnt {
TICKSPERBASE = 1;
};
ALARM AWAKE {
ACTION = SETEVENT;
COUNTER = DgrCnt;
TASK = TASK_B;
EVENT = DgrAlmEvent;
};
EVENT DgrAlmEvent {
MASK = 0x01;
};
MESSAGE Norm {
ITEMTYPE = "int";
ITEMS = 6;
ReceiverNum = 3;

System Services
R E Q U I R E D
};
...
The C-language file:
#define X_FLG 0x80 /* define masks for internal flags */

#define Y_FLG 0x40 /* #define may be used for event masks */
#define Z1_FLG 0x20 /* in other case evnt masks should be */
#define Z2_FLG 0x10 /* generated by SG tool and established */
/* via DeclareEvent() */
DeclareTask( TASK_A ) /* the extended tasks */

A G R E E M E N T
DeclareTask( TASK_C ) /* the basic task */
TASK( TASK_A ) /* Extended task TASK_A */

{
EventMaskType aa = 3; /* ‘external’ events */
EventMaskType x, z1 = Z1_FLG, /* ‘internal’ events (flags) */
z2 = Z2_FLG;
int speed;
...
/* Check the variable and set internal flag if needed */
if (speed == LIMIT)
{
x = X_FLG;
SetEvent( TASK_A, x );
}
...
GetEventMask( TASK_A, &x ); /* check internal flag */

/* Perform some actions in accordance with internal flag status */
if ((x & X_FLG) != 0 ) ClearEvent( z1 );
else SetEvent( TASK_A, z2 );
if ((x & Y_FLG) == 0 ) ChainTask( TASK_C );
...
WaitEvent( aa ); /* the task is stopped until one of three

‘external’ events is set by another task */
ClearEvent( aa ); /* clear all ‘external’ events after

awakening */
...
}
#define EVMASK1 0x01 /* event mask definitions */

#define EVMASK2 0x02
#define EVMASK3 0x04

System Services
Communication Management Services
R E Q U I R E D
TASK( TASK_B ) /* Extended task TASK_B */
{
EventMaskType b_ev, a_ev;
b_ev = EVMASK1 | EVMASK3;
InitCounter( DgrCnt, 10 ); /* initialize the counter */
...
SetRelAlarm( AWAKE, 20, 0 ); /* this alarm will awake the task */
WaitEvent( b_ev ); /* waiting for one of two events */
/* The task will be ready again when one of two events are set. One of
them - EVMASK1 will be set by the alarm AWAKE after 20 ticks of the counter
DgrCnt. Thus, the task can delay itself. */
A G R E E M E N T
ClearEvent( b_ev ); /* clear all events */
GetEvent( TASK_A, &a_ev ); /* get events of TASK_A */
if ( (a_ev & EVMASK2) == 0)
{
a_ev = EVMASK2;
SetEvent( TASK_A, a_ev );
} /* set the event for TASK_A */
...
}
TASK( TASK_C ) /* Basic task TASK_C */

{
EventMaskType bb, set;
set = EVMASK3;
...
GetEventMask( TASK_B, &bb ); /* if the event is clear, set it */
if ((bb & EVMASK3) == 0 ) SetEvent( TASK_B, set );
...
}
17.8 Communication Management Services
17.8.1 Data Types and Identifiers
The following names are used in the OSEK Operating System for work
with messages:
• SymbolicName This is an unique name representing a

message. It only can be used in
conjunction with calls of the message

System Services
R E Q U I R E D
service. A SymbolicName need not be a

data type. Variables or constants of
SymbolicName can be declared or used.
• AccessName This is a unique name defining access to
a message object. Depending on the
chosen configuration, a distinction is
made between the following AccessName
scheme:
WithCopy configuration:
A G R E E M E N T
A application variable exists as a local

copy of the message. The name of the
variable is the AccessName. This variable
contains a copy of the corresponding
message object.
WithoutCopy configuration:
The message object data is accessed via
the AccessName. This AccessName is a
static link: it refers directly to the message
object data. The AccessName refers to
the same data (RAM) as the message
object.
17.8.2 SendMessage
Syntax:
StatusType SendMessage ( SymbolicName <Message>, AccessName <Data> )
Input:
• <Message> – symbolic name of the message object,

• <Data> – AccessName of the message data to be
sent.
Output:
• None.

System Services
R E Q U I R E D
Description:
In case of WithCopy:
This service updates the message object <Message> with the Data
given by <Data> and requests the transmission of the message object to
the receiving entities. The message object is locked during this update
and during the transmission of the data to the underlying communication
layer. The message object is not updated if it is already locked. This
service updates also the status information of the message object
accordingly.
A G R E E M E N T
In case of WithoutCopy:
– Possible for unqueued message type only –
This service requests the transmission of the already updated message
object to the receiving entities via the bus.
Particularities:
SendMessage does not verify whether the message object has been
initialized prior to sending it.
Status:
• Standard:
WithCopy
– E_OK – message object updated,
– E_COM_LOCKED – message object locked.
WithoutCopy
– E_OK – successful operation,
• Extended:
– E_COM_ID – invalid parameter <Message>.
Conformance: N/A

System Services
R E Q U I R E D
17.8.3 ReceiveMessage
Syntax:
StatusType ReceiveMessage ( SymbolicName <Message>,AccessName <Data>)
Input:
• <Message> – symbolic name of the message object.
Output:
A G R E E M E N T
• <Data> – AccessName of the message data to be

received
Description:
In case of WithCopy:
This service delivers the message data associated with the message
object <Message> to the applications message copy referenced by
<Data>. The message object is locked during data reception. This
service also updates the status information of the message object
accordingly.
In case of WithoutCopy:
– Possible for unqueued message type only –
Returns Status only since application can access directly to the

message object.
Particularities:
Queued messages:
1. The service returns the oldest message.

2. In case of a FIFO overflow, at leas t one message was lost, the
oldest message is returned.
3.If the FIFO is empty, no message is returned to the application.
Unqueued messages:
1. The service returns the current message.

2. If no new message has been received since the last call to
ReceiveMessage the current message is returned.

System Services
R E Q U I R E D
Status:
• Standard:
WithCopy:
– E_OK – message available,
– E_COM_LOCKED – message object locked,
– E_COM_NOMSG – in case of unqueued message, no
message received so far,
– E_COM_NOMSG – in case of queued message, no
message available (FIFO empty),
A G R E E M E N T
– E_COM_LIMIT – at least one message has been lost
for a message object.
WithoutCopy:
– E_OK – successful operation,
• Extended:
– E_COM_ID– invalid parameter <Message>.
Conformance: N/A
17.8.4 GetMessageResource
Syntax:
StatusType GetMessageResource ( SymbolicName <Message> )
Input:
Output:
• None.
Description:
The service GetMessageResource sets the given message object

<Message> status (extended: for other tasks) as busy if it is not already
so. This call serves to enter critical sections in the code that are assigned

System Services
R E Q U I R E D
to read or write the message object referenced by <Message>. A critical

section (critical sections should be short) must always be left using
ReleaseMessageResource.
Particularities:
This service provides message availability information for the application

to ensure message consistency between API communication service
calls in the without copy configuration.
Corresponding calls to Get- and ReleaseMessageResource should

A G R E E M E N T
appear within the same function on the same function level. Before
terminating the task or entering the wait or suspend state the
corresponding service ReleaseMessageResource has to be used.
Status:
• Standard:
– E_OK – message object is set busy ,
– E_COM_BUSY – message object is already busy.
• Extended:
Conformance: N/A
17.8.5 ReleaseMessageResource
Syntax:
StatusType ReleaseMessageResource ( SymbolicName <Message> )
Input:
Output:
• None.

System Services
R E Q U I R E D
Description:
The service ReleaseMessageResource sets off the message object

<Message> from busy. ReleaseMessageResource is the counterpart of
GetMessageResource and serves to leave critical sections in the code
that are assigned to read or write the message object referenced by
<Message>.
Particularities:
This service allows for message consistency to be ensured by the
A G R E E M E N T
application in case without copy configuration.
Corresponding calls to Get- and ReleaseMessageResource should

appear within the same function on the same function level. Before
terminating the task or entering the wait or suspend state the
corresponding service ReleaseMessageResource has to be used
Status:
• Standard:
– E_OK – message object unlocked
successfully.
• Extended:
Conformance: N/A
17.8.6 GetMessageStatus
Syntax:
StatusType GetMessageStatus ( SymbolicName <Message> )
Input:
• <Message> – symbolic name of the message object
Output:
• None.

System Services
R E Q U I R E D
Description:
The service GetMessageStatus returns the current status of the

message object <Message>. If this service call fails, it has to return an
implementation specific error code which can be distinguished from all
other return values.
Particularities:
None.
A G R E E M E N T
Status:
• Standard:
– E_OK – no error,
– E_COM_BUSY – message object is currently in use
by the application,
– E_COM_LOCKED – message object locked irrespective
of whether the message object is
currently in use by the application
(busy),
– E_COM_NOMSG – in case of unqueued message, no
message received so far,
– E_COM_NOMSG – in case of queued message, no
message available,
– E_COM_LIMIT – at least one message has been lost,
– implementation specific status information or error codes.
• Extended:
Conformance: N/A
17.8.7 Examples of Using Messages
The examples below present the usage of system services for

communication. The Unqueued Message MsgBAst has a timestamp
and it is defined as a message of the MSGTS type.

System Services
R E Q U I R E D
...
TASK TASK_A {
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = FALSE;
PRIORITY = 3;
StackPool = POOL1;
};
TASK TASK_B {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
A G R E E M E N T
PRIORITY = 2;
EntryPoint = "task_b";
STACKSIZE = 64;
};
TASK TASK_X {
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
PRIORITY = 1;
};
COUNTER Post {
TICKSPERBASE = 1;
};
MESSAGE msgAAst {
ITEMTYPE = "int";
ITEMS = 1;
WithCopy = FALSE;
};
MESSAGE msgBAst {
ITEMTYPE = "MSGTS";
ITEMS = 1;
WithCopy = TRUE;
};
MESSAGE msgCBst {
ITEMTYPE = "int";
ITEMS = 1;
WithCopy = TRUE;
};
MESSAGE msgDBev {
ITEMTYPE = "int";

System Services
R E Q U I R E D
ITEMS = 6;
ReceiverNum = 3;
};
...
DeclareTask( TASK_A )
DeclareTask( TASK_X )
OSMSGmsgAAst *_msgAAst = &OSmsgAAst;

OSMSGmsgBAst _msgAAst;
A G R E E M E N T
OSMSGmsgCBst _msgCBst;
OSMSGmsgDBev _msgDBev;
DeclareCounter( Post )
typedef struct tagMSGTS MSGTS;

struct tagMSGTS
{
TickType ts;
int x;
};
void Func( void );

{ /* The function uses the Queued Message - receives and processes it */
ReceiveMessage( msgDBev );
...
}
TASK( TASK_A )
{
...
ReceiveMessage( msgCBst, _msgCBst ); /* get the message */
if( msgCBst == 2 ) *_msgAAst = 1;
else *_msgAAst = 33;
SendMessage( msgAAst, _msgAAst );
...
_msgBAst.x = 60;
GetCounterValue( Post, &(_msgBAst.ts) );
SendMessage( msgBAst, _msgBAst );
...
Func();
...
}
TASK( TASK_B )

System Services
Operating System Execution Control
R E Q U I R E D
{
TickType cur_time;
...
_msgCBst = 15;
SendMessage( msgCBst, _msgCBst );
...
ReceiveMessage( msgAAst, _msgAAst );
if( *_msgAAst == 1 ) ActivateTask( TASK_X );
ReceiveMessage( msgBAst, _msgBAst );

_msgBAst.ts = 60;
GetCounterValue( Post, &cur_time );
if( (cur_time - _msgBAst.ts) > 15 ) SetEvent( TASK_X, 1 );
A G R E E M E N T
...
SendMessage( msgEBev, _msgEBev );

...
}
17.9 Operating System Execution Control
17.9.1 Data Types
The OSEK OS establishes the following data type for operation mode
representation:
• AppModeType This data type represents the operating
mode.
17.9.2 GetActiveApplicationMode
Syntax:
AppModeType GetActiveApplicationMode( void );
Description:
This service returns the current application mode. It may be used to write
mode dependent code (see Section 11.6 Application Modes).

GetActiveApplicationMode is turned off in the configuration file.

System Services
R E Q U I R E D
Particularities:
17.9.3 StartOS
Syntax:
void StartOS( AppModeType <Mode> );
Input:
A G R E E M E N T
• <Mode> – operating mode.
Output:
• None.
Description:
The user can call this system service to start the system in a specific
mode. This service calls user hook StartupHook. Each application mode
consists of own set of tasks (see Section 11.6 Application Modes).
Particularities:
See Section 11.5 Start-up Routine and Section 11.6 Application

Modes for general description of system startup.
17.9.4 ShutdownOS
Syntax:
void ShutdownOS( StatusType <Error> );
Input:
• <Error> – a code of the error occurred.
Output:
• None.

System Services
R E Q U I R E D
Description:
The user can call this system service to abort the overall system (e.g.
emergency off). The operating system also calls this function internally,
if it has reached an undefined state and is no longer ready to run. This
service calls user hook ShutdownHook. If ShutdownHook returns, the
operating system jumps to the next statement following the initial call to
StartOS (see Section 11.7 System Shutdown).
Particularities:
A G R E E M E N T
ShutdownOS never returns to the location where it was called.
ShutdownOS is application specific, since standardized error treatment

is not possible.
ShutdownOS runs in connection with the currently active context, which

may be unknown to the user. Thus, no API functions are admitted within
the ShutdownOS routine.
After the return from ShutdownOS service all interrupts will be disabled.

ShutdownOS is turned off in the configuration file.
17.9.5 Examples of Application Modes Usage
The example bellow demonstrates different application modes usage.
OIL_VERSION = "2.0e"; /* Force SG to use Extended */

/* OIL format */
INCLUDE “mot20.oil”
CPU cpu1 {
CFGACTIVE = { ModeA, ModeB }; /* Two application modes */
/* “ModeA”, “ModeB” are */
/* defined */
....
CFG ModeA { /* Application mode “ModeA” */
TASK TC { /* Common task for both modes */
TYPE = EXTENDED;

System Services
R E Q U I R E D
SCHEDULE = FULL;
AUTOSTART = TRUE;
STACKSIZE = 60;
PRIORITY = 3;
};
TASK TA1 { /* ModeA specific task TA1 */
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
StackPool = POOL;
PRIORITY = 2;
A G R E E M E N T
};
... /* Other ModeA tasks */
};
CFG ModeB { /* Application mode “ModeB” */
TASK TB1 { /* ModeB specific task TB1 */
TYPE = BASIC;
SCHEDULE = FULL;
AUTOSTART = TRUE;
StackPool = POOL;
PRIORITY = 4;
};
TASK TC { /* Common task for both modes */
TYPE = EXTENDED;
SCHEDULE = FULL;
AUTOSTART = TRUE;
STACKSIZE = 60;
PRIORITY = 5;
};
... /* Other ModeB tasks */
};
STACK POOL { /* Stack pool definition */
StackSize = 60;
NumberOfStacks = 3;
}
COUNTER Timer { ... };/* Counter definition */
ALARM TimeLimit { /* Alarm definition */
ACTION = SETEVENT;
COUNTER = Timer;
TASK = TC; /* Activates common task */
EVENT = SHUTDOWN;
}
EVENT SHUTDOWN { MASK = 0x01; };
EVENT STARTTA1 { MASK = 0x02; };
EVENT STARTTB1 { MASK = 0x04; };
....
};

System Services
R E Q U I R E D
DeclareTask( TA1 ) /* ModeA specific task TA1 */

DeclareTask( TB1 ) /* ModeB specific task TB1 */
DeclareTask( TC ) /* Task TC is shared between both modes */
DeclareCounter( Timer ) /* System timer */
DeclareAlarm( TimeLimit ) /* Alarm to abort the system */
DeclareEvent( SHUTDOWN ) /* TC command: shutdown the system */
DeclareEvent( STARTTA1 ) /* TC command: activate TA1 */
DeclareEvent( STARTTB1 ) /* TC command: activate TB1 */
...
AppModeType NewMode; /* Application mode */
void main( void )
A G R E E M E N T
{
NewMode = ModeA; /* Set initial application mode */
for( ; ; )
{
... /* Perform some actions before startup*/
/* and start OS in specific mode */
StartOS( NewMode );
... /* Perform some actions after system*/
/* shutdown */
}
}
TASK( TC ) /* TC code is shared between both modes */

{
EventMaskType tc_ev;
/* Set maximum possible time limit */
SetRelAlarm( TimeLimit, 1000, 0 );
for( ; ; )
{
ClearEvent( SHUTDOWN|STARTTA1|STARTTB1 );
WaitEvent( SHUTDOWN|STARTTA1|STARTTB1 );
GetEvent( TC, &tc_ev );
if( ( tc_ev & SHUTDOWN ) != 0 )
{ /* Force system shutdown */
ShutdownOS( E_OK );
}
if( ( tc_ev & STARTTA1 ) != 0 )
{ /* Activate ModeA specific task */
ActivateTask( TA1 );
}
if( ( tc_ev & STARTTB1 ) != 0 )
{ /* Activate ModeB specific task */
ActivateTask( TB1 );
}
}
}
/* USer’s shutdown hook */
void ShutdownHook( StatusType Error )

System Services
R E Q U I R E D
{
/* Check current application mode */
if( GetActiveApplicationMode( ) = ModeA )
NewMode = ModeB; /* Next time the system will start */
/* in application mode ModeB */
else
NewMode = ModeA; /* Next time the system will start */
/* in application mode ModeA */
}
TASK( TA1 ) /* ModeA specific task */

{
... /* Activate other ModeA specific tasks */
A G R E E M E N T
TerminateTask( ); /* And terminate self */

}
TASK( TB1 ) /* ModeB specific task */

{
... /* Activate other ModeB specific tasks */
TerminateTask( ); /* And terminate self */
}
17.9.6 Hook Routines
17.9.6.1 ErrorHook
Syntax:
void ErrorHook( StatusType <Error> );
Input:
Output:
• None.
Description:
This hook is called by the operating system at the end of a system

service which has a return value not equal to E_OK. It is called before
returning to the call level.
For error parameters to be transferred see

Section 17.9.4 ShutdownOS.

System Services
R E Q U I R E D
Particularities:
See Section 11.3 Hook Routines for general description of hook

routines.
This hook is not implemented if the system configuration option

ErrorHook is turned off in the configuration file.
Status:
• None.
A G R E E M E N T
17.9.6.2 PreTaskHook
Syntax:
void PreTaskHook( void );
Input:
• None.
Output:
• None.
Description:
This hook is called before the operating system enters the context of the
task. This hook is called from the scheduler when it passes control to the
given task. It may be used by the application to trace the sequences and
timing of tasks’ execution.
Particularities:

routines.

PreTaskHook is turned off in the configuration file.
Status:

System Services
R E Q U I R E D
None.
17.9.6.3 PostTaskHook
Syntax:
void PostTaskHook( void );
Input:
A G R E E M E N T
• None.
Output:
• None.
Description:
This hook is called after the operating system leaves the context of the
task. This hook is called from the scheduler when it switches from the
current task to another. It may be used by the application to trace the
sequences and timing of tasks’ execution.
Particularities:

routines.

PostTaskHook is turned off in the configuration file.
Status:
None.
17.9.6.4 IdleLoopHook
Syntax:
void IdleLoopHook( void );

System Services
R E Q U I R E D
Input:
• None.
Output:
• None.
Description:
This hook is called by the operating system from scheduler idle loop. It
is not possible to call OSEK OS directives from this hook. Hardware
A G R E E M E N T
dependent code like manipulation with COP registers may be placed
here.
Particularities:

routines.

IdleLoopHook is turned off in the configuration file.
17.9.6.5 StartupHook
Syntax:
void StartupHook( void );
Input:
• None.
Output:
• None.
Description:
This hook is called by the operating system at the end of the operating
system initialization and before the scheduler is running. At this point in
time the application can start tasks, alarms, initialize device drivers etc.

System Services
R E Q U I R E D
Particularities:

routines.

StartupHook is turned off in the configuration file.
Status:
None.
A G R E E M E N T
17.9.6.6 ShutdownHook
Syntax:
void ShutdownHook( StatusType <Error> );
Input:
Output:
• None.
Description:
This hook is called by the operating system when the service

ShutdownOS has been called. This routine is called before the operating
system shuts down itself.
Particularities:

routines. This hook is not implemented if the system configuration option
ShutdownHook is turned off in the configuration file.
Status:
None.

R E Q U I R E D
Section 18. ORTI Implementation
18.1 Contents
18.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269
A G R E E M E N T
18.3 ORTI Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .271
18.5 ORTI Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .275
18.2 General
The purpose of OSEK Run Time Interface (ORTI) implementation is
giving the user extended opportunities in debugging embedded OSEK
applications. The ORTI shall be supported from both sides: an OSEK OS
and a debugger. The debugger able to display information in terms of
OSEK system objects is “OSEK aware” debugger. The internal OS data
is to be made available to the debugger. For this purpose special ORTI
file is generated at configuration time by an ORTI generator. As a result,
more services will be available to the user during application debugging
session.
The ORTI generator (OrtiGen) is the command line utility which uses OIL
file (App.oil) as input file. The OrtiGen utility generates static information
in the ORTI format. This utility analyzes the application configuration and
generates ORTI file. The same OIL file is processed by the SysGen and
all files with configuration data for OS are generated. After application is
compiled and linked and executable and map files are created then they
are loaded by the debugger. If the debugger is OSEK aware then it can
load also the ORTI file for this application. The information from ORTI file
provide the debugger with possibility to display information about system
objects of current implementation of OSEK OS. This process is depicted
on Figure 18-1.
MOTOROLA ORTI Implementation 269

ORTI Implementation
R E Q U I R E D
User’s Source File OIL File

app.c
OS
SysGen OrtiGen
A G R E E M E N T
Application
Configuration
Files
Compiler/Linker
Executable File MAP File ORTI File

OSEK Aware
Debugger
OSEK Operating System

components:
Data files
Programs
Third-party tools
Library
Figure 18-1. Application Building Process with ORTI Support
270 ORTI Implementation MOTOROLA

ORTI Implementation
ORTI Features
R E Q U I R E D
18.3 ORTI Features
ORTI provides two kinds of interfaces to OSEK OS data:
• Trace interface, which means getting an access to the data on a

running target when it is essential to trace data changes in a real
time;
• Breakpoint interface, which provides an access to desirable data
on a stopped target.
Note that ORTI Trace interface is designed to provide access to
A G R E E M E N T
requested data in accomplished form that is not requiring additional
processing.
18.3.1 ORTI Trace Interfaces
There are two trace ORTI interfaces: running task identification in run-
time and OSEK OS system calls identification in run-time.
The special attributes are generated for the OS object in ORTI file to
support trace interfaces. There are RUNNINGTASK and
CURRENTSERVICE attributes1.
• RUNNINGTASK
This attribute specifies the name of the currently running task
within the OS.
The RUNNINGTASK attribute value presents the address of a
byte which contains either byte numeric identifier of a task which
is currently in the running state or the special byte value in case of
none tasks are in the running state. The certain values of task
identifiers are statically determined and enumerated in the type
field of RUNNINGTASK attribute of an OS object as well as the
special value (NO_TASK) representing none of tasks running.
1. These attributes are specified in the document “ORTI: OSEK Run Time Interface, Version 2.0
(Draft a), 18 February 1999”.

ORTI Implementation
R E Q U I R E D
The value of the RUNNINGTASK attribute is updated each time

CPU switches to another task or to the code corresponding to
none of task running.
• CURRENTSERVICE
This attribute specifies which operating service, if any is currently
being executed.
The CURRENTSERVICE attribute value presents the address of
a byte which represents a service numeric identifier. This value is
updated with OSEK OS service (Service) identifier on the
A G R E E M E N T
following events occurred:

– CPU enters Service code;
– CPU resumes execution of Service code after switching to the
task preempted (this also could take place in case of unacted
task preemption, when system scheduler tried to switch to
another task but found no appropriate task to switch to and
resumed Service code execution in a frame of the current
task);
– CPU resumes execution of Service code after leaving nested
OSEK OS service call (mainly for hook services).
In case of leaving OSEK OS service the byte accepts the special
value (NO_SERVICE) corresponding to none of OSEK OS service
being currently executed. The byte is updated with this value on

the following events occurred:
– CPU leaves OSEK OS service code and starts to execute non
OSEK OS service code;
– CPU preempts execution of OSEK OS service code to perform
task switching.
NOTE: Typically trace sequence of CURRENTSERVICE looks like the

following:
Traced Value Description

...
SERVICE_1_ID entering or resuming Service 1

NO_SERVICE leaving Service 1 (possibly due to task switching)

ORTI Implementation
ORTI Features
R E Q U I R E D
Traced Value Description
...

resuming Service 2 execution after unacted task
SERVICE_2_ID
preemption (could be ignored)
...
A G R E E M E N T
SERVICE_4_ID entering nested Service 4 call (possibly hook
routine)
SERVICE_3_ID leaving Service 4 and resuming Service 3
...
SERVICE_6_ID entering nested Service 6 call (possibly hook

routine)
NO_SERVICE leaving Service 5 and Service 6 (possibly due to

task switching)
...
18.3.2 ORTI Breakpoint Interface
There is one Breakpoint ORTI interface intended to facilitate debugger

access to task related data.
The following static (at breakpoints) ORTI services are supported:
• access to tasks information for a debugger on breakpoints;

• access to stacks information for a debugger on breakpoints.
Information needed to display the current task status is available for the
debugger whenever the debugger is stopped (i.e. this information is not
required in real-time and hence can be read from the TCB or similar
structure).

ORTI Implementation
R E Q U I R E D
The following task information is available to the user:
• priority,
• current stack.
Information in the ORTI file allows a debugger to display task information

using values that the user sets in the OIL file.
The task priority value is provided with taking into account possible task
priority changes due to a dynamic resource allocation.
A G R E E M E N T
The task state indicates a standard OSEK state the task is currently in.
Information needed to display stacks allocated in the system is available

for the debugger whenever the debugger is stopped. All memory areas
defined as stack in the application are presented via:
• size,
• start address.
NOTE: To provide system with information about application main stack area
make sure 2 variables are defined in Cosmic link command file: __stack
(required for Cosmic start-up code) and __stackstart (should be
allocated at the lowest address byte of application main stack area). In
this case Cosmic link command file may look like the following:
...
+seg .bss -a data # BSS starts after .data
+def __stackstart=@.bss # pointer to stack start value
+spc .bss=0x3F # reserve 0x3f bytes for stack in BSS
+def __stack=@.bss # stack pointer value
...
18.4 ORTI Supporting OS Properties

To control ORTI support some additional attributes should be defined in
the configuration file (OIL file). The following attributes are specified for
an object of the OS type:

ORTI Implementation
ORTI Generator
R E Q U I R E D
• DEBUG_LEVEL (ENUM)
Specifies the ORTI support in OS. The attribute can have values
0 or 1. If the system has the DEBUG_LEVEL = 0 the static ORTI
support is switched off. If the system has the DEBUG_LEVEL = 1
this mode is considered to be a debugging mode.
• ORTIRunningTask (BOOLEAN)
Specifies that the running task identification in run-time support
will be used. This attribute will be ignored if DEBUG_LEVEL = 0.
• ORTICurrentService (BOOLEAN)
A G R E E M E N T
Specifies that the OSEK OS system calls identification in run-time
support will be used. This attribute will be ignored if
DEBUG_LEVEL = 0.
All attributes of the OS object are described in Section 13.3 OS

Definition.
18.5 ORTI Generator

The ORTI generator utility is a command line utility which has the OIL file
as input and ORTI file as result of work. The ORTI generation utility is
intended to prepare all data needed for OSEK aware debugger to
display information about application in OSEK terms.
The OrtiGen utility has the following format of command line:
ortigen [-options] filename
All options are case sensitive. The space between option and argument
is optional.

ORTI Implementation
R E Q U I R E D
The following options are accepted by the OrtiGen:

Table 18-1. ORTI Generator Command Line Options
Option Description
The argument of this option defines file name for output ORTI file. By
-c
default the input file name with extension .ort is used
This option adds a directory to the list of directories searched for include
files. To search more than one directory, give additional -i options on the
-i
command line – one -i option for each directory. Directories are searched
only until the specified include file is found
The argument of this option defines CPU name for which the ORTI file will
A G R E E M E N T
-n
be written. By default the first CPU in the file is used
The argument of this option defines the name of template file for the ORTI
-t
file generation
The location of the ORTI template file can be pointed either in command
line or via the ORTI_TEMPLATE environment variable.
In addition to command line option the OSB_INCLUDE_DIR

environment variable can be used to specify the set of directories.
If the ORTI generator finds an error in the source files, it either halts
processing or outputs a warning message depending on the error
severity. If there are no error, the OrtiGen returns 0, if there are mild
errors the OrtiGen sends warning messages and returns 0, but does not
terminate processing, if severe errors are detected – the OrtiGen returns
2 and does not produce output file.
The ORTI generator performs the same verification as the SysGen does
and has the same format of error messages. All System Generator error
and warning messages and their formats are described in
Appendix D System Generation Error Messages.
If the DEBUG_LEVEL attribute of the OS object is set to 0 or undefined

in the OIL file then the ORTI file is not produced and the following
warning is generated:
W0010: DEBUG_LEVEL is undefined, ORTI file is not generated
If the DEBUG_LEVEL attribute is undefined in the implementation

definition then the following warning is generated:

ORTI Implementation
ORTI Generator
R E Q U I R E D
W0011: DEBUG_LEVEL is not defined in implementation
A G R E E M E N T

ORTI Implementation
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Appendix A. Sample Application
A.1 Contents
A.2 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279
A G R E E M E N T
A.3 Source Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .280
A.2 Description
The Sample application delivered with the OSEK Operating System
should help to learn how to use OSEK OS. The Sample’s source files are
located in the SAMPLE directory - it contains all files needed to create
an executable file.
The Sample is not a real application and it does not perform any useful
work. But it has a certain algorithm so it is possible to track the execution.
It uses most of OSEK OS mechanisms and allows the user to have the
first look inside the OSEK OS.
The Sample consists of four tasks. It uses two counters (one of them is
the standard OSEK OS timer), three alarms, one resource, one
unqueued and one queued message. Timer interrupt is handled by the
ISR.
Generally, Sample tasks are divided into two pairs. TASKSND and
TASKRCV compose the first pair and TASKPROD, TASKCONS are the
second pair. This two pairs interacts with the help of the event
mechanism.
The task TASKSND is activated by the StartOS routine. It gets the

resource to provide exclusive access to the unqueued message MsgA,
modifies the message and sends it to TASKRCV. After that the resource
is released and the task terminates itself. MsgA consists of two parts (it
has the user defined type) and only one part (‘value’ is changed by
MOTOROLA Sample Application 279

Sample Application
R E Q U I R E D
TASKSND). The message is used without copying. Arrival of the

message activates the task TASKRCV.
TASKRCV receives the message MsgA and analyzes it. If the ‘value’ is
greater than the certain limit, the second part of MsgA is increased and
the event is set for the task TASKPROD (producer). In the end the task
releases the resource and terminates itself.
The task TASKPROD is activated by the StartOS routine. Just after the
activation the task activates the system counter (timer) and the counter
A G R E E M E N T
for messages and sets two alarms. To prevent rescheduling at this

moment the scheduler is got by the tasks as a standard resource. One
alarm is the relative cyclic alarm based on the system timer, it will be
used to “awake” the task, and the second alarm is the absolute alarm
based on the message counter. The message counter is intended to
count the number of items in the queued message MsgB. After all
initialization activities TASKPROD calls the WaitEvent service and, thus,
the task delays itself.
When TASKPROD becomes running again, it sends the queued message

MsgB. The message contents depends on the event which has caused
task awakening. After sending MsgB the message counter is triggered.
The task TASKCONS (consumer) has the lowest priority. This is

preemptive task. TASKCONS is activated by the alarm when the message

counter reaches the predefined number. The task reads (consumes)
queued message MsgB items and analyzes them. In case of the “S_OK”
message the message timestamp is saved in the variable “normal”. In
case of the “S_LIMIT” message the period of time elapsed between the
“S_OK” and “S_LIMIT” messages is saved in the variable “period”.
The user can watch the “normal” and “period” variables, the message
contents and so on.
A.3 Source Files

Source files for the Sample application are the following:
• “sample.c” – the application code,
280 Sample Application MOTOROLA

Sample Application
Source Files
R E Q U I R E D
• “cfg20.oil” – OSEK Implementation Language file (Version 2.0),
• “makefile” – command files to build the executable file,
• “vector.c”– Vector table,
• “crts.s” – Start-up module for Cosmic
• “make.bat“ – Environment Configuration file for OSEK OS (builds
executable file)
To build the executable file the user should make sure that OSEK OS
components are properly installed on the disk and pathes for the OSEK
A G R E E M E N T
directory and compiler software are known. The makefile was written for
Microsoft Visual C++ 4.2 NMAKE utility. Run the MAKE.BAT to build the
executable file. To build sample application for Cosmic compiler run
MAKE.BAT with 'c' variable set to 'cosmic12':
>MAKE "c=cosmic12"
To build sample application for M68HC12B32EVB run MAKE.BAT with

'type' variable set to 'B32':
>MAKE "type=B32"
To build sample application for M68HC12D60EVB user should run

MAKE.BAT with 'type' variable set to 'D60':
>MAKE "type=D60"
To clean all produced files in the OSEK\SAMPLE directory user should

run MAKE.BAT and set clean target:
>MAKE clean
(See the file "makefile" in the OSEK\SAMPLE directory for additional

information)
Makefile uses the system environment variables CXPATH, CXLIB and

OSEKDIR to get Cosmic and OSEK components.
When all produced filed are ready, the executable file can be load into
the Evaluation board (HC12D60EVB for example) and run.
MOTOROLA Sample Application 281

Sample Application
R E Q U I R E D
A G R E E M E N T
282 Sample Application MOTOROLA

R E Q U I R E D
Appendix B. System Service Timing
B.1 Contents
B.2 General Notes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .283
A G R E E M E N T
B.2 General Notes
The following notation is used to define four main states for run-time
services:
• Immediate Response (IR) – The service completes immediately

without any tasking changes.
• Stop Task (ST) – The service transfers the task from the running
state into another state (ready, waiting or suspended). Task
switching will take place.
• Task Waiting (TW) – The service called transfer another task into
the ready state (from waiting or suspended states). This task has
the same or lower priority than the task calling the service, or
preemption is disabled, therefore task switching will not take
place.
• Task Waiting and Context Switching (TWCS) – The service called
transfer another task into the running state (from ready, waiting or
suspended states). This task has the higher priority than the
calling task, therefore task switching is performed.
Results in Table B-1 and Table B-2 below was got on the basis of the
certain OS configuration. The list of systetm properties is shown below,
and this configuration is called in the table as “Initial”. Properties that are
not listed have their default values. In the column “Condition” the
differences from the given list (“Initial“) are indicated. For each
configuration the corresponded numbers are provided in the table.
MOTOROLA System Service Timing 283

System Service Timing
R E Q U I R E D
OIL_VERSION = "2.0";
#include "mot20.oil"
CPU cpu1 {
OS os1 {
OSVERSION = 2;
TargetMCU = HC12;
CC = BCC2;
EntryExitISR = TRUE;
InterruptMaskControl = TRUE;
SCHEDULE = FULL;
TaskIndexMethod = FALSE;
StackPool = FALSE;
A G R E E M E N T
TaskOwnStack = TRUE;
PersistentNode = TRUE;
PersistentStack = FALSE;
STATUS = EXTENDED;
ErrorHook = TRUE;
StartupHook = TRUE;
ShutdownHook = TRUE;
PreTaskHook = FALSE;
PostTaskHook = FALSE;
InternalErrorHandler = TRUE;
Resources = FALSE;
FastResource = FALSE;
Events = FALSE;
Counters = TRUE;
CounterSize = 32;
Alarms = TRUE;
AlarmList = TRUE;
UnqueuedMessages = TRUE;
UnqueuedMsgDefaultValue = TRUE;
QueuedMessages = FALSE;
QueuedMsgOneToN = FALSE;
ActivateOnMsg = FALSE;
AlarmOnMsg = FALSE;
SetEventOnMsg = FALSE;
DisableInterruptMask = 0x50;
EnableInterruptMask = 0x40;
TaskLevelMask = 0x40;
IsrStackSize = 255;
NodeNumber = 5;
MaxPrio = 5;
SchedStackSize = 255;
NodeStackSize = 255;
NodeStack = FALSE;
MultiplyActivation = TRUE;
};
284 System Service Timing MOTOROLA

General Notes
R E Q U I R E D
All numbers in the table are the number of CPU cycles counted by
reading the free running counter. Therefore, to calculate these numbers
in microseconds, these numbers must be multiplied by the period of
CPU clock. For instance, for HC12D60 with 16Mhz oscillator, CPU clock
frequency equals 8Mhz and the CPU clock period equals 0.125
microseconds the duration of GetResource service (for “Initial” system
configuration) is 34.125 microseconds (273 * 0.125*10-6 = 34.125*10-6).
It is possible that some real numbers can slightly differ from the
A G R E E M E N T
presented values due to some last changes in OSEK OS.
Table B-1. OSEKOS_20 version of the Operating System run-time services timing
characteristics (HC12D60, Cosmic software)(1)
Conditions IR ST TW TWCS
ActivateTask
BCC1, NONPREEMPT, STATUS=STANDARD,
Counters=FALSE, Alarms=FALSE,
UnqueuedMessages=FALSE, - - 301 -
QueuedMessages=FALSE, no hook routines, no
interrupts
NONPREEMPT - - 546 -
Initial - - 601 692
TerminateTask
UnqueuedMessages=FALSE, - 240 - -
interrupts
NONPREEMPT - 455 - -
Initial - 447 - -
ChainTask

R E Q U I R E D
UnqueuedMessages=FALSE, - - - 441
interrupts
NONPREEMPT - - - 845
Initial - - - 821
A G R E E M E N T
Schedule
67 - - 115
UnqueuedMessages=FALSE,
QueuedMessages=FALSE
NONPREEMPT 123 - - 266
Initial 123 - - -
GetTaskId
Initial 48 - - -
GetTaskState
Initial: running task 68
ready task 226 - - -
suspended task 266
EnterISR
Resources=TRUE, FastResource=TRUE 53 - - -
LeaveISR
EnableInterrupt
DisableInterrupt
GetInterruptMask
GetResource
ReleaseResource
Resources=TRUE, FastResource=TRUE 151 - - 353

General Notes
R E Q U I R E D
SetEvent
ECC1, NONPREEMPT 102 - 144 -
ECC1 102 - 180 280
ClearEvent
ECC1, NONPREEMPT 29 - - -
ECC1 29 - - -
A G R E E M E N T
GetEvent
ECC1, NONPREEMPT 98 - - -
ECC1 98 - - -
WaitEvent
ECC1, NONPREEMPT 38 169 - -
ECC1 38 187 - -
(2)
SendMessage
BCC1, an unqueued message with copy 107 - - -
(2)
ReceiveMessage
BCC1, an unqueued message with copy 111 - - -
(3)
SendMessage
BCC1, queued message, 1 receiver 209 - - -
(3)
ReceiveMessage
BCC1, queued message, 1 receiver 250 - - -
InitCounter
(4)
CounterTrigger
Resources=TRUE, FastResource=TRUE 151 - 741 869
GetCounterValue
GetCounterInfo
(4)
SetRelAlarm
(4)
SetAbsAlarm

R E Q U I R E D
CancelAlarm(4)
GetAlarm(4)
1. In all configurations number of task objects is 5.
A G R E E M E N T
2. In this configuration number of message objects is 7.
3. In this configuration number of message objects is 8.
4. In this configuration number of alarm objects is 1.


R E Q U I R E D
Appendix C. Memory Requirements
C.1 Contents
C.2 Memory for the OSEK Operating System. . . . . . . . . . . . . . . .289
A G R E E M E N T
C.3 Data Sheet for the Cosmic . . . . . . . . . . . . . . . . . . . . . . . . . . .292
C.2 Memory for the OSEK Operating System

The table below contains the data about ROM and RAM needed for the
OSEK Operating System kernel and system objects. The amount of
memory depends on the system configuration and on the number of
certain objects (e.g., tasks, counters, etc.). The table does not reflects all
possible configurations so the overall number of them is too big (more
than 2000). Therefore, only some most important configurations are
presented.
The following initial system property settings were used to determine
memory requirements:
OSVERSION = 2;
TargetMCU = HC12;
HCBankCode = FALSE;
HCBasePage = TRUE;
HCLowPower = FALSE;
CC = BCC1;
EntryExitISR = FALSE;
InterruptMaskControl = FALSE;
SCHEDULE = FULL;
SimpleScheduler = TRUE;
UseMainStack = FALSE;
UseSameContext = TRUE;
MultiplyActivation = FALSE;
TaskIndexMethod = FALSE;
TaskBasePage = TRUE;
NodeStack = FALSE;
StackPool = FALSE;
TaskOwnStack = TRUE;
MOTOROLA Memory Requirements 289

Memory Requirements
R E Q U I R E D
PersistentNode = FALSE;
PersistentStack = FALSE;
STATUS = STANDARD;
HookRoutines = FALSE;
ErrorHook = FALSE;
StartupHook = TRUE;
ShutdownHook = TRUE;
PreTaskHook = FALSE;
PostTaskHook = FALSE;
InternalErrorHandler = FALSE;
Resources = FALSE;
FastResource = FALSE;
Events = FALSE;
A G R E E M E N T
Counters = FALSE;
CounterSize = 8;
Alarms = FALSE;
AlarmList = FALSE;
UnqueuedMessages = FALSE;
UnqueuedMsgDefaultValue = FALSE;
QueuedMessages = FALSE;
QueuedMsgOneToN = FALSE;
ActivateOnMsg = FALSE;
AlarmOnMsg = FALSE;
SetEventOnMsg = FALSE;
This initial property list was used for the first row in the table. It conforms
to the BCC1 Conformance Class without any additional mechanisms
and this is the minimal OSEK OS configuration. The rows below reflects
memory requirements for the next Conformance Classes. System
properties are shown in the rows which are turned on for the
corresponded Conformance Class. For BCC2, ECC1, ECC2 the
scheduler policy is full-preemptive one.
All other rows below the first one (“Initial”) has a title “Initial” or
“Changed:” and one or more options turned ON or OFF. If a row has a
title “Initial” it means that for such OS configuration the Initial property list
is used with particular options changed as shown. If a row has a title
“Changed:” it means that for such OS configuration the setting list as for
the previous row is used with particular options changed as shown.
Thus, the system functionality grows up.
Under the title “Extensions” the additions are shown for each additional
system property (or group of them). These numbers are got on the base
of ECC2 configuration. For example, the row “Counters = ON” presents
the additional memory requirements for this mechanism. It allows the
290 Memory Requirements MOTOROLA

Memory Requirements
Memory for the OSEK Operating System
R E Q U I R E D
user to evaluate the amount of memory needed to support some
particular mechanisms and features. Differences between the amount of
memory required to support these features for various Conformance
Classes are comparatively small. Therefore, the data is provided only for
ECC2. Thus, since each next row includes all functionality of the
previous ones, the last row presents the memory requirements for the
system with full functionality.
Since each system object (a task, a message, an alarm, etc.) requires

some ROM and RAM the total amount of memory depends on the
number of objects. Therefore, the formulas should be used to calculate
A G R E E M E N T
the exact memory amount for each case. These formulas are provided
in the table.
NOTE: In the formulas in the table the following symbols are used:
• Ts is the number of tasks in non-suspended state;

• Tt is the total number of tasks;
• C is the number of counters;
• A is the number of alarms;
• S is the number of unqueued messages;
• E is the number of queued messages;
• P is the number of tasks’ priorities;
• R is the number of resources;
• Sp is the number of stack pools;
• Sb is the number of stack buffers.
It is possible that some real numbers can slightly differ from the
presented values due to some last changes in OSEK OS.

Memory Requirements
R E Q U I R E D
C.3 Data Sheet for the Cosmic

Table C-1. OSEKOS_20 version of the Operating System memory requirements
Confor-
System Properties Base Page
Number mance ROM RAM
(configuration) RAM
Class
0 Initial - 840+7*Tt 23+7*Ts
Initial
1 - 825+7*Tt 23+9*Ts
SCHEDULE = NON
Initial
2 - 840+7*Tt 23+7*Ts
SCHEDULE = MIXED
A G R E E M E N T
Initial
3 SCHEDULE = MIXED - 894+7*Tt 23+9*Ts
UseSameContext = FALSE
Changed:
4 HCBasePage = FALSE 23+7*Ts 890+7*Tt -
TaskBasePage = FALSE
Changed: BCC1
5 21+7*Ts 1001+10*Tt -
STATUS = EXTENDED
Changed:
6 21+7*Ts 1001+10*Tt -
ErrorHook = TRUE
Changed:
STATUS = STANDARD
7 25+7*Ts 1056+7*Tt -
ErrorHook = FALSE
EntryExitISR = TRUE
Changed:
8 27+7*Ts 1165+8*Tt -
InterruptMaskControl = TRUE
Changed:
081 27+7*Ts 1191+10*Tt -
Reconfig = TRUE
Initial
9 - 936+7*Tt 29+10*Ts+4*P
SimpleScheduler = FALSE
Changed:
10 HCBasePage = FALSE 29+10*Ts+4*P 991+7*Tt -
Initial
11 SimpleScheduler = FALSE - 1266+11*Tt 31+10*Ts+4*P
MultiplyActivation = TRUE BCC2
Changed:
Changed:
13 29+10*Ts+4*P 1456+14*Tt -
STATUS = EXTENDED
Changed:
14 29+10*Ts+4*P 1541+14*Tt -
ErrorHook = TRUE

Memory Requirements
Data Sheet for the Cosmic
R E Q U I R E D
Confor-
(configuration) RAM
Class
Initial
15 SimpleScheduler = FALSE - 1075+7*Tt 29+12*Ts+4*P
Events = TRUE
Changed:
Changed:
17 27+12*Ts+4*P 1336+10*Tt -
STATUS = EXTENDED
A G R E E M E N T
ECC1
Changed:
18 27+12*Ts+4*P 1502+10*Tt -
ErrorHook = TRUE
Changed:
STATUS = STANDARD
19 31+12*Ts+4*P 1349+7*Tt -
ErrorHook = FALSE
EntryExitISR = TRUE
Changed:
20 33+12*Ts+4*P 1494+8*Tt -
InterruptMaskControl = TRUE
Initial
SimpleScheduler = FALSE
21 ECC2 - 1407+11*Tt 31+12*Ts+4*P
MultiplyActivation = TRUE
Events = TRUE

Memory Requirements
R E Q U I R E D

Confor-
(configuration) RAM
Class
Extensions (based on the configuration for ECC2)
Changed: 1562+11*Tt+3
22 2*R 31+14*Ts+4*P
Resources = TRUE *R
Changed:
23 - 1546+11*Tt 33+12*Ts+4*P
FastResource = TRUE
24 1*C 33+12*Ts+4*P
A G R E E M E N T
Counters = TRUE *C
25 2*C 33+12*Ts+4*P
CounterSize = 16 *C
26 4*C 33+12*Ts+4*P
CounterSize = 32 0*C
Changed:
2108+11*Tt+6
27 Alarms = TRUE 3*C+8*A 33+12*Ts+4*P
*C+7*A
CounterSize = 8
28 3*C+11*A 33+12*Ts+4*P
AlarmList = TRUE *C+7*A
Changed: 3*C+11*A+3* 2445+11*Tt+4
29 33+12*Ts+4*P
UnqueuedMessages = TRUE S *C+7*A+5*S
Changed: 3*C+11*A+3* 2478+11*Tt+4
30 ECC2 33+12*Ts+4*P
UnqueuedMsgDefaultValue = TRUE S *C+7*A+7*S
2711+11*Tt+4
Changed: 3*C+11*A+3*
31 *C+7*A+7*S+ 33+12*Ts+4*P
QueuedMessages = TRUE S+39*E
11*E
2830+11*Tt+4
32 *C+7*A+7*S+ 33+12*Ts+4*P
QueuedMsgOneToN = TRUE S+39*E
15*E
2891+11*Tt+4
33 *C+7*A+10*S 33+12*Ts+4*P
ActivateOnMsg = TRUE S+39*E
+18*E
2907+11*Tt+4
34 *C+7*A+10*S 33+12*Ts+4*P
SetEventOnMsg = TRUE S+39*E
+18*E
3052+11*Tt+4
35 *C+7*A+13*S 33+12*Ts+4*P
AlarmOnMsg = TRUE S+39*E
+21*E
3218+11*Tt+1
Changed: 4*Sp+3*C+11*
36 0*Sp+4*C+7* 33+14*Ts+4*P
StackPool = TRUE A+3*S+43*E
A+13*S+21*E

Memory Requirements
Data Sheet for the Cosmic
R E Q U I R E D
Confor-
(configuration) RAM
Class
3265+11*Tt+1
37 0*Sp+4*C+7* 33+16*Ts+4*P
NodeStack = TRUE A+3*S+47*E
A+13*S+21*E
3348+13*Tt+1
38 0*Sp+4*C+7* 33+16*Ts+4*P
PersistentNode = TRUE A+3*S+47*E
A+13*S+21*E
3390+13*Tt+1
4*Sp+3*C+11*
A G R E E M E N T
Changed:
39 0*Sp+4*C+7* 33+16*Ts+4*P
PersistentStack = TRUE A+3*S+47*E
A+13*S+21*E
33+16*Ts+4*P
+4*Sp+3*C+1
40 HCBasePage = FALSE 0*Sp+4*C+7* -
1*A+3*S+47*
A+13*S+21*E
E
31+16*Ts+4*P
ECC2 4058+16*Tt+1
Changed: +4*Sp+3*C+1
41 0*Sp+7*C+7* -
STATUS = EXTENDED 3*A+5*S+47*
A+13*S+21*E
E
31+16*Ts+4*P
4431+16*Tt+1
42 0*Sp+7*C+7* -
ErrorHook = TRUE 3*A+5*S+47*
A+13*S+21*E
E
33+16*Ts+4*P
5125+16*Tt+1
43 0*Sp+7*C+7* -
EntryExitISR = TRUE 3*A+5*S+49*
A+13*S+21*E
E
35+16*Ts+4*P
5349+17*Tt+1
44 0*Sp+7*C+7* -
InterruptMaskControl = TRUE 3*A+5*S+51*
A+13*S+21*E
E

Memory Requirements
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Appendix D. System Generation Error Messages
D.1 Contents
D.2 Error Message Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
A G R E E M E N T
D.3 Error Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .297
D.4 Warning Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .314
D.2 Error Message Format

The System Generator checks the compatibility of properties,
parameters and limits and reports about possible errors via error
messages. The error messages are divided into errors and warnings. By
convention messages are divided into subgroups according to related
objects. The error code is presented by the following string LNN##:
L is equal to “E” for error and” W” for warning,
NN presents the group number,
## presents the error number inside the group.
An error message includes the file name, the line number, the error code
and a short error (or warning) description. The error message has one of
the following formats:
<filename>(<line number>) : error ENN## : <message>

<filename>(<line number>) : warning WNN## : <message>
Below all System Generator error and warning messages are described.
D.3 Error Messages

E0001: syntax error
MOTOROLA System Generation Error Messages 297

System Generation Error Messages
R E Q U I R E D
A syntax error was found in the input stream. Problems of this type can
sometimes be attributed to a syntactical or clerical error. For example:
TASK taskA
{
PRIORITY = 5 // No closing semicolon
SCHEDULE = FULL;
};
In the preceding example, the error message will be generated for the
line which contains the definition of SCHEDULE attribute, although the
true source of the error appears on the line just above. As a general rule,
A G R E E M E N T
make sure to also examine the lines above the line listed in the error
message when trying to determine the cause.
E0002: invalid token ’<token>’
An invalid (unrecognizable) token was found in the input stream.
E0003: unexpected end of file found in comment
The system generator found the end of a file while scanning a comment.
A comment cannot be split across source files.
This error can also be caused by a comment on the last line of a source
file that is not followed by the ‘CR’ symbol as in the example:
int i; // error: last line not terminated by newline
To eliminate this error, go to the end of the line and add a new line.
E0004: Unexpected EOF
The system generator reached the end of a source file without resolving
a construct.
For instance, a object definition may be missing a closing curly brace.
E0005: End of line in STRING
A string constant was continued on a second line without a backslash (\)

or the closing double-quote missed.
To break a string constant that is on two lines in the source file, end the
first line with the line-continuation character, a backslash.
298 System Generation Error Messages MOTOROLA

Error Messages
R E Q U I R E D
E0011: cannot open source file: <name>
cannot open include file: <name>
cannot open output file: <name>
This file either did not exist, could not be opened, or was not found.
There are three possible reasons of that:
– This error can occur if the file, subdirectory, or disk on which it resides
is read-only. In this case, make the file writable or move the file to a
writable disk.
A G R E E M E N T
– Trying to open a file or directory for which you do not have permission
can cause this error.
– If an include file could not be opened, check that the INCLUDE

environment variable is set correctly and that the name of the file is
spelled correctly.
E0012: cannot read file: <name>
The system generator encountered an error when trying to read a file.
This error can be caused by a disk error or by a file-sharing conflict.
E0013: cannot write file: <name>
An error occurred while SG was trying to write into the file.
E0014: Disk is full
An error occurred while the system generator was trying to write to the
output file. The cause of this error is insufficient disk space.
E0015: Template file not found
The system generator could not find template file for use in the
generation process because the command-line option or
SYSGEN_TEMPLATE environment variable was set to an invalid
filename.
To eliminate this error, either correct command line or use the SET
command to change the SYSGEN_TEMPLATE environment variable so
that it points to a valid filename.

R E Q U I R E D
E0020: <flag> requires an argument
A command-line option requires an argument, but nothing is specified.
E0021: no input file specified
The input file is not specified in the command line.
E0030: Incorrect object name
Incorrect name was defined for object. The first character of an identifier
name must be an underscore or an uppercase or lowercase letter. The
A G R E E M E N T
next characters of an identifier name must be an underscore or an

uppercase or lowercase letter or a digit.
The following OIL keywords can not be used as identifier:

STRING, INT, BOOLEAN, ENUM, AUTO, WITH_AUTO,
CPU, GROUP, CFG, PCFG, CONSTANT, NETWORK,
OS, TASK, MESSAGE, STACK, ISR, EVENT, RESOURCE,
COUNTER, ALARM,
COM, NM, NODE, NETMESSAGE, CONNECTION, LINK,
NMCFGALARM, NMSTATEALARM.
E0032: Undefined object type

The non-standard object type was detected, object definition ignored.
E0033: This OIL version is not supported
The unsupported OIL version was defined as value for the

OIL_VERSION attribute.
E0034: Undefined OIL version
The undefined OIL version was detected.
E0035: Only one CPU can be defined in the STANDARD OIL
E0036: Configuration is not supported in the STANDARD OIL
E0037: Object library is not supported in the STANDARD OIL
E0038: CPU <name>: CFGACTIVE attribute is not supported in the

Standard format

Error Messages
R E Q U I R E D
The standard OIL format is intended to define simple application inside
separate CPU without using object library and configuration.
E0039: CPU <name>: Active CFG <cfg> is not defined.

Attribute "CFGACTIVE" deleted
The CFGACTIVE attribute was defined while the CFG with desired
name was not detected.
E0040: Same name <name> is used for different objects.

CPU <cpu>: Same name for several object inside cfg: <name>
A G R E E M E N T
CPU <cpu>: Same name for several object inside Cpu: <name>
The given name has already been used for a system object of the other
type.
E0041: <object type> objects are not supported
The object type is not supported in the current implementation.
E0042: No NET can be defined in the STANDARD OIL

separate CPU without NETWORK configuration.
E0043: Project Configuration is not supported in the STANDARD
OIL

separate CPU without using Project configuration.
E0044: Constant Table is not supported in the STANDARD OIL
The standard OIL format is intended to define simple application without

using Constant tables.
E0046: Invalid reference
The reference was not defined in the implementation.
E0047: <name> reference is single, so only one parameter will be

processed!
The set of values was listed for single reference.

R E Q U I R E D
E0048: Unresolved reference from <name> to <name>
The referenced object was not found.
E0049: Invalid referenced object type from <name> to <name>
The referenced object type does not correspond to reference type.
E0050: CPU <name>: More than one OS defined inside local object
CPU <name>: More than one OS defined inside cfg: <name>
Only one OS shall be defined for application.

A G R E E M E N T
E0051: Desired cpu <name> is not defined in the file

No cpu was defined in the file
Either the CPU specified in command line was not found in the file or no
CPU was defined in the file.
E0052: Active Project CFG <pcfg> is not defined
The PCFGACTIVE attribute was defined while the PCFG with desired
name was not detected.
E0053 no <name> configuration defined inside <cpu> CPU

no <name> configuration defined inside <net> NETWORK
The setting for CPU or NETWORK was defined inside PCFG but the
referenced CFG was not defined for defined object.
E0054: unresolved reference from project configuration <pcfg> to

<name>
The setting for CPU or Network was defined inside PCFG but neither
CPU nor NETWORK with the name was defined.
E0055: redefinition of <name> table item
The given identifier was defined twice inside table (either Constant or
Project configuration table). The system generator used the second
definition.
E0056: redefinition of CPU <cpu> configuration

Error Messages
R E Q U I R E D
The configuration for given CPU was defined twice inside Project
configuration table. The system generator used the second definition.
E0070: Only one implementation definition is allowed
More than one Implementation definition was found in the input file.
E0071: Redefined type of reference does not correspond to

previously defined.
New type ignored!
Other reference type defined for standard reference.
A G R E E M E N T
E0072: Redefined type of referenced object does not correspond to
previously defined
Other referenced object type defined for standard reference.
E0073: Redefined type of attribute does not correspond to

standard.
Definition ignored
Other type of standard attribute defined.
E0074: Attribute redefinition: previous attribute definition ignored
Implementation specific attribute was defined twice, only last definition
make a sense.
E0075: Invalid default value
Default value does not correspond to attribute type or attribute value

range.
E0076: Range value does not correspond to attribute type, ignored
Range value does not correspond to attribute type.
E0077: undefined type of referenced object
The undefined type of referenced object was defined in reference

definition.

R E Q U I R E D
E0080: <attribute name> attribute is not defined in the

implementation
The used implementation does not correspond to current version of

system generator. Check your implementation file or contact vendor.
E0090: the <name> application mode is not defined
The application mode is listed as the CFG_ACTIVE attribute value but

there is not the CFG with defined name.
A G R E E M E N T
E0091: only TASK can be redefined for mode
Other than TASK object is defined inside CFG declared as application

mode. There is restriction that only set of tasks can be varied in
application mode.
E0092: TargetMCU shall be defined
The default value for TargetMCU is not allowed.
E0100: No OS defined for Cpu: <cpu name>

No OS defined inside cfg: <cfg name>
OS is mandatory object for CPU. The OS shall be defined either in local

CPU object or for each configuration.
E0102: Undefined attribute
The attribute was not defined in the implementation.
E0103: Invalid attribute value
The attribute value does not correspond to the type or range.
E0104: incorrect property <name> setting
The setting of the property <name> is incompatible with other current

settings.
E0105: method of task stack assignment is not defined
At least one of task stack assignment methods shall be defined, either

NodeStack or StackPool or TaskOwnStack.

Error Messages
R E Q U I R E D
E0106: SimpleScheduler property can not be used with Resources
property
If SimpleScheduler is used then the resources can not be used.
E0107: Conformance class shall be defined
The CC attribute was not defined.
E0108: status shall be defined
The STATUS attribute was not defined.
A G R E E M E N T
E0110: interrupt masks shall be defined
The InterruptMaskControl property is turned on, but the interrupt masks

are not defined.
E0111: interrupt stack shall be defined
The EntryExitISR property is turned on, but the interrupt stack is not
defined.
E0112: Multiple activation is not supported in BCC1

Multiple activation is not supported in ECC1
According to OSEK OS spec. v2.0 Multiple task activation is not
supported for the BCC1 and ECC1 conformance classes.
E0113: no task with multiple activation defined
The MultiplyActivation property is turned on, but no task with multiple

activation defined. To avoid this error turn the MultiplyActivation property
of or define ACTIVATION attribute for task greater than 1.
E0115: TimeModuloValue shall be defined
The TimerModulo property is turned on, but TimerModuloValue is not

defined.
E0116: PrescalerValue shall be defined
The Prescaler property is turned on, but PrescalerValue is not defined.

R E Q U I R E D
E0117: resource access checking is not supported in standard

status
The ResourceAccessCheck property is turned on, but STANDARD

status of the system defined. To avoid this error set EXTENDED status
or turn ResourceAccessCheck property off.
E0118: resource access checking is not supported for

FastResource
The ResourceAccessCheck property is turned on, but FastResource

A G R E E M E N T
property is turned on too. To avoid this error set FastResource property

off.
E0119: resource access checking is not supported for more than 8

resources
The ResourceAccessCheck property is turned on, but more than 8

resources are defined. To avoid this error set ResourceAccessCheck
property off.
E0120: error hook shall be defined
The ErrorHook property is turned on, but the error hook is not defined.
E0121: context switch routines shall be defined
The PreTaskHook or PostTaskHook property is turned on, but the

corresponding routine is not defined.
E0122: more than one hook of the type defined
The several hooks with the same type were defined.
E0123: startup hook shall be defined
The StartupHook property is turned on, but the startup hook is not
defined.
E0124: shutdown hook shall be defined
The ShutdownHook property is turned on, but the shutdown hook is not
defined.

Error Messages
R E Q U I R E D
E0160: Reconfig property turned off, no application mode
supported
More than one application modes are defined but Reconfig property is
turned off. Either turn Reconfig property on or change definition of
application mode set.
E0201: the number of task control blocks shall be greater than 0
The NodeNumber attribute is equal to 0.
E0202: number of priorities shall be greater than 0
A G R E E M E N T
The MaxPrio attribute is equal to 0.
E0203: size of scheduler stack shall be defined
The UseMainStack property is turned off, but the SchedulerStackSize

attribute is not defined.
E0204: size of task node stack shall be defined
The NodeStack property is turned on, but the TaskNodeStackSize

E0205: number of task control blocks less than priority range
The number of task control blocks are less than maximum of task
priority, it is not enough in case of SimpleScheduler.
E0302: EXTENDED task not supported in BASIC classes
The OS Conformance Class is defined as one of the BCC classes, but a

task has the EXTENDED type.
E0304: task priority exceeds the maximum limit
The defined task priority is greater than MaxPrio attribute defined for OS.
E0305: the number of task nodes is not enough to allocate

persistent nodes
The number of tasks with persistent node are greater than the number
of nodes. Also this error is caused when the number of tasks with

R E Q U I R E D
persistent node is equal to number of nodes and there are at least one
more tasks.
E0306: the stack pool parameter shall be defined
A task has the defined POOLSTACK stack attachment method, but the
StackPool reference has not been defined.
E0308: the basic task cannot be notified by event setting
The basic task is referenced by ALARM or MESSAGE to be notified by

A G R E E M E N T
event setting.
E0309: at least one task shall be defined
At least one task shall be defined in the system.
E0310: NodeStack property is turned off, stack cannot be allocated
A task has the defined NODESTACK stack attachment method, but the
NodeStack property is turned off.
E0310: StackPool property is turned off, stack cannot be allocated
A task has the defined POOLSTACK stack attachment method, but the
StackPool property is turned off.
E0311: task has no stack
The method of task stack attachment is not defined or not supported by

the OS.
E0312: the stack size parameter shall be defined
A task has the defined OWNSTACK attachment method, but the

STACKSIZE attribute has not been defined.
E0313: Multiple activation is not supported for EXTENDED task

Multiple activation is not supported in BCC1
Multiple activation is not supported in ECC1
The ACTIVATION attribute has the value greater than 1, but according
to OSEK OS spec. 2.0 multiple task activation is not supported in the

Error Messages
R E Q U I R E D
BCC1 and ECC1 conformance classes for BACIS task and never
supported for EXTENDED task.
E0314: non-preemptive tasks are not supported by full-preemptive

scheduler
preemptive tasks are not supported by non-preemptive
scheduler
The defined task preemptive property is incompatible with defined

scheduling policy.
A G R E E M E N T
E0318: task scheduling type shall be defined
Task preemptive property is not defined. The SCHEDULE attribute is

obligatory for TASK object.
E0319: task type shall be defined
The task type is not defined. The TYPE attribute is obligatory for TASK
object.
E0320: task priority shall be defined
Task priority property is not defined. The PRIORITY attribute is

E0321: number of task activations shall be defined
Number of task activations is not defined. The ACTIVATION attribute is

E0322: AUTOSTART task property shall be defined
Initial task state is not defined. The AUTOSTART attribute is obligatory

for TASK object.
E0323: only EXTENDED task can have Events
The BASIC task has the reference to EVENT.
E0324: EVENT not supported in BASIC classes
The task has the reference to EVENT.

R E Q U I R E D
E0325: TaskOwnStack property is turned off, stack cannot be

allocated
A task has the defined OWNSTACK stack attachment method, but the
TaskOwnStack property is turned off.
E0326: the same priority can’t be defined for tasks in case of

SimpleScheduler
The simplified scheduler can be used only if each task in the application
has an unique priority.
A G R E E M E N T
E0351: Size of buffer in the pool shall be defined
Size of buffer in the pool shall be defined for the STACK object.
E0352: Number of buffers in the pool shall be defined
Number of buffers in the pool shall be defined for the STACK object.
E0401: resource priority exceeds the maximum limit
The defined PRIORITY attribute for RESOURCE is greater than

MaxPrio attribute of OS.
E0450: ISR category shall be defined

The CATEGORY attribute is obligatory for ISR object.
E0470: No tasks referencing event, AUTO mask can not be

calculated
If an event has AUTO as mask, then some task should have reference
to this event.
E0451: ISR of category 3 is not supported without EntryExitISR
The ISR of category 3 has the ISR-frame which is started with EnterISR
and finished by ExitISR call. The pair of function is obligatory for ISR of
category 3.
E0471: Events not supported in BASIC classes

Error Messages
R E Q U I R E D
The EVENT object is defined, but one of the BASIC conformance
classes is defined for OS.
E0472: MASK attribute shall be defined
The MASK attribute is obligatory for EVENT object.
E0501: system timer is already defined
Only one of the defined counters shall have the SystemTimer attribute
TRUE.
A G R E E M E N T
E0502: System timer is undefined
If the OS attribute SysTimer is set to TRUE but there is no COUNTER

defined then the System Timer is considered as undefined.
E0503: TICKDURATION attribute shall be defined for system timer
The TICKDURATION attribute is not defined for system timer. The value
of this attribute is used for definition of the OSTICKDURATION constant.
E0511: MAXALLOWEDVALUE attribute shall be defined
The MAXALLOWEDVALUE attribute is obligatory for COUNTER object.
E0512: TICKSPERBASE attribute shall be defined
The TICKSPERBASE attribute is obligatory for COUNTER object.
E0601: assigned counter is undefined
The COUNTER reference is not defined.
E0602: task to event setting shall be defined
The TASK reference is not defined.
E0603: type of notification shall be defined
The ACTION attribute is obligatory for ALARM object.
E0604: task activation method is defined, event shall not be defined
The task activation method is defined, but reference to event is defined

too.

R E Q U I R E D
E0605: event to be set shall be defined
The event setting task notification method is defined but reference to

event is not defined.
E0606: task to be notified shall be defined
The ALARM has the reference to EVENT while one of the BASIC
A G R E E M E N T
conformance classes has been defined for OS.
E0608: Events property is turned off, notification can not be

defined
This error message is generated in the case when the SETEVENT

notification action is defined but OS Events property is set to FALSE.
E0706 : Queued message can not be used in without copy mode
The WithCopy attribute shall be TRUE for the Queued message.
E0711: message type shall be defined
The TYPE attribute is obligatory for MESSAGE object.

E0712: number of items shall be defined
The ITEMS attribute is obligatory for MESSAGE object.
E0713: type of item shall be defined
The ITEMTYPE attribute is obligatory for MESSAGE object.
E0714: reference to alarm shall be defined
The ALARMRESETTIME attribute is defined but the ALARMRESET

reference is not defined.
E0715: alarm period shall be defined
The ALARMRESET reference is defined but the ALARMRESETTIME


Error Messages
R E Q U I R E D
E0716: task to event setting shall be defined
The event setting notification method is defined but the TASK reference
is not defined.
The EVENT reference is defined for message while one of the BASIC
conformance classes has been defined for OS.
E0718: Unqueued message can not have more than 1 items
A G R E E M E N T
The ITEMS attribute has value greater than 1 for unqueued message.
E0719: type of notification shall be defined
The ACTION attribute is obligatory for MESSAGE object.
E0720: task activation method is defined, event shall not be defined
The task activation method is defined, but reference to event is defined

too.
E0721: task notification method is NONE, event shall not be defined
The task notification method is NONE, but reference to event is defined.
E0722: task notification method is NONE, task shall not be defined
The task notification method is NONE, but reference to task is defined.
E0723: task to be notified shall be defined
E0724: event to be set shall be defined
The event setting task notification method is defined but reference to

event is not defined.
E0850: <filename> or "filename" expected
The incorrect syntax of include directive.
E0851: <filename without path> expected

R E Q U I R E D
The incorrect syntax of include directive.
E0852: unknown directive: <directive>
Unknown preprocessing directive was detected.
E0853: undefined directive
No preprocessing directive was detected.

A G R E E M E N T
D.4 Warning Messages

W0020: ignoring unknown option <flag>
The <flag> in the command-line option is not valid; the option is ignored.
W0031: <name> : identifier was truncated to 32 characters
The identifier is longer than 32 characters.
W0101: <name> attribute already defined
The attribute <name> has been previously defined and will be re-
defined.
W0102: <name> reference already defined

The reference <name> has been previously defined and will be re-
defined.
W0110: UseMainStack property is turned on, parameter ignored
The UseMainStack property is turned on, but either the scheduler stack
or the interrupt stack is defined.
W0120: ErrorHook property turned off, definition ignored
The ErrorHook property is turned off, but the error hook is defined.
W0121: PreTaskHook property turned off, definition ignored

PostTaskHook property turned off, definition ignored
The PreTaskHook or PostTaskHook property is turned off, but the

corresponding routine is defined.

Warning Messages
R E Q U I R E D
W0122: StartupHook property turned off, definition ignored
The StartupHook property is turned off, but the startup hook is defined.
W0123: ShutdownHook property turned off, definition ignored
The ShutdownHook property is turned off, but the shutdown hook is

defined.
W0150: NetworkCOM property turned on, but this version does not
support COM generation, definition ignored
A G R E E M E N T
The NetworkCOM property is turned on, but this version of system
generator does not support generation of COM objects.
W0201: NodeStack property is turned off, parameter ignored
If the NodeStack property is turned off then the node stacks are not
supported and parameters defining this stack are ignored.
W0202: there are unused task control blocks
The number of task control blocks are greater than maximum defined
priority of a task, therefore in case of SimpleScheduler the unused
control blocks exist.
W0304: Multiple activation is not supported
The MultiplyActivation property is set to FALSE but the task has
ACTIVATION greater than 1.
W0306: PersistentNode property is turned off, parameter ignored
A task has the defined PersistentNode attribute, but the OS

PersistentNode property is turned off.
W0307: PersistentStack property is turned off, parameter ignored
A task has the defined PersistentStack attribute, but the OS

PersistentStack property is turned off.
W0308: persistent stack may be assigned only for task with

persistent node, parameter ignored

R E Q U I R E D
A task has the defined PersistentStack attribute, but the PersistentNode

attribute is not defined. The PersistentStack attribute is ignored in this
case.
W0309: persistent stack shall be assigned from stack pool,

parameter ignored
A task has the defined PersistentStack attribute, but other than

POOLSTACK stack method is defined. The PersistentStack attribute is
ignored in this case.
A G R E E M E N T
W0311: the stack address shall be defined for OWNSTACK,

parameter ignored
A task has the defined StackAddress attribute, but StackMethod

attribute is not OWNSTACK.
W0350: StackPool property turned off, definition ignored
The STACK object is defined, but the StackPool property turned off.
W0400: Resources property turned off, definition ignored
The RESOURCE object is defined, but the Resources property of OS

turned off.
W0401: Scheduler resource has highest priority, definition ignored
It is not possible to define PRIORITY for RES_SCHEDULER object.
W0402: no task referencing resource
Resource is defined, but not referenced by any task.
W0470: Events property turned off, definition ignored
The EVENT object is defined, but the Events property of OS turned off.
W0500: Counters property turned off, definition ignored
The Counters property of OS is turned off but the COUNTER object is

defined.

Warning Messages
R E Q U I R E D
W0503: TICKDURATION attribute is applied for system timer only,
parameter ignored
If the counter is not the system timer then the definition of the
TICKDURATION is ignored.
W0600: Alarms property turned off, definition ignored
The Alarms property of OS is turned off but the ALARM object is defined.
W0700: UnqueuedMessages property is turned off, definition

ignored
A G R E E M E N T
QueuedMessages property is turned off, definition ignored
The message object is defined but corresponding OS property is turned

off.
W0701: UnqueuedMsgDefaultValue property is turned off,

parameter ignored
The DefaultValue attribute for Unqueued Message is defined, but

UnqueuedMsgDefaultValue property is turned off.
W0704: QueuedMsgOneToN property is turned off, parameter

ignored
The number of receivers is greater than one, but QueuedMsgOneToN is
turned off.
W0705: AlarmOnMsg property is turned off, definition ignored
The ALARMRESET reference is defined, but AlarmOnMsg property is

turned off.
W0708: ActivateOnMsg property is turned off, definition ignored
The TASK reference is defined, while the ActivateOnMsg property is

turned off.
W0709: SetEventOnMsg property is turned off, definition ignored
The TASK and EVENT references are defined, while the

SetEventOnMsg property is turned off.

R E Q U I R E D
W0710: Queued Message cannot have default value, parameter

ignored
The DefaultValue attribute is defined for queued message.
W0711: Number of receivers doesn’t matter for Unqueued

message, parameter ignored
The ReceiverNum attribute is defined for state message and has value
greater than 1.
A G R E E M E N T
W0719: Events property is turned off, parameters ignored
The specified method of task notification is not supported.
W1001: NETWORK objects are not supported by this version,

definition ignored
The NETWORK object is defined, but this version of system generator

does not support generation of COM objects.

R E Q U I R E D
Appendix E. Quick Reference
E.1 Contents
E.2 System Services Quick Reference . . . . . . . . . . . . . . . . . . . . .319
A G R E E M E N T
E.3 OIL language Quick Reference . . . . . . . . . . . . . . . . . . . . . . .325
E.2 System Services Quick Reference

The brief list of all OSEK Operating System run-time services is provided
below. Input and output parameters, syntax and ability to use in ISR are
shown.
Table E-1. OSEK OS services

Service Input Output ISR
Task management services
Task name – Yes
ActivateTask
syntax: StatusType ActivateTask(TaskType <TaskName>);
– – No
TerminateTask
syntax: StatusType TerminateTask(void);
Task name – No
ChainTask
syntax: StatusType ChainTask(TaskType <TaskName>);
– – No
Schedule
syntax: StatusType Schedule(void);
– Task name No
GetTaskId
syntax: StatusType GetTaskId(TaskRefType <TaskName>);
Task name Task state Yes
GetTaskState syntax: StatusType GetTaskState(TaskType <TaskName>,
TaskStateRefType <State>);
– Task Control Block Yes
GetTCBInfo1
syntax: StatusType GetTCBInfo(TaskControlBlockRefType <Tcb>);
Interrupt management services
MOTOROLA Quick Reference 319

Quick Reference
R E Q U I R E D

– – Yes
EnterISR
syntax: StatusType EnterISR(void);
– – Yes
LeaveISR
syntax: StatusType LeaveISR(void);
Interrupt descriptor – Yes
EnableInterrupt
syntax: StatusType EnableInterrupt(IntDescriptorType <Descr>);
Interrupt descriptor – Yes
A G R E E M E N T
DisableInterrupt
syntax: StatusType DisableInterrupt(IntDescriptorType <Descr>);
– Interrupt descriptor Yes
GetInterruptDescriptor
syntax: StatusType GetInterruptDescriptor(IntDescriptorRefType <Descr>);
Resource management services
Resource name – No
GetResource
syntax: StatusType GetResource(ResourceType <ResName>);
Resource name – No
ReleaseResource
syntax: StatusType ReleaseResource(ResourceType <ResName>);
Event control services
Task name, Event mask – Yes
SetEvent syntax: StatusType SetEvent (TaskType <TaskName>,
EventMaskType <Mask>);
Event mask – No
ClearEvent
syntax: StatusType ClearEvent(EventMaskType <Mask>);
Task name Event mask Yes
GetEvent syntax: StatusType GetEvent(TaskType <TaskName>,
EventMaskRefType <Mask>);
Event mask – No
WaitEvent
syntax: StatusType WaitEvent(EventMaskType <Mask>);
Message management services
Message name, message data – Yes2
SendMessage syntax: StatusType SendMessage( SymbolicName <Message>,
AccessName <Data>);
Message name Message data Yes/No3
ReceiveMessage syntax: StatusType ReceiveMessage(SymbolicName <Message>,
AccessName <Data>);
Message name – No
GetMessageResource
syntax: StatusType GetMessageResource(<MessageName>);
320 Quick Reference MOTOROLA

Quick Reference
System Services Quick Reference
R E Q U I R E D
Message name – No
ReleaseMessageResource
syntax: StatusType ReleaseMessageResource(<MessageName>);
Message name – Yes
GetMessageStatus
syntax: StatusType GetMessageStatus(<MessageName>);
Counter management services
Counter name, initial value – No
InitCounter syntax: StatusType InitCounter(CtrRefType <CtrName>,
TickType <Ticks>);
A G R E E M E N T
Counter name – Yes
CounterTrigger
syntax: StatusType CounterTrigger(CtrRefType <CtrName>);
Counter name, number of ticks – No
AdvanceCounter4 syntax: StatusType AdvanceCounter(CtrRefType <CtrName>,
TickType <Ticks>);
Counter name Counter value No
GetCounterValue syntax: StatusType GetCounterValue(CtrRefType <CtrName>,
TickRefType <Ticks>);
Counter name Counter constants No
GetCounterInfo syntax: StatusType GetCounterInfo(CtrRefType <CtrName>,
CtrInfoRefType <Info>);
Alarm management services
Alarm name Alarm constants Yes
GetAlarmBase syntax: StatusType GetAlarmBase(AlarmType <AlarmName>,
AlarmBaseRefType <Info>);
Alarm name, Counter relative value,
– Yes
Cycle value
SetRelAlarm
syntax: StatusType SetRelAlarm (AlarmType <AlarmName>,
TickType <Increment>, TickType <Cycle>);
Alarm name, Counter absolute value,
– Yes
Cycle value
SetAbsAlarm
syntax: StatusType SetAbsAlarm (AlarmType <AlarmName>,
TickType <Start>, TickType <Cycle>);
Alarm name – Yes
CancelAlarm
syntax: StatusType CancelAlarm(AlarmType <AlarmName>);
Relative value in ticks before the
Alarm name Yes
alarm expires
GetAlarm
syntax: StatusType GetAlarm(AlarmType <AlarmName>,
TickRefType <Ticks>);

Quick Reference
R E Q U I R E D

Execution control services
– Current application mode Yes
GetActiveApplicationMode
syntax: AppModeType GetActiveApplicationMode(void);
Operating mode – No
StartOS
syntax: void startOS(ModeType <Mode>);
Error code – No
ShutdownOS
syntax: void shutdownOS(StatusType <Error>);
A G R E E M E N T
Hook Routines
Error code – Yes
ErrorHook
syntax: void ErrorHook(StatusType <Error>);
– – Yes
PreTaskHook
syntax: void PreTaskHook(void );
– – Yes
PostTaskHook
syntax: void PostTaskHook(void );
– – No
IdleLoopHook
syntax: void IdleLoopHook(void );
– – No
StartupHook
syntax: void StartupHook(void );
– – No
ShutdownHook
syntax: void ShutdownHook(void );
1. This service is not defined in the OSEK OS v.2.0 rev. 1 specification. This is an extension of OSEK OS.
2. Yes – for unqueued messages in WithCopy configuration only.
3. Yes – for unqueued messages in WithCopy configuration only, No – for queued messages.
The list of OSEK Operating System Data Types is provided here.
Table E-2. Data Types

Data Type Description
The data type for all status information the API services offer (see return values for OSEK OS
StatusType
services in Table E-4)
TaskType The abstract data type for task identification
TaskRefType The data type to refer variables of the TaskType data type

Quick Reference
System Services Quick Reference
R E Q U I R E D
Table E-2. Data Types
Data Type Description
TaskStateType The data type for variables to store the state of a task
TaskStateRefType The data type to refer variables of the TaskStateType data type
TaskControlBlockType The data type for task control block (task node)
TaskControlBlockRefType The data type to refer variables of the TaskControlBlockType data type
IntDescriptorType The data type for logical interrupt descriptors
IntDescriptorRefType The date type to refer variables of the IntDescriptorType data type
ResourceType The abstract data type for referencing a resource
A G R E E M E N T
EventMaskType The data type of the event mask
EventMaskRefType The data type to refer to an event mask
CtrRefType The data type references a counter
TickType The data type represents a counter value in system ticks
TickRefType The data type references data corresponding to the data type TickType
The data type represents a structure for storage of counter characteristics. This structure has
the following fields:
maxallowedvalue maximum possible allowed count value;
CtrInfoType
ticksperbase number of ticks required to reach a counter-specific significant unit;
mincycle minimum allowed number of ticks for a cyclic alarm (only for system with Extended
Status);
CtrInfoRefType The data type references data corresponding to the data type CtrInfoType
The data type represents a structure for storage of alarm characteristics. It is the same as
AlarmBaseType
CtrInfoType
AlarmBaseRefType The data type references data corresponding to the data type AlarmBaseType
AlarmType The data type represents an alarm element
AppModeType This data type represents the operating mode
SymbolicName An unique name representing a message
AccessName An unique name defining access to a message object
The brief list of OSEK Operating System Constructional elements is

provided below.
Table E-3. Constructional elements

Name Description
Serves as an external declaration of a task. The function and use of this service are similar to
DeclareTask that of the external declaration of variables
syntax: DeclareTask(TaskType <TaskId>)

Quick Reference
R E Q U I R E D
Table E-3. Constructional elements

Name Description
Serves as an external declaration of an event. The function and use of this service are similar to
DeclareEvent that of the external declaration of variables
syntax: DeclareEvent(EventMaskType <Event>)
Serves as an external declaration of a resource. The function and use of this service are similar
DeclareResource to that of the external declaration of variables
syntax: DeclareResource(ResourceType <ResId>)
Serves as an external declaration of an alarm element
DeclareAlarm
syntax: DeclareAlarm(AlarmType <AlarmId>)
A G R E E M E N T
Serves as an external declaration of a counter

DeclareCounter
syntax: DeclareCounter(CtrRefType <CounterId>)
Serves as an external declaration of an ISR. The function and use of this service are similar to
that of the external declaration of variables. This service is not defined in OSEK OS v.2.0
DeclareISR specification. This is an extension of OSEK OS.
syntax: DeclareISR(<ISRName>)
The table below contains all return values for OSEK Operating System
run-time services and error values.
Table E-4. OSEK Operating System run-time services return values and error values
Name Value Type
E_OK 0 No error, successful completion
E_OS_ACCESS 1 Access to the service/object denied

E_OS_CALLEVEL 2 Access to the service from the ISR is not permitted
E_OS_ID 3 The object ID is invalid
E_OS_LIMIT 4 The limit of services/objects exceeded
E_OS_NOFUNC 5 The object is not used, the service is rejected
E_OS_RESOURCE 6 The task still occupies the resource
E_OS_STATE 7 The state of the object is not correct for the required service
E_OS_VALUE 8 A value outside of the admissible limit
E_OS_SYS_STACK 10 Internal stack overflow
E_COM_BUSY 1 Message in use by application task/function
E_COM_ID 3 Invalid message name passed as parameter
E_COM_LIMIT 4 Overflow of FIFO associated with queued messages
E_COM_LOCKED 7 Rejected service call, message object locked due to a pending operation
E_COM_NOMSG 9 No message available

Quick Reference
OIL language Quick Reference
R E Q U I R E D
The following table contains OSEK Operating System constants with
short description.
Table E-5. OSEK Operating System constants

Constant Value Description
Constant of data type TaskStateType for task state
RUNNING 0
running
WAITING 1
waiting
READY 2
ready
A G R E E M E N T
SUSPENDED 3
suspended
Constant of data type TaskType for a not defined
INVALID_TASK (TaskType)–1
task
(ResourceType)0
If Resource = FALSE or
FastResource = FALSE in
configuration OIL-file Constant of data type ResourceType for Scheduler
RES_SCHEDULER
(ResourceType)–1 as a resource
If Resource = TRUE and
FastResource = TRUE in
configuration OIL-file
OSMAXALLOWEDVALUE Maximum possible allowed count value
OSTICKPERTIME Number of ticks that are required to reach 10
OSTICKSPERBASE milliseconds in the system timer
Number of ticks required to reach a counter-specific
OSTICKDURATION Depends on user’s settings
significant unit
in configuration OIL-file
Minimum allowed number of ticks for a cyclic alarm
OSMINCYCLE
(only for system with Extended Status)
INITIAL_INTERRUPT_
Initial interrupt level during system startup
DESCRIPTOR
E.3 OIL language Quick Reference

The lists of the all OIL object parameters with their possible values and
short descriptions are provided here. All standard object attributes must
be always defined. Motorola’s specific attributes can be defined in
addition to standard ones.
The value used by default typed by the boldface type in the Possible
Values cells.

Quick Reference
R E Q U I R E D
E.3.1 OS Object
The OS object is the mandatory one for any application. It defines OS

and its properties for the application. The OS object has the standard
and Motorola’s specific attributes. These attributes exactly corresponds
to the system options and are divided into parts which correspond to
appropriate system objects.
Table E-6. OS Parameters

Object Parameters Possible Values Description Notes
A G R E E M E N T
Standard Attributes
OSEK Conformance Class. Defines
general OS functionality and OS
behavior. However, most features of
BCC1, BCC2, the OS may be selected by means of BCC3 Conformance Class is
CC ECC1, ECC2, using other OS additional properties. also supported in Motorola OS
AUTO Therefore, even for given conformance v.1.0.
class the functionality may be reduced
or increased according to user’s
needs.
Scheduling Policy. Determines
whether OS supports non-preemptive
task only, preemptive task only, or
both. The preemptive scheduling
allows better timing for external events, In general, the task context
while it adds overhead for more often differs for preemptive and non-
NON, FULL,
SCHEDULE context switching. For application with preemptive tasks. Preemptive
MIXED, AUTO
all short tasks non-preemptive task context requires more stack

scheduling policy is recommended. It is space.
recommended do not use mixed
scheduling policy unless absolutely
necessary, because it increases code
size and timing.
As a general approach, it is
recommended to start
Defines whether additional run-time
application development with
error checks are supported by OS for
extended status to discover
STANDARD, OSEK API calls or not. The extended
STATUS configuration and run-time
EXTENDED status adds approximately 10% of
problems. For debugged
code, and increases timing
applications the status may be
accordingly.
set to standard to reduce code
size and advance timing.

Quick Reference
R E Q U I R E D
Defines that user’s-provided hook is
called after the operating system start-
up and before the scheduler is running.
Particular main() function should
This hook may be used by the
not be used for OS-dependent
application to perform hardware
initialization actions like task
StartupHook TRUE, FALSE initialization actions, task activations,
activation, alarm setting,
alarm setting, etc.
because at this time OS is not
The alternative way is to make such
running.
initialization steps in the task, which
starts automatically. The hook is called
with disabled interrupts.
A G R E E M E N T
Defines that user’s-provided hook is
called when the OS shutdown service This hook is called before
is performed. The main purpose of this system timer shutdown (if
hook is to shutdown initialized system timer is configured in the
ShutdownHook TRUE, FALSE
hardware devices like timers, network system). The status of interrupts
controllers, etc. Besides, the reason for is undefined, so it should be
shutdown may be obtained through the controlled by the user.
error code.
Defines that user’s-provided hook is It is not recommended to use
called from the scheduler code before this hook in normal working
the operating system enters context of applications, because it adds
the task. In general, this hook is significant timing overhead.
PreTaskHook TRUE, FALSE
designed for debugging applications by If defined, this hook is called for
means of tracing current task. This each task, i.e. it is not allowed to
hook is called within the task or use this hook for particular
interrupt service routine. task(s) only.
Defines that user’s-provided hook is It is not recommended to use
called from the scheduler code after this hook in normal working
the operating system leaves context of applications, because it adds
the task. In general, this hook is significant timing overhead.
PostTaskHook TRUE, FALSE
designed for debugging applications by If defined, this hook is called for
means of tracing current task. This each task, i.e. it is not allowed to
hook is called within the task or use this hook for particular
interrupt service routine. task(s) only.

Quick Reference
R E Q U I R E D

There is no need to check the
Defines that user’s-provided hook is error status of the each OS
called by the Operating System at the service call if this hook is used.
end of each system service which However, the mean of
returns a value not equal to E_OK. identifying source of error
This hook is designed for debugging should be implemented
applications by means of tracing error somehow in the application.
ErrorHook TRUE, FALSE code, returned by the system service This hook is useful as a
instead of checking error code after temporary feature of a working
each call of system service. This hook (debugged) applications when
A G R E E M E N T
increases the OS code with extended some troubles occur.

error status by approximately 11%, and If defined, this hook is called for
increase the timing in case of error each system service, i.e. it is not
during the service call. allowed to use this hook for
particular service(s) only.
Motorola’s Specific Attributes
This group of OS attributes represents system features which are
Global System Attributes
common for the whole system
OSEK OS version used. In general,
version 1.0 is supported for backward OS v.2.0 used by default. If the
compatibility only, and the support will portability of the application is an
be dropped from future releases of the issue, then it is recommended to
product. However, the implementation avoid usage of system services,
OSVERSION 1, 2 support services, which are defined in which are not defined in official
OSEK OS Specifications v1.0, but OSEK OS Specifications.
which are removed from OSEK OS To build application for OSEK
Specifications v2.0. For example, OS v1.0 Specs. this attribute
counters and message services may should be set equal 1.

still be used.
Target MCU type. This attribute Usually only one target may be
defines the core, for which the OS will used in the supplied code, but
be configured. this attribute should be defined
In addition, if a number of anyway, because some
microcontroller families is supported by additional checks are
HC08, HC12,
the OS, then the particular family will performed for each particular
TargetMCU CPU32, WINNT,
be defined during compilation/linking target.
MPC, MCORE
time by means of defining special It is highly recommended to use
identifier for the family (for example, sample makefile as a basis for
OSHC12A4 should be defined in the building application to provide
compiler command line if HC12A4 consistency in compiler/linker
family is a target). settings.
Specifies the ORTI support in OS. The
attribute can have values 0 or 1. If the
This attribute is only valid for
system has the DEBUG_LEVEL = 0
OSEK OS supporting ORTI (see
DEBUG_LEVEL 0, 1 the static ORTI support is switched off.
Section 18 ORTI
If the system has the DEBUG_LEVEL
Implementation for the details).
= 1 this mode is considered to be a
debugging mode.

Quick Reference
R E Q U I R E D
Specifies that the running task This attribute is only valid for
identification in run-time support will be OSEK OS supporting ORTI (see
ORTIRunningTask TRUE, FALSE
used. This attribute will be ignored if Section 18 ORTI
DEBUG_LEVEL = 0. Implementation for the details).
Specifies that the OSEK OS system This attribute is only valid for
calls identification in run-time support OSEK OS supporting ORTI (see
ORTICurrentService TRUE, FALSE
will be used. This attribute will be Section 18 ORTI
ignored if DEBUG_LEVEL = 0. Implementation for the details).
If there is no network, then this
attribute should be defined as
A G R E E M E N T
Defines whether the COM support is FALSE to avoid overhead,
NetworkCOM TRUE, FALSE
provided by OS or not. connected with communication
code.
FALSE by default.
Supported for HC08, HC12 for
base page (address range 00 16-
FF16), and for MPC (few general
registers are used to hold often
used OS variables). It is
Defines that OS system variables will
recommended to use base page
be allocated in the base page or in
for OS system variables, if there
non-volatile registers. Depending on
is enough space in it. In this
the OS configuration, the system
case, application should be
variables consume from several bytes
linked correctly to provide
HCBasePage TRUE, FALSE to several dozens of bytes in base
proper allocation of data in base
page. The code size is decreased by
page. It is highly recommended
approximately 5%, and timing is
to use sample makefile as a
improved accordingly, because
basis for using this attribute
addressing to base page usually takes
properly (in compiler/linker
less space and processor cycles.
settings).
However, some MCUs use base
page for input-output registers,
which prevents the using of it for
variables.
Defines that the support of Bank
Switching is used in the OSEK Supported for HC12 only. It is
OS. The microcontroller memory bank not recommended to use this
HCBankCode TRUE, FALSE hardware should be supported by the feature, if there is no need to
compiler. locate application into the
This is useful when memory banks are banked memory.
supported by the hardware.

Quick Reference
R E Q U I R E D

Defines that Alternative Register File
will be used for ISR processing. This Supported for MCORE only.
attribute is useful in case of numerous This attribute, if it is TRUE,
single-level interrupts most of which do requires vector table adjusting.
not cause task re-scheduling. Also it The low order bit of the
HCAltRegISR TRUE, FALSE
allows to avoid problem of using exception vector content must
variables inside ISR category 3, be 1 for every vector in the table
problem of nested interrupts for (except those ones that are not
MCORE and problem of using normal really used).
interrupt exceptions for MCORE.
A G R E E M E N T
Simplified scheduler is used. This

scheduler supports table of ready tasks
unlike convenient scheduler, which
supports list of ready tasks. The main
restriction of this type of scheduler is
that only one task per priority may be
It is highly recommended to use
used (i.e., each task should has unique
this type of scheduler, unless
priority), and, hence, OSEK resources
resources or/and several tasks
SimpleScheduler TRUE, FALSE are not allowed. Also task multiply
per priority and task multiply
activations are not supported.
activation are required in
However, the simplified scheduler
application.
requires less code, and runs much
faster. In spite, that the features,
provided by this type of scheduler, are
suitable for BCC1, it may be used in
any conformance class when the
conditions, mentioned above, are met.
If this attribute is set to TRUE, stack
It is recommended to use this

usage is reduced for system services,
feature, only if RAM
and, hence for tasks and ISRs. In this
requirements is an issue. In
case static memory area is used for
general, 20%–30% of task and
UseCommonArea TRUE, FALSE parameters and local variables of
ISR stack space is saved (see
system services. About 20 more bytes
Section 15 HC12 Platform-
are required in RAM to hold common
Specific Features for more
area, while code and timing is
information).
increased very slightly.
Specifies whether copyright notice
It is highly recommended always
CopyrightNotice TRUE, FALSE should be incorporated into OS ROM
have this attribute set to TRUE.
code or not.
This option allows to have a number of If it is not necessary to have a
different application modes (different number of different application
sets of tasks) in the same modes in the same application,
application.In this case it is possible to then it is recommended to turn
Reconfig TRUE, FALSE
change application mode after system this property off. It decreases
shutdown. If Reconfig is set to TRUE, the needed amount of RAM for
then Extended OIL format should be task identification and increases
used to define application modes. the speed.
Defines whether OS has to use CPU This attribute is intended for
UseMoveBlockInstruction TRUE, FALSE
memory move block instructions or not. MPC only.

Quick Reference
R E Q U I R E D
Low Power Related Attributes These OS attributes associate with support Low Power Mode
Defines that the MCU Low Power
Mode will be used instead of plain
forever no-operation when there is no
ready tasks, and scheduler goes into
idle loop. In general, it is recommended
Not supported for WINNT.
HCLowPower TRUE, FALSE to define this attribute to reduce power
consumption. However, the recovery
from the low power state to the normal
conditions (after interrupt) may take
A G R E E M E N T
more time, than recovery from normal
loop.
WAIT, DOZE, Supported for MPC and
STOP, Defines the particular Low Power MCORE only.
HCLowPowerMode
NORMAL, Mode used Applicable if HCLowPower =
SINGLE, SLEEP TRUE
Defines whether the IRQ[0:1] pin mask
HCLowPowerMask TRUE, FALSE is defined for Low Power exit logic or Supported for MPC only
not
Supported for MPC only.
Defines a mask for Low Power Exit
HCLowPowerMaskValue NONE, IRQ Applicable if HCLowPowerMask
logic
= TRUE
System Memory Related Attributes This group of OS attributes associates with system memory allocation
Specifies the number of task control
blocks (nodes), allocated in the
system. For every ready task separate
AUTO if undefined, and number
control block should be used, therefore
of nodes will be equal to the
this value should be big enough to
number of tasks, defined in
support all ready tasks. However, the
application. It is highly
same task control block may be used
NodeNumber integer recommended to set this value
by several tasks, if they are not
explicitly to avoid overhead
activated simultaneously. In general,
connected with consuming to
the task control blocks are assigned
much RAM for each task, which
dynamically to the task, when it is
are not run in the same time.
activated. In addition, several attributes
may be used to provide persistent link
between task and task control block.
AUTO if undefined.
Specifies the number of task priorities.
In spite, that system generator
In general, there is no relations
compacts the priority range, it is
between number of task control blocks
MaxPrio integer highly recommended to keep
unless SimpleScheduler attribute is
the priority range as small as
defined TRUE. In the last case these
possible. This will make
numbers should be equal.
debugging easy.

Quick Reference
R E Q U I R E D

Use the same stack for system start-
up, scheduler, and ISRs. If turned
FALSE, then separate stacks are used
It is recommended to define this
for system start-up code, for scheduler
attribute unless there is special
idle loop, and for interrupt service
requirements to stack locations.
routines. In this case, the user may
However, the size of the stack
fully control the size and location of
should be controlled by user -
UseMainStack TRUE, FALSE stack areas by means of using
usually by means of using linker
attributes, described below. However,
directives. The size of stack
the RAM requirements may be
should be big enough to hold
A G R E E M E N T
reduced if all these stacks are

interrupt stack frames for the
combined in the same memory area.
nested interrupts.
As a side effect, the code size is
slightly decreased, because stack
switching is simplified.
Scheduler stack size in bytes. This
stack is mainly used when scheduler
goes into idle loop, when there is no Ignored if
SchedStackSize integer
ready tasks. This stack should be big UseMainStack=TRUE.
enough to hold interrupt stack frame
and several additional bytes.
Scheduler stack address. This
Ignored if
parameter may be used, if there is a
UseMainStack=TRUE.
need to allocate scheduler stack in
If this parameter is set, then
SchedStackAddress string particular memory section. (For
proper linking directives should
example, internal MCU RAM may be
be used to locate stack area at
used instead of external RAM to
particular memory address.
provide better timing).
ISR Stack Size. The stack is used

when interrupt service routine calls
system service. In this case the current
Ignored if
status of the processor is saved onto
IsrStackSize integer UseMainStack=TRUE.
the current stack, and stack is switched
to the interrupt stack. This stack should
be big enough to hold all nested
interrupt stack frames in the system.
ISR Stack Address. This parameter
Ignored if
may be used, if there is a need to
UseMainStack=TRUE.
allocate ISR stack in particular memory
If this parameter is set, then
IsrStackAddress string section. (For example, internal MCU
proper linking directives should
RAM may be used instead of external
be used to locate stack area at
RAM to provide better timing or power
particular memory address.
consumption).

Quick Reference
R E Q U I R E D
Defines the support of task control AUTO if undefined.
block stacks in the operating system It is highly recommended to set
code. If this parameter is set to FALSE, this parameter to FALSE, if task
NodeStack TRUE, FALSE some another stack mechanism (stack control block stacks are not
pool, static stack) should be configured used by no one task. This way,
to protect the system from crash due to both code size as well as RAM
lack of stack. consumption will be decreased.
Specifies the size of the stack (in
bytes) per each task control block. In
Ignored if
general, each task control block has its
NodeStack = FALSE.
A G R E E M E N T
own stack with fixed size. Therefore,
If any task control block may be
the simplest way is to define this
NodeStackSize integer used by any task, this parameter
attribute, and use task control block
should be big enough to satisfy
stack for ready tasks. However, the
requirements of the task, which
memory consumption is not optimized
comsumes biggest stack.
in this case, because every task may
have different stack requirements.
Specifies the bottom of task control
block stacks. This parameter may be Ignored if
used, if there is a need to allocate task NodeStack = FALSE.
NodeStackAddress string control blocks stack array in particular The task control block stack
memory section. (For example, to area is allocated as continuous
utilizes different areas of the RAM in block of memory.
the microcontroller memory map).
Clears outstanding reservations
This attribute is supported for
ClearReservation TRUE, FALSE between processes.
MPC only.
Task Related Attributes This group of OS attributes controls task feature
The FALSE attribute disables task
multiple activation. This feature is
Valid only if
useful, if there is a need to have an
CC = BCC2, ECC2;
extended conformance class, but to
AUTO if undefined.
exclude multiple activation of the tasks.
MultiplyActivation TRUE, FALSE It is highly recommended to
In this case the attribute decreases
define this attribute unless
code size, and task control block size,
multiple activation is required in
as well as eliminates some variables,
the application.
connected with tracking of order of task
activations.

Quick Reference
R E Q U I R E D

If this attribute is defined, then the
intermediate vector of the pointers to
It is recommended to set this
the task control blocks for each task in
attribute to TRUE, if more than 8
the system is used to track the status
tasks are configured in the
of the task (activated or suspended).
system, and there is a lot of task
TaskIndexMethod TRUE, FALSE Therefore, fast and deterministic
activations.
access to task control blocks is
However, this attribute should
provided. However, more RAM space
be set to FALSE, if
is required to hold the intermediate
SimpleScheduler= TRUE.
vector of pointers (one pointer for each
A G R E E M E N T
task, configured in the application).

Defines whether stack pools are
supported or not. The stack pools are
useful when different set of tasks has
different requirements for the stacks. In
this case, the stack of needed size will
AUTO if undefined.
be allocated for the task during the run-
Because the configuration of the
time. The distribution of the stack pools
stack pools is rather
StackPool TRUE, FALSE should be performed by the application
complicated task, therefore
developer. The tasks are to be grouped
these pools are recommended
by the stack size required, stack pool
for experienced users.
for particular size should created, and
then the number of stacks in each pool
should be defined by means of
calculating a number of tasks in each
group activated at the same time.
When set to TRUE, allows persistent
task control block allocation. The
persistent task control block is the

AUTO if undefined.
control block, which is explicitly
The distribution of the persistent
assigned (allocated) to the task. This
task control blocks is rather
persistent task control block improves
PersistentNode TRUE, FALSE complicated task, therefore
the timing, because no run-time
these pools are recommended
allocating/freeing of task node is
for experienced users.
required. However, the persistent task
control block can not be used by any
other task in application, even when
the task is suspended.

Quick Reference
R E Q U I R E D
When set to TRUE, allows persistent
task stack allocation. The persistent
task stack is the stack from the stack
pool, which is explicitly assigned
AUTO if undefined.
(allocated) to the task. This persistent
The distribution of the persistent
task stack improves the timing,
stacks is rather complicated
because no run-time allocating/freeing
PersistentStack TRUE, FALSE task, therefore these pools are
of task stack is required. However, the
recommended for experienced
persistent stack can not be used by
users.
any other task in application, even
when the task is suspended. The task
A G R E E M E N T
stack may be made persistent for the
task, only if this task has persistent
task node.
AUTO if undefined.
In spite, that same memory area
may be used by several tasks, if
When set to TRUE, allows the explicit only one of them is activated in
task stack allocation. The explicit task the given time, it is
stack is a static memory area, which is recommended to avoid such
used by the task for stack. This feature configurations.
TaskOwnStack TRUE, FALSE improves the timing, because no The own stack of the task is the
dynamic operations are involved into easiest way to watch the stack
the task activating/terminating. status, because it is absolutely
However, the stack memory area can clear where the stack is located.
not be used for any other tasks. Therefore, it is recommended to
use this feature if there are
troubles, connected with the
stack overflow.
Defines whether the some run-time
context frame is used both for non-
Valid only if
preemptive and preemptive tasks.
SCHEDULE=MIXED.
When set to TRUE, decreases code
It is highly recommended to set
UseSameContext TRUE, FALSE size and improves timing. However,
this attribute to TRUE. This
more stack is required for non-
simplifies debugging of the
preemptive task context, because
application.
preemptive context is used for any
task.

Quick Reference
R E Q U I R E D

Supported for HC08, HC12 for
base page (address range
0016–FF16). It is recommended
to use base page for task control
block, if there is enough space
If TRUE, the task control blocks are
in it. In this case, application
allocated into the base page memory.
should be linked correctly to
It increases the system performance
provide proper allocation of data
since CPU accesses the base page is
in base page. It is highly
faster than to the extended memory. In
recommended to use sample
addition, code size is decreased.
A G R E E M E N T
TaskBasePage TRUE, FALSE makefile as a basis for using this

However, because base page has
attribute properly (in
limited size, and may be used for
compiler/linker settings).
application needs, the amount of
However, some MCUs use base
memory, required to hold all task
page for input-output registers,
control blocks, should be estimated
which prevents the using of it for
beforehand.
variables.
This attribute is completely
independent from HCBasePage
attribute, and any combinations
of them may be used.
It is highly recommended to set
This parameter may be set to FALSE if
this parameter to TRUE unless
ChainTaskItself TRUE, FALSE there is no tasks that chain itself. It
there are tasks which chain
decreases the task control block size.
itself.
Extended Task Context Related Attributes This group of OS attributes controls task context extension
Defines whether OS has to support
task context extension or not. Valid

only if the target MCU has the Supported for MPC, CPU32,
ExtendedContext TRUE, FALSE
corresponding hardware support, or HC08 only.
some virtual compiler registers are to
be included into task context.
Specifies the number of extended Supported for MPC, CPU32
NonPreemptCtxRegNum integer registers included into non-preemptive only.
task context. Valid only if ExtendedContext =
TRUE.
These parameters allow
experienced user to optimize
task context depending on the
Specifies the number of extended application code and compiler
PreemptCtxRegNum integer registers included into preemptive task behavior. It these parameters
context. are not used and
ExtendedContext = TRUE, then
task context contains all
extended registers.

Quick Reference
R E Q U I R E D
Specifies the assembler macro for
saving extended registers into non-
preemptive task context. It should be a
SaveNonPreemptCtxExt string
STRING which contains inline
assembler statements for saving
extended registers
Specifies the assembler macro for Supported for CPU32 only.
restoring extended registers from non- Valid only if ExtendedContext =
preemptive task context. It should be a TRUE.
RestoreNonPreemptCtxExt string These parameters allow
experienced user to optimize
A G R E E M E N T
assembler statements for restoring
extended registers task context depending on the
application code and compiler
Specifies the assembler macro for behavior. It these parameters
saving extended registers into are not used and
preemptive task context. It should be a ExtendedContext = TRUE, then
SavePreemptCtxExt string
STRING which contains inline task context contains all
assembler statements for saving extended registers.
extended registers
restoring extended registers from
preemptive task context. It should be a
RestorePreemptCtxExt string
assembler statements for restoring
extended registers
Interrupt Related Properties This group of OS attributes defines parameters of ISR execution
If no ISR which call system
service are used in the
Defines whether OS provides ISR
application, it is recommended
support or not. In general, this attribute
to set this attribute to FALSE.
EntryExitISR TRUE, FALSE should be set to TRUE, if the
This will decrease the code size
application has interrupt service
and will improve timing, because
routines, which call system service.
no interrupt-level checks are
performed in the system.
Specifies whether the ISR of category
ISRCategory1 TRUE, FALSE 1 is supported by OS or not. Currently
this attribute does not affect OS code.
ISRCategory2 TRUE, FALSE 2 is supported by OS or not. Currently
this attribute does not affect OS code.
ISRCategory3 TRUE, FALSE
3 is supported by OS or not.

Quick Reference
R E Q U I R E D

Defines whether OS provides the
Interrupt Mask Control or not. If this
attribute is set to TRUE, the user is
allowed to use interrupt descriptor The full control of interrupt
manipulation services. Besides, the status is designed for
system always tracks the status of processors having complex
interrupts during the system service interrupt masks (like HC16 or
execution. That means, that application CPU32). It is highly
has full control on the interrupt status. recommended to set this
For example, the task may disable attribute to FALSE for
A G R E E M E N T
InterruptMaskControl TRUE, FALSE interrupts, call system service, and processors which have rather
interrupts will be disabled when service simple interrupt system (like
will be completed. When this HC08 or HC12).
parameter is set to FALSE, interrupts It should be double checked,
will be re-enabled in this scenario after that all interrupt masks
system service completion. In (including interrupts masks for
addition, no interrupt descriptor each task) are defined properly
manipulation services are allowed. if this attribute is set to TRUE.
When this attribute is set to TRUE,
code size and timing is significantly
increased.
Specifies the value of Interrupt mask
DisableInterruptMask integer which corresponds to all interrupts Valid only if
disabled. InterruptMaskControl=TRUE.
Specifies the value of Interrupt mask The exact value for the
EnableInterruptMask integer which corresponds to all interrupts particular platform is described
enabled in other section of this manual.
As a general rule, the bit
Specifies the value of Interrupt mask position in these mask should

which corresponds to the middle level correspond to the interrupt(s)
TaskLevelMask integer
of enabled interrupts for tasks in the bits in CPU conditional code or
system flags registers with value one
Specifies the value of Interrupt mask represented enable state, and
which corresponds to the initial level of value zero represented disable
InitialMask integer state.
enabled interrupts during the system
start-up

Quick Reference
R E Q U I R E D
Specifies the number of extended
registers to be saved into ISR stack
ISRCtxRegNum integer
frame. It should contain value from 1 till Intended for MPC505 only, not
18 implemented yet.
Valid only if ExtendedContext =
TRUE.
saving extended registers into ISR
These parameters allow
stack frame. It should be a STRING
SaveISRCtxExt string experienced user to optimize
which contains inline assembler
ISR context depending on the
statements for saving extended
application code and compiler
registers
behavior. If these parameters
A G R E E M E N T
Specifies the assembler macro for are not used and
restoring extended registers from ISR ExtendedContext = TRUE, then
stack frame. It should be a STRING ISR stack frame contains all
RestoreISRCtxExt string
which contains inline assembler extended registers.
statements for restoring extended
registers
This attribute is intended for
UnorderedExceptions TRUE, FALSE Allow unordered exception handling.
MPC only.
Resources and Events Related Attributes These OS attributes control resources and events
Defines whether event management is
provided by OS or not. Set this
attribute to be FALSE to exclude event AUTO if undefined.
Events TRUE, FALSE
support. If the attribute is set as FALSE
then no event services will be available
in the application
Defines whether resource
management is provided by OS or not.
Set this attribute to be FALSE to
AUTO if undefined.
Resources TRUE, FALSE exclude resource support. If the
attribute is set as FALSE then no
resource services will be available in
the application.
This option is strongly
recommended only for
Defines whether fast resources are
debugged applications, because
FastResource TRUE, FALSE provided by OS or not. If it is TRUE the
errors related to incorrect
system will work faster.
access and priority are not
signaled to the application.
If system has STANDARD
Defines whether E_OS_ACCESS error
status or FastResource
code is returned by GetResource
property turned on or more than
service or not. If it is TRUE, then error
ResourceAccessCheck TRUE, FALSE 8 resources (including
code will be returned in EXTENDED
Scheduler) are defined in
status based on task definition in OIL-
application, then this property
file.
should be set to FALSE.
Counters and Alarms Related Attributes This group of OS attributes controls counters and alarms features

Quick Reference
R E Q U I R E D

exclude alarm support. If the
attribute is set as FALSE then
no counter connected services
Defines whether counters are
Counters TRUE, FALSE will be available in the
provided by OS or not.
application.
The system timer is not
supported if this attribute is set
to FALSE.
It is highly recommended to use
A G R E E M E N T
minimal counter size in the

application to decrease code
size and improve timing. In
general, 8-bits counters should
Defines the size of all counters. The
be used for 8-bits CPUs (like
valid values are 8, 16 and 32 which
CounterSize 8, 16, 32 HC08), 16-bits counters should
conform to byte, word and long word
be used for 16-bits CPUs (like
size of counters.
HC12), while 32-bits counters
may be used in CPU32, MPC
and MCORE.
This size is defined for all
counters in the application.
exclude alarm support. If the
Defines whether alarms are supported
Alarms TRUE, FALSE attribute is set as FALSE then
by OS or not.
no alarm services will be
available in the application.
The list of alarms improves

timing of alarms operation,
If the attribute is TRUE the running especially if dozen of alarms are
alarms are linked into a list which used in the system. However,
decreases the time for alarm handling. list of alarms requires much
AlarmList TRUE, FALSE
If this attribute and AlarmDeltaList more memory than table of
attribute are FALSE, table of alarms is alarms to support lists. The
used. setting of this attribute should be
balanced between timing and
memory requirements.

Quick Reference
R E Q U I R E D
The delta-list of alarms improves
timing of CounterTrigger()
service, especially if dozen of
alarms are connected to the
same counter. However, delta-
If the attribute is TRUE the running list of alarms requires much
alarms are linked into a ordered alarm more memory than table of
delta-list which decreases the time for alarms to support lists also
CounterTrigger() service if too much timing of alarm management
AlarmDeltaList TRUE, FALSE
alarms are connected to the same services like SetAbsAlarm(),
counter. If this attribute and AlarmList SetRelAlarm() and GetAlarm()
A G R E E M E N T
attribute are FALSE, table of alarms is will be increased. The setting of
used. this attribute should be balanced
between timing and memory
requirements.
Only one of the options
AlarmList and AlarmDeltaList
may be used in the application.
When FALSE no one alarm may
be cyclic (this decreases RAM
usage for alarm control blocks
Defines whether alarms are supported
CyclicAlarm TRUE, FALSE and for task stacks, as well as
by OS or not.
decreases code usage and
advances timing of alarms
services).
When FALSE alarm handling is
optimized for speed. When
turned on, the alarm control
block is significantly decreased,
Defines whether the alarm handling is
MinAlarmRAM TRUE, FALSE because most information is
optimized for memory (RAM) or not.
stored into ROM. This
decreasing is especially
significant when AlarmList
attribute is set to FALSE.
These are additional OS attributes to tune the selected hardware interrupt
System Timer Related Attributes
source
Valid only if interrupt related
Defines whether the System Timer is
SysTimer TRUE, FALSE services are supported by OS,
provided by OS or not.
i.e. if EntryExitISR = TRUE.

Quick Reference
R E Q U I R E D

TIMTOI, TIMOC0,
TIMOC1,
TIMOC2,
TIMOC3,
TIMOC4,
TIMOC5,
TIMOC6,
TIMOC7,
TIMATOI,
TIMAOC0,
A G R E E M E N T
TIMAOC1, This attribute is intended to select the

This parameter can not be
TIMAOC2, hardware interrupt source for the
TimerHardware omitted, if system timer is
TIMAOC3, system counter (among the accessible
defined (except OSEK OS/NT).
TIMBTOI, MCU devices)
TIMBOC0,
TIMBOC1, RTI,
PIT, DEC, MDC,
CTM4S1FCSM,
CTM4S1MCSM2,
CTM4S1MCSM11,
CTM4S2FCSM,
CTM4S2MCSM2,
CTM4S2MCSM11,
NTTIMER1
Defines if the Prescaler is to be set for
Prescaler TRUE, FALSE
the selected System Timer hardware.
Defines the Prescaler setting for the The value of this attribute is fully
PrescalerValue integer
selected System Timer hardware. hardware-dependent.
Defines if the Modulo is to be set for

TimerModulo TRUE, FALSE
the selected System Timer hardware.
Defines the Modulo setting for the The value of this attribute is fully
TimerModuloValue integer
selected System Timer hardware. hardware-dependent.
Messages Related Attributes These are additional OS attributes to control local messages
If the attribute is set to be
Set this attribute as FALSE to exclude
FALSE then all Unqueued
UnqueuedMessages TRUE, FALSE Unqueued Messages support for the
Message related services will be
system.
unavailable in the application.
AUTO if undefined.
Set this attribute as TRUE to allow If the attribute is set to be
UnqueuedMsgDefaultValue TRUE, FALSE Unqueued Messages to have default FALSE then Ungueued
values. Messages will not be able to
have default values.
If the attribute is set to be
FALSE then all Queued
QueuedMessages TRUE, FALSE Queued Messages support in the
Message related services will be
system.

Quick Reference
R E Q U I R E D
AUTO if undefined.
Set this attribute as FALSE to exclude If the attribute is set to be
QueuedMessageOneToN TRUE, FALSE 1:N Queued Messages support in the FALSE then 1:N Queued
system. Messages are not supported for
the application.
If the attribute is TRUE then the task
ActivateOnMsg TRUE, FALSE activation on message arrival is AUTO if undefined.
supported for the application.
If the attribute is TRUE then the alarm
notification on message arrival is
A G R E E M E N T
AlarmOnMsg TRUE, FALSE AUTO if undefined.
supported for the application (an alarm
can be linked to message arrival).
If the attribute is TRUE then the event
notification on message arrival is
SetEventOnMsg TRUE, FALSE AUTO if undefined.
supported for the application (an event
setting is allowed on message arrival).
Hook Routines Related Attribute This OS attribute defines additional hook routines support in the system
Internal error handler is used to
catch fatal errors of the
Defines whether the internal error
InternalErrorHandler TRUE, FALSE operating system. The error
handler is implemented in OS or not.
hook is called independently of
this parameter setting.
This hook is intended for
Defines that user’s-provided hook is manipulation with hardware
called by the Operating System from registers (like COP).
IdleLoopHook TRUE, FALSE
scheduler idle loop (when there are no It is not possible to call any
tasks in ready state). OSEK OS directives from this
hook.
The attribute defines entry point of the
UserCommand1 string user's command hook #1 to be called
from the OS Dispatcher thread. Supported for OS/NT with
interrupt emulation only.
The attribute defines entry point of the
It is possible to call Windows
library functions from this hooks.
from the OS Dispatcher thread.
Special mechanism to invoke
The attribute defines entry point of the hooks should be used.
from the OS Dispatcher thread.
The group of attributes is designed to exclude particular OS services. If an
attribute is FALSE the corresponding service is excluded from the OS
OS Service Related Attributes
code. Names of these attributes are the same as corresponding OS
service names

Quick Reference
R E Q U I R E D

ShutdownOS TRUE, FALSE Set this attribute as FALSE to exclude
code supporting the corresponding OS
service. This will decrease the total OS Exclude Execution Control
GetActiveApplicationMode TRUE, FALSE code size. If the attribute is set to be services.
FALSE then the service will be
ActivateTask TRUE, FALSE
TerminateTask TRUE, FALSE Set this attribute as FALSE to exclude
ChainTask TRUE, FALSE
A G R E E M E N T
service. This will decrease the total OS

Schedule TRUE, FALSE code size. If the attribute is set to be Exclude Task services.
GetTaskId TRUE, FALSE
GetTaskState TRUE, FALSE
GetTCBInfo2 TRUE, FALSE
GetResource TRUE, FALSE Set this attribute as FALSE to exclude
ReleaseResource TRUE, FALSE
service. This will decrease the total OS Exclude Resource
GetScheduler TRUE, FALSE code size. If the attribute is set to be services.
ReleaseScheduler TRUE, FALSE unavailable in the application.
SetEvent TRUE, FALSE Set this attribute as FALSE to exclude
ClearEvent TRUE, FALSE
service. This will decrease the total OS Exclude Event
GetEvent TRUE, FALSE code size. If the attribute is set to be services.
WaitEvent TRUE, FALSE unavailable in the application.

EnterISR TRUE, FALSE
LeaveISR TRUE, FALSE code supporting the corresponding OS
EnableInterrupt TRUE, FALSE Exclude ISR services.
code size. If the attribute is set to be
DisableInterrupt TRUE, FALSE FALSE then the service will be
GetInterruptDecsriptor TRUE, FALSE
InitCounter TRUE, FALSE
CounterTrigger TRUE, FALSE code supporting the corresponding OS
service. This will decrease the total OS Exclude Counter
AdvanceCounter2 TRUE, FALSE
code size. If the attribute is set to be services.
GetCounterValue TRUE, FALSE FALSE then the service will be
GetCounterInfo TRUE, FALSE

Quick Reference
R E Q U I R E D
SetRelAlarm TRUE, FALSE
SetAbsAlarm TRUE, FALSE code supporting the corresponding OS
service. This will decrease the total OS Exclude Alarm
CancelAlarm TRUE, FALSE
code size. If the attribute is set to be services.
GetAlarm TRUE, FALSE FALSE then the service will be
GetAlarmBase TRUE, FALSE
SendMessage TRUE, FALSE
ReceiveMessage TRUE, FALSE code supporting the corresponding OS
A G R E E M E N T
GetMessageResource TRUE, FALSE Exclude Messaging services.
code size. If the attribute is set to be
ReleaseMessageResource TRUE, FALSE FALSE then the service will be
GetMessageStatus TRUE, FALSE
1. NTTIMER may be omitted for OSEK OS/NT.
E.3.2 TASK Object
Parameters of this object type define task properties. The TASK object
has the standard and Motorola’s specific attributes and references.
Table E-7. TASK Parameters

Standard Attributes
Defines the priority of the task.
The higher task priority In the Motorola’s implementation
PRIORITY integer
corresponds to the higher value range is [0...255]
PRIORITY value
TYPE BASIC, EXTENDED Defines the task type
Defines the run-time behavior of
SCHEDULE FULL, NON
the task
Defines whether the task is
AUTOSTART TRUE, FALSE activated during the system
start-up procedure or not
The maximum number of
The value range is [1...255]
ACTIVATION integer registered activation requests
for the task

Quick Reference
R E Q U I R E D

Defines the memory bank for
the task code. It should be
MemoryBank integer
defined only if memory banking
is used
Defines the starting task’s If this parameter is omitted, then
InterruptMask integer
interrupt mask OS TaskLevelMask value is used
If the attribute is set as TRUE a
PersistentNode TRUE, FALSE persistent task node is assigned
to the task
A G R E E M E N T
NODESTACK - stack is assigned

statically in the Node Stack
NODESTACK, system area. POOLSTACK - stack
Specifies the stack allocation
StackMethod POOLSTACK, is assigned dynamically in the
method for the task
OWNSTACK pointed stack pool. OWNSTACK -
stack is explicitly assigned by the
user
Defines the size of the task
Shall be defined only when the
stack in bytes. It depends on the
STACKSIZE integer StackMethod value is
CPU family and functionality of
OWNSTACK
the task
Motorola’s Specific Attribute
Task stack address. This
parameter may be used, if there Valid
is a need to allocate task own ifStackMethod=OWNSTACK.
stack in particular memory If this parameter is set, then
StackAddress string
section. (For example, internal proper linking directives should be

MCU RAM may be used instead used to locate stack area at
of external RAM to provide particular memory address.
better timing).
If the attribute is set as TRUE a
Valid if StackMethod =
PersistentStack TRUE, FALSE persistent stack buffer is
POOLSTACK
assigned to the task
Standard References
RESOURCE names of RESOURCEs Resources accessed by task
EVENT names of EVENTs Events owned by the task
Motorola’s Specific References
Reference to messages which
MESSAGESENT names of MESSAGEs
are sent by the task
MESSAGERECEIVED names of MESSAGEs
are consumed by the task

Quick Reference
R E Q U I R E D
If a task uses the stack from a
stack pool the reference to the
StackPool name of STACK dedicated stack pool must be
provided. The symbolic name of
the stack pool shall be pointed
E.3.3 ISR Object
This object represents an Interrupt Service Routine. Parameters of this
A G R E E M E N T
object type define ISR properties. The ISR object has the standard
attributes and references.
Table E-8. ISR Parameters

Standard Attribute
In OSEK OS three categories of
CATEGORY 1, 2, 3 ISR are considered depending on
system services used
Chooses the type of ISR. ISR can
Supported for MCORE only,
TYPE FAST, NORMAL be launched by Fast Interrupt
HCAltRegISR shall be TRUE
exception or normal exception
Motorola’s Specific Reference
MESSAGESENT names of MESSAGEs
are sent by ISR
E.3.4 STACK Object
The STACK object defines physical parameters of a stack pool This

object is Motorola’s specific object and it has no standard attributes.
Table E-9. STACK Parameters

Object
Possible Values Description Notes
Parameters
Represents the size of a single stack
StackSize integer
buffer
Defines the number of stack buffers in the
NumberOfStacks integer
pool

Quick Reference
R E Q U I R E D
Table E-9. STACK Parameters

Object
Possible Values Description Notes
Parameters
Specifies the start address of the pool
memory area. This optional parameter
StackAreaAddress string
serves for explicit memory allocation for
the task stack pool
E.3.5 RESOURCE Object
The RESOURCE object is intended for the resource management. This

A G R E E M E N T
object has no standard attributes and references.
Table E-10. RESOURCE Parameters

Defines the resource priority. The
PRIORITY integer higher value corresponds to the AUTO if undefined
higher priority
E.3.6 ALARM Object
This object presents OS alarms. The ALARM object has the standard
attributes and references.
Table E-11. ALARM Parameters

Standard Attribute
Defines which type of task
ACTIVATETASK,
ACTION notification is used when the
SETEVENT
alarm expires
Standard References
Points to a particular counter to
COUNTER name of COUNTER
have an ability to operate
Points to a task which is to be
TASK name of TASK notified via activation or event
setting when the alarm expires
The event is considered as an
inseparable pair of the task and
Point to an event which is to be the event belonging to this task,
EVENT name of EVENT
set when the alarm expires so the reference to the task which
owns the events shall be also
defined for this alarm

Quick Reference
R E Q U I R E D
E.3.7 COUNTER Object
Attributes of this object type define counter properties. A COUNTER

object has no references, it is referenced to by other object. The
COUNTER object has the standard and Motorola’s specific attributes.
Table E-12. COUNTER Parameters

Standard Attributes
Defines the maximum allowed counter
MAXALLOWEDVALUE integer
value
A G R E E M E N T
Specifies the minimum allowed
MINCYCLE integer number of counter ticks for a cyclic
alarm linked to the counter
Specifies the number of ticks required
TICKSPERBASE integer
to reach a counter-specific value
By default this attribute
has the value FALSE.
Specifies whether the counter is the Note, however, that only
SystemTimer TRUE, FALSE
system timer one counter must be
defined as the system
timer
Shall be defined for
Specifies duration of a tick of the
TICKDURATION integer system counter only
system counter in nanoseconds
E.3.8 MESSAGE Object
Parameters of this object type define message properties. The

MESSAGE object has the Motorola’s specific parameters at the
moment. Some of them are proposed to be standard attributes. By
convention the parameters of this object can be divided into two groups:
standard and Motorola’s specific parameters.
Table E-13. MESSAGE Parameters

Standard Attributes
Queued message data is buffered and
UNQUEUEDMESSAGE, consumed by receive operations.
TYPE
QUEUEDMESSAGE Unqueued message data is not con-
sumed and overwritten each time

Quick Reference
R E Q U I R E D
Table E-13. MESSAGE Parameters

ITEMTYPE is the C data type of the
ITEMTYPE string message item. Define any ANSI-C type-
specifier
The number of items has a sense only
ITEMS integer for Queued message, Unqueued mes-
sage always has only one item
Assigned alarm will be restarted with the
Valid if ALARMRESET
ALARMRESETTIME integer specified time period at the message
reference is defined
arrival
A G R E E M E N T
ACTIVATETASK, Defines which type of task notification is

ACTION
SETEVENT, NONE used when the message arrives
Defines the number of local task-receiv-
ers of the message. If it has a value
ReceiverNum integer greater than 1, then it is assumed, that
several tasks may receive a message
item from the Message queue
Specifies whether the alarm referenced
by the message must be restarted during
StartupAlarm TRUE, FALSE system start-up or not (default). Alarm
restarting is used to trap the loss of the
first message
Presents the address of the ROM-based
Intended for unqueued
variable, which holds the default value of
messages only.
DefaultValue string the Unqueued message. This variable
The attribute may be

must have the type <ITEMTYPE>, and
omitted
must be located in the user’s code
Standard References
Assigned alarm will be restarted with
ALARMRESET name of ALARM defined time period at the message
arrival
Task activation or event setting can be
TASK name of TASK used to inform the specified task at mes-
sage arrival
The event is considered
as an inseparable pair of
the task and the event
Event signaling can be used to inform belonging to this task, so
EVENT name of EVENT
the specified task at message arrival the reference to the task
which owns the events
shall be also defined for
this message

Quick Reference
R E Q U I R E D
E.3.9 EVENT Object
The EVENT object is intended for the event management. This object
has no references.
Table E-14. EVENT Parameters

Standard Attribute
MASK integer Represents the event AUTO if undefined
A G R E E M E N T

Quick Reference
R E Q U I R E D
A G R E E M E N T

R E Q U I R E D
Index
A event 105
ALARM 163, 348 Extended OIL version 135
ACTION 163 Extended Status 37, 125, 127, 193
COUNTER 163 Extended Task 32, 41
A G R E E M E N T
EVENT 164
TASK 163 F
alarm 97 fatal errors 126
Application configuration file 134
Application Modes 168
H
hook routines 121
B
Basic Task 32, 43
BCC1 33 I
BCC2 33 Interrupt Service Routine (ISR) 73
interrupt stack frame 75
ISR 167, 347
C CATEGORY 167
Ceiling Priority 87 MESSAGESENT 167
CFG 168 TYPE 167
CFGACTIVE 168 ISR frame 73
Conformance Class 32
conversion constant 94
COUNTER 162, 349 M
MAXALLOWEDVALUE 162 MESSAGE 164, 349
MINCYCLE 162 ACTION 164
SystemTimer 163 ALARMRESET 166
TICKDURATION 162 ALARMRESETTIME 165
TICKSPERBASE 162 DefaultValue 166
CPU 138 EVENT 166
ITEMS 165
ITEMTYPE 165
E ReceiverNum 166
ECC1 33 StartupAlarm 165
ECC2 33 TASK 166
EVENT 161, 351 TYPE 165
MASK 161 WithCopy 166
MOTOROLA Index 353

Index
R E Q U I R E D
Message Objects (MO) 111 GetMessageStatus 156

mild errors 126 GetResource 155
multiple activation 34, 44 GetTaskId 155
GetTaskState 155
O GetTCBInfo 155
HCAltRegISR 143
OIL 134
HCBankCode 143
ORTI 269
HCBasePage 143
OS 142, 326
HCLowPower 144
ActivateOnMsg 153
HCLowPowerMode 144
ActivateTask 155
IdleLoopHook 154
AdvanceCounter 155
A G R E E M E N T
InitCounter 155
AlarmDeltaList 152
InitialMask 150
AlarmList 152
InternalErrorHandler 154
AlarmOnMsg 154
InterruptMaskControl 145
Alarms 152
ISRCategory1 150
CancelAlarm 156
ISRCategory2 150
CC 143
ISRCategory3 150
ChainTask 155
ISRCtxRegNum 150
ChainTaskItself 148, 155
IsrStackAddress 149
ClearEvent 155
IsrStackSize 149
CopyrightNotice 146
LeaveISR 155
Counters 152
MaxPrio 145
CounterSize 152
MinAlarmRAM 153
CounterTrigger 155
MultiplyActivation 147
CyclicAlarm 152
NodeNumber 145
DisableInterrupt 155
NodeStack 147
DisableInterruptMask 150
NodeStackAddress 146
EnableInterrupt 155
NodeStackSize 145
EnableInterruptMask 150
NonPreemptCtxRegNum 148
EnterISR 155
OSVERSION 142
EntryExitISR 145
PersistentNode 148
ErrorHook 154
PersistentStack 148
Events 152
PostTaskHook 154
ExtendedContext 147
PreemptCtxRegNum 149
FastResource 151
Prescaler 153
GetActiveApplicationMode 156
PrescalerValue 153
GetAlarm 156
PreTaskHook 154
GetAlarmBase 156
QueuedMessages 153
GetCounterInfo 155
QueuedMsgOneToN 153
GetCounterValue 155
ReceiveMessage 156
GetEvent 155
Reconfig 146
GetInterruptDecsriptor 155
ReleaseMessageResource 156
GetMessageResource 156
354 Index MOTOROLA

Index
R E Q U I R E D
ReleaseResource 155 UseSameContext 148
ResourceAccessCheck 151 WaitEvent 155
Resources 151 OSEK 21
RestoreISRCtxExt 151 OSEK Implementation Language 134
RestoreNonPreemptCtxExt 149 OSEK Run Time Interface 269
RestorePreemptCtxExt 149 OSShutDown 126
SaveISRCtxExt 150
SaveNonPreemptCtxExt 148 P
SavePreemptCtxExt 149
Priority Ceiling Protocol 87
SchedStackAddress 145
SchedStackSize 145
SCHEDULE 147 Q
A G R E E M E N T
Schedule 155 Queued Messages 111
SendMessage 156
SetAbsAlarm 156 R
SetEvent 155
ready state 41, 43
SetEventOnMsg 154
RESOURCE 160, 348
SetRelAlarm 156
PRIORITY 161
ShutdownHook 154
run time context 40
ShutdownOS 156
running state 41, 43
SimpleScheduler 144
StackPool 148
StartupHook 154 S
STATUS 144 scheduler 39, 65
SysTimer 153 simplified scheduler 66
TargetMCU 142 single activation 44
TaskBasePage 148 STACK 159, 347
TaskIndexMethod 147 NumberOfStacks 160
TaskLevelMask 150 StackAreaAddress 160
TaskOwnStack 148 StackSize 160
TerminateTask 155 Stack Errors 195
TimerHardware 153 Standard OIL version 135
TimerModulo 153 Start-up Routine 128
TimerModuloValue 153 System Generator 36
UnorderedExceptions 151 System Generator utility (SG) 133
UnqueuedMessages 153 system timer 95
UnqueuedMsgDefaultValue 153
UseCommonArea 146 T
UseMainStack 144
TASK 156, 345
UseMoveBlockInstruction 147
ACTIVATION 157
UserCommand1 155
AUTOSTART 157
UserCommand2 155
EVENT 159
UserCommand3 155
InterruptMask 158
MOTOROLA Index 355

Index
R E Q U I R E D
MemoryBank 158
MESSAGERECEIVED 159
MESSAGESENT 159
PersistentNode 158
PersistentStack 158
PRIORITY 157
RESOURCE 159
SCHEDULE 157
StackMethod 157
StackPool 159
STACKSIZE 157
A G R E E M E N T
TYPE 156
task configuration table 40
task control block 51
task node 40
U
Unqueued Messages 111
W
waiting state 32, 105
356 Index MOTOROLA

HC12 Os

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

HC12 Os

Încărcat de

Drepturi de autor:

Formate disponibile

OSEK Operating System

Motorola reserves the right to make changes without further notice to

Copyright © 1999 Motorola, Inc. All Rights Reserved

User’s Manual MC68HC(7)05H12 — Rev. 1.2

Copyright © 1999 Motorola, Inc. All Rights Reserved

No part of this publication may be reproduced or transmitted in any form

Permission is granted to reproduce and transmit the Problem Report

IMPORTANT NOTICE TO USERS

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Legal Notices 3

Microsoft, MS-DOS and Windows are trademarks of Microsoft.

UNIX is a trademark of AT&T Bell Laboratories.

User’s Manual OSEK Operating System — Rev 1.2

4 Legal Notices MOTOROLA

Section 3. Operating System Architecture

Section 4. Task Management

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Table of Contents 5

4.6 Task Priorities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.7.5.2 Persistent Stack Allocation from the Stack Pool . . . . . . . 57

Section 6. Interrupt Processing

User’s Manual OSEK Operating System — Rev 1.2

6 Table of Contents MOTOROLA

Section 7. Resource Management

Section 8. Counters and Alarms

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Table of Contents 7

8.5.3 Counters and Alarm Generation . . . . . . . . . . . . . . . . . . . .101

9.4.1 Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . .108

Section 10. Communication

10.5 Programming Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .116

Section 11. Error Handling and Special Routines

User’s Manual OSEK Operating System — Rev 1.2

8 Table of Contents MOTOROLA

Section 12. System Configuration

Section 13. System Objects Definition

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Table of Contents 9

13.4 Task Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .156

13.8 Counter Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .161

Section 14. Building of Application

Section 15. HC12 Platform-Specific Features

User’s Manual OSEK Operating System — Rev 1.2

10 Table of Contents MOTOROLA

Section 16. Application Troubleshooting

Section 17. System Services

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Table of Contents 11

17.3.4 Task Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .200

17.4 ISR Management Services . . . . . . . . . . . . . . . . . . . . . . . . . . .210

17.5.3 Resource Declaration . . . . . . . . . . . . . . . . . . . . . . . . . . . .221

User’s Manual OSEK Operating System — Rev 1.2

12 Table of Contents MOTOROLA

Section 18. ORTI Implementation

OSEK Operating System — Rev 1.2 User’s Manual

MOTOROLA Table of Contents 13

18.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .269

Appendix A. Sample Application

A.1 Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .279

Appendix B. System Service Timing

Appendix C. Memory Requirements

C.3 Data Sheet for the Cosmic . . . . . . . . . . . . . . . . . . . . . . . . . . .292