Presentation Tricore

PXROS-HR for TriCore
The safety platform for embedded systems
Author: Mario Cupelli
HighTec EDV-Systeme
Feldmannstrae 98
D-66119 Saarbr
ucken
HighTec EDV-Systeme GmbH

c 2011 PXROS-HR for TriCore 1/113
Introduction Initialization Tasks Communication Object Id
1 Introduction
Tasks and Handlers
Object Management in PXROS-HR
Time and Memory Management
Scheduling
2 Initialization
3 Tasks
Tasks
Access rights
Memory Protection of TriCore
4 Communication
Messages
Examples
Events
5 Object Id

Meaning
PXROS-HR means
P ortable
e X tendible
R ealtime
O perating
S ystem
-
H igh
R eliabilty

Realtime
Definition
A system can be called realtime, if its correctness is not solely subject to
the output values it creates, but also to the times when these output
values are available.

Soft vs. Hard Realtime
Soft realtime
Violation of time requirements for part of the events is tolerable
In case of deviations from defined deadlines, the result can still be
correct and may be processed.
Hard realtime
Violation of time requirement leads to unusable results or damage
In systems that are subject to hard realtime, the meeting of deadlines
has to be guaranteed; individual deadlines must not be missed.

PXROS Basic Concepts I
Conceived as an object-based multitasking operating system over 20

years ago
No interrupt locks and latencies
Evidence for meeting time requirements
Allocation of resources
Time
Memory
Objects

PXROS Basic Concepts II
Encapsulation
Model concept: tasks run on different processors
Tasks have their own independent resources
Error in one task does not affect the whole system
Communication between tasks only per messages and events
Tasks have client/server relations

PXROS-HR Concepts
PXROS-HR
Implements a safe environment to execute any applications
The basic concept for avoiding the propagation of errors is to

encapsulate the data and to strictly control the resources
An application component should only access data which are
necessary to perform its task
The component should only use assigned resources (memory, CPU
time)
Communication between two components should only be based on
object transfer including access permissions

PXROS-HR Concepts
Using shared memory is prohibited

Semaphores and similar synchronisation and communication
mechanisms are not allowed in safety environments
Synchronisation should only be used if absolutely necessary
The basic communication principle should be asynchronous
Asynchronous communication permits an easy implementation of
redundant systems

Features of PXROS-HR
TriCores Memory protection

PXROS-HR uses the TriCore protection mechanism to implement a
hardware controlled separation of task address spaces
Hardware requirements
Distinction between privileged and non-privileged modes
The highest privileged mode (supervisor mode) is reserved for the
PXROS-HR kernel
All tasks are executed in a less privileged mode (User-0 and User-1)
Memory protection mechanism with small granularity
The TriCore protection registers allow protection of memory areas of
any size

Features of PXROS-HR
System functions are called by the SVC interface which allows

implicit mode switching
Each task can only access memory which lies within its address
space. Every access to memory beyond this address space will be
detected and can be handled by the protection trap
Only the message mechanism can be used to transfer data between
tasks. Only the actual user of a message has access to the contents
of the message
The message mechanism explicitly transfers the memory from one
address space to another

Tasks and Handlers
Tasks
Have their own address space
Act as independent modules which process complex subprograms
Are arranged by priorities
Handlers
Act as interrupt service routines
Can be activated by hardware or software events
Interrupt tasks and operating system functions.

PXROS is object-based
Objects are converted from general, unused standard objects to
special objects
Objects can only be modified by PXROS functions
Modification is only possible if access to the object is available
Number of objects remains constant

Legende
Standardobjekt
Objektpool
Mailbox
Nachrichtenobjekt / Message
Delay-Job
Speicherklasse / Memory Class

Procedure
Request an object from PXROS
Use the special object
Release to operating system
Available as general object again

Time Management
PXROS time management services

Software timer (delay job)
Timeout events
Periodical events
PXROS smallest time unit: ticks
Each call to PxTickDefine_Hnd defines a tick
PxTickDefine_Hnd is called by a periodical timer interrupt
The time passing at each tick can be flexibly set by the user

Memory Management
Memory Classes
PXROS manages the working memory by means of memory classes
Different classes are possible for different parts of the application
A task can request memory from PXROS

Resource Allocation as the Primary Objective
Occurring errors only have local impact

Due to allocation, resource shortages can be locally limited within
tasks or subsystems

Scheduling Procedures I
Definition
Scheduling means a strategy for allocating a shared resource to the
concurrent processes within a realtime system.
Several tasks are to be processed simultaneously

The processor can never process different code at one time
Tasks must be processed successively
Scheduling decides which task is to be processed at any given time
Targets
Meeting realtime requirements
Optimal utilisation of the processor

Scheduling Procedures II
Non-superseding scheduling
The active task occupies the processor until the processor is
voluntarily released by the task
Superseding scheduling
Tasks can be interrupted
The time of interruption is not predictable
The processor state must be saved

Scheduling Procedures III
Non priority-based superseding scheduling

Superseding is effected without prioritisation of processes
Example: Time slice
The task may occupy the processor for a predefined period of
time
Priority-based superseding scheduling

Process with the highest priority is executed
Priority can be assigned statically or dynamically
Tasks with equal priority can not interrupt each other

Priority scheme
Handler
Handlers have always a higher
priority than tasks
Task
The task priority controls the
scheduling behaviour

Initialization
PXROS-HR has to be initialzed by the function PxInit ()

No PXROS service is available before PxInit ()
The PXROS system specifiation is given to PxInit () as parameter
PxInit creates:
System memory class
System object pool
Objects
Initial task
PxInit () never returns, the init task is scheduled and started in user
mode

Initialization
If some hardware specific initialization has to be done in supervisor mode,

before PXROS is started, you may use the macro
_PxInitcall ( function , parms ...) . All these functions are collected in
the section . pxinit and are executed before PXROS is initialized.
Example:
static void __enable_asc ( void )
{
/* Enable ASCx */
ASC0_CLC . reg = 1 << A S C 0 _ C L C _ R M C _ S H I F T ;
return ;
}
_PxInitcall ( __enable_asc );

Initialization workflow
The application starts in supervisor mode, so all necessary initialization

has to take place, before PxInit is called:
int main ( void ) {
PxError_t error ;
I n i t H a r d w a r e I n S u p e r v i s o r ();
error = PxInit (& InitSpec );

if ( error != PXERR_NOERROR )
{
PxPanic ();
return 1;
}
return 0;
}

PxInit () schedules the first task in the system, the so called InitTask,
which runs in user 0 or user 1 mode. In this task the other tasks of the
system are created and started:
static void InitTask_Func ( PxTask_t myID , PxMbx_t myMailbox , PxEvents_t m y A c t i v a t i o n E v e n t s )
{
/* Start PXROS time base with HZ ( defined in clock . h ) ticks per second . */
TicksInit (1000);
/* Install Errorfunction */
P xS et Me s sa ge F un ( errmsg );
/* Initialize the name server */

NameSrv = PxNamesrvInit ( NAMESRV_PRIO , ( PxAligned_t *) PxNameServerSpaceBase , PxNameServerSpaceEnd - P
if ( PxTaskIdError ( NameSrv ) != PXERR_NOERROR )
PxPanic ();
NameSrvMbx = PxTaskGetMbx ( NameSrv );
TcpIpTaskId = TcpIpStart ();

if (! P xT as k Id Is Va l id ( TcpIpTaskId ))
PxPanic ();
LedServer_Id = PxTaskCreate ( PXOpoolTaskdefault , & LedServer_Spec , LEDSERVER_PRIO , L E D S E R V E R _ A C T I V A T I O

if ( PxTaskIdError ( LedServer_Id ) != PXERR_NOERROR )
PxPanic ();
_mbx = PxTaskGetMbx ( LedServer_Id );
if ( PxNameR egister ( LedServerMbx_NAMESERVERID , sizeof ( PxMbx_t ) , & _mbx ) != PXERR_NOERROR )
PxPanic ();

Having created and activated all other tasks the InitTask typically
reduces its priority to the lowest and runs an endless loop to keep the
controller busy, if no other task is ready:
PxTaskSetPrio ( PxGetId () , MINPRIO );
while (1)
{
;
}
Alternatively, the task may call PxAwaitEvents(0) to remove itself from

scheduling:
PxTaskSetPrio ( PxGetId () , MINPRIO );
PxAwaitEvents (0);
In the first case you see in a PXVIEW recording how long the initask
became busy.

PXROS Tasks
Independent subsystem
Can wait for 32 events
Has its own mailbox
Program code runs in an infinite loop
Has its own stack and local variables
Is separated from other tasks by encapsulation
Has its own protected address space
Tasks have a unique ID/reference

PXROS Tasks

PXROS Tasks
Separation of hardware-dependent and hardware-independent

components
Separation of time-critical and non time-critical tasks
Priorisation of PXROS tasks
Task can be utilised as a reusable component

typical tasks
tasks
Control (high priority)
Monitoring
Communication
Evaluation and background checks (low priority)

Task States
States
waiting awaits events and messages
ready is ready and awaits activation
active is processed
Condition for task switches

Task of higher priority with ready
state supersedes current task or
Present task switches into waiting
state

Task Function
The function of the task will be executed sequentially

The function will be assigned to the task during task creation
Execution of the function will start, when task is activated for the
first time
The function never returns
The prototype of a task function
void TaskFunc (PxTask_t ,PxMbx_t ,PxEvents_t)

Task Creation
Defining the task properties e.g.

Task function
Priority
Stacksize
protected address space
Call PxTaskCreate

Access rights I
One of the main task properties are the tasks access rights:
PXACCESS_HANDLERS
The right to execute PxHndcalls and install interrupt
handlers with system priveleges
PXACCESS_INSTALL_HANDLERS
The right to install interrupt handlers which are executed
as PXROS handlers like delay jobs and normal interrupts
PXACCESS_INSTALL_SERVICES
The right to install PXROS services as handlers

Access rights II
PXACCESS_REGISTERS
The right to execute system functions with access to
special core registers
PXACCESS_SYSTEMDEFAULT
The right to allocate from the system default resources
PXMcSystemdefault and PXOpoolSystemdefault
PXACCESS_SYSTEM_CONTROL
The right to execute special system function like
PxTaskSuspend which can influence the system behaviour

Access rights III
PXACCESS_RESOURCES
The right to access resources which are not owned by the
task itself.
PXACCESS_NEW_RESOURCES
The right to define new resources

Protection Registers I
Memory Protection
Encapsulate components using (2 code and 4 data) protection registers
in supervisor and user mode.
Each protection register configures
upper bound
lower bound
control (read, write, execute)
TriCore offers hardware based memory protection.

Protection Registers II
When a task is created, 2 data protection register pairs are defined:

The tasks read-only area
The tasks data area
The other 2 data protection register pairs are used dynamically (e.g. for
messages).

Protection Registers III
It is possible to create additional protected areas for a task, e.g. for the
memory of an external device:
static const P x P r o t e c t R e g i o n _ T D i s p l a y T a s k R e g i o n s [] = {
{( PxUInt_t ) DISPLAY_MEMORY_START , ( PxUInt_t ) DISPLAY_MEMORY_END , WRProtection } ,
{0 , 0 , 0};
};
...
. ts_protect_region = DisplayTaskRegions ,

Memory Protection Unit

Privilege modes
Supervisor
Access to: all on-chip peripherals, external
peripheral devices, core SFR.
User-1
Access to: non protected on-chip peripherals
and external peripheral devices.
User-0
No access to: peripheral devices and core SFR.


Privilege modes
Supervisor
User-1
User-0


Privilege modes
Supervisor
User-1
User-0

Encapsulation concept of PXROS-HR
Each component (PXROS task) has its

own protection register context
PXROS-HR manages the switching of
memory protection of components
An access violation leads to an error
handling, e.g. the component is suspended
stack overflow can be detected.





Support of protection mechanism in PXROS-HR
Add protection areas to a task

The memory protection areas of the task are defined at task creation
time.
Detect, evaluate and inspect error

If a protection trap occurs, the trap handler checks if the trap address is
covered by an other protection area. In this case the protection registers
are changed temporarily and the trapped task can continue execution.

Communication Mechanisms
Exchange of Messages
Data exchange between tasks is done by sending messsages to
mailboxes
Messages must be allocated or received before they can be used
Mailboxes can never overflow
Signalling Events
Reporting status changes
Events are signalled and stored for each task
Transmission from task to task or
From handler to task
A task can await messages and events simultaneously

Messages
Messages are used to exchange data

Data can be of any size
Messages can be used as often as desired
Content is protected

Messages
Only the task which currently uses the message has read/write
access to the content
Messages are either stored in mailboxes or used by tasks
The owner of a message can set write protection for the content

Mailbox
Mailboxes can contain an arbitrary number of messages

Task sends messages to a mailbox
Task receives messages from a mailbox
Mailbox is organised as a FIFO
Prioritised messages are possible
Every task owns a private mailbox

Mailbox

Model
Explanatory Model with paper and envelope:

Paper corresponds to transmission data
Paper is put into envelope (message)
Envelope is sent, and then put in recipients mailbox
Recipient takes letters sequentially out of mailbox
Recipient opens envelope and reads contained data
If the size of the paper stays the same (A4, A5), the envelope can
be used again

Message Management
Messages are objects requested from PXROS

Messages must be returned after use
Task may process messages only after request or receipt
Once sent or returned, a message can no longer be used by the task

Message Design
Messages are defined by their properties:

Owner
User
Data
When the message is sent, PXROS
changes these properties

Requesting Messages
Two ways to request a message:

PxMsgRequest() requests a message object and the associated
memory
Corresponds to: requesting envelope and paper
PxMsgEnvelop() requests a message object but no memory
Corresponds to: requesting envelope only, paper is already at hand
Memory for the message has to be provided by the task
The memory is bound to the message
Access is only possible for the owning task

Receiving Messages
ReceiveMsg
Task always receives messages from a
SendMsg
PxMsgReceive
mailbox
PxMsgRequest
Mailbox can be the private mailbox of the
PxMsgGetData
liefert Zeiger
auf Datenbereich task, or a general, public mailbox
PxMsgGetData
liefert Zeiger
auf Datenbereich
Daten auslesen
When message is received, authorisation
und auswerten
Nachrichtendaten
ausfllen
for access to data in message must be
Datenbereich neu
ausf.llen
PxMsgRelease
obtained
PxMsgSend
Task can await messages and events
PxMsgSend
simultaneously at the mailbox
After use, always release message or pass
on

Characteristics
Access to message content by PxMsgGetData. The message area is

added to the protection area of the calling task
The access to the message content is always released by
PxMsgSend
PxMsgRelease
PxMsgRelDataAccess.
The message data area is released from the protection area of the
calling task

Messages - Procedure I
Request message with data block

msg = PxMsgRequest ( sizeof ( Data ) , sized sizeof (Data) bytes
PXMcTaskdefault ,
P X O p o o l T a s k d e f a u l t );
Request access to the data area of
data = ( char *) PxMsgGetData ( msg );
the message
data - > content = 42;
Write data area
msg = PxMsgSend ( msg , PxTaskGetMbx ( Task2Id ));
Send message to private mailbox of
Task2

Messages - Procedure II
Receive message from myMbx

msg = PxMsgReceive ( myMbx );
mailbox
data = ( char *) PxMsgGetData ( msg );
if ( data - > content == 42) {

Request access to the data area of
}
...
the message
msg = PxMsgRelease ( msg ); Analyse message data
Return message to PXROS

Restricting access to message data
It is possible to restrict the access to message data for other tasks:

Hide the data begin by moving the data pointer with
PxMsgSetData()
Resize the message data with PxMsgSetSize()

Mailbox handler
Mailbox handler are special handler assigned to a mailbox

The handler is activated, when a message is stored in the mailbox
There is exactly one handler installed for a mailbox
The handler can react on normal, prioritized or all messages

Message Pools
Message pools
You may use a mailbox as a message pool to ensure the availability of
messages.
Request some messages with the same size

Install message pool as release mailbox for the messages
Send these messages to the message pool mailbox
Receive messages from the message pool to use them

Example Messages
Description
PXROS message exchange
I/O server and client
Asynchronous communication

Example Messages
Task1
Client for I/O server
Infinite loop
Assigns output to Task2
Task2
I/O server
Infinite loop
Awaits jobs at mailbox and processes them

Events
Each task can have up to 32 events

Event is represented by a corresponding bit of the PxEvents_t type
Each event has two states: occurred / not occurred
Meaning of the events can be freely defined
No resources necessary for events
Events 28 to 31 are reserved for PXROS enhancements (e.g. PxTcp)
Handlers cannot receive events

Events
Events are used for signalling states, e.g.

Timeout
Message received
Job finished
Task can wait for the arrival of events
When waiting for events, a mask can be set, which represents the
events to wait for
When a set of events was read, the events are automatically reset
Event number is often named by a #define

Events - Procedure
P xT as k Si g n a l E v e n t s ( Task2ID , EVENT_1 ); Signal EVENT_1 to Task2

events = PxAwaitEvents ( EVENT_2 | EVENT_3 );
if ( events & EVENT_2 ) {
Await EVENT_2 or EVENT_3
...
} If EVENT_2 is received, then
action

Object Ids
Object Ids are handles of PXROS objects

each PXROS object class has his own access functions
Object Ids should only be manipulated by this access functions

Object Id functions for messages
return an invalid Msg handle for initialization

PxMsg_t PxMsgIdInvalidate(void);
return TRUE if Msg holds a valid Msg handle
int PxMsgIdIsValid(PxMsg_t Msg);
return the last error of the object handle Msg
PxError_t PxMsgIdError(PxMsg_t Msg);
reset the last error of the object handle Msg
PxError_t PxMsgIdResetError(PxMsg_t Msg);
return the object ID of the object handle Msg
PxObjId_t PxMsgIdGet(PxMsg_t Msg);
return an Msg handle which object ID id
PxMsg_t PxMsgIdSet(PxObjId_t id);

Time Management Object Management Handlers Name Server Access to peripheral registers
6 Time Management
Delay Job
Timeouts
Periodical Events
Examples
7 Object Management
Object Management
8 Handlers
Handlers
Installing handlers
9 Name Server
10 Access to peripheral registers

Time Management
PXROS time management services

Software timer (delay job)
Timeout events
Periodical events
PXROS smallest time unit: ticks
Each call to PxTickDefine_Hnd defines a tick
PxTickDefine_Hnd is called by a periodical timer interrupt
The time passing during each tick can be flexibly set by the user

Time Management

Delay Job
PxDelayRequest
PxDelaySched(t=100)
Request delay object / alarm
Scheduler plans delay job
Abbrechen?
Sonstige Aktionen PxDelaySched(0)

Einplanen des
Delayauftrages
Delay job starts
Processing user-defined function
Processing function once

Delayauftrag Delayauftrag
lschen starten
For periodical functions

schedule delay job again
PxTaskSignalEvents_Hnd(task1)
Signal an event to the task

Delete delay job
PxDelayRelease
Task 1 PXROS Kernel Delay Handler

Example - Description
Description
PXROS event mechanism
Two tasks sending messages to each other
Task 1
Infinite loop
Signals event EV_MESSAGE to Task2 ten times and awaits event
EV_MESSAGE
Awaits event EV_CONTINUE

Timeouts
PxToInit(100,EV_TO)
Initialise with timeout in PXROS ticks

PxToStart
Start timer
Task waits for the timeout event
PxAwaitEvent(EV_TO)A
After timeout, PXROS kernel send event
T=100 Ticks
Task awakes from event
PXROS- Aktion
Task can delete or restart timeout job
Events can be triggered after a predefined period
of time
PxToClear
A task can only create events for itself
Task PXROS- Kernel

Periodical Events
Periodical events have Pe instead of To extensions

Apart from this, the procedure is the same as with timeouts
Events are triggered periodically

Example Timeout - Description
Description
PXROS event mechanism
Two tasks sending messages to each other
Using timeout services
Task 1
Infinite loop
Signals event EV_MESSAGE to Task2 ten times and awaits event
EV_MESSAGE
Awaits event EV_CONTINUE

Example Timeout - Description
Task 2
Infinite loop
Waits 1 second at most for event EV_MESSAGE
If EV_MESSAGE is received, it is passed on to Task1
If waiting period has expired, signal EV_CONTINUE to Task1

Example Periodic Event
Description
PXROS message exchange
I/O server and client for I/O server
Asynchronous communication
Task2 starts periodical event handler and creates appropriate output
Task1
Client for I/O server
Infinite loop
Assigns output to Task2

Example Periodic Event
Task2
I/O server
Infinite loop
Awaits jobs at mailbox and processes them

Object Management
PXROS is strictly object-oriented

PXROS possesses a certain number of general objects
When an object is requested from PXROS, a general object is
converted into a special object
An object pool from where the general object is to be taken, must
be given with the request

Object Pools
Objects are held in object pools

Object pools contain general objects
A default object pool with a fixed number of objects is generated
during system initialisation
Object pools are themselves objects
There are two types of object pools:
Real object pools
Virtual object pools

Encapsulation by Object Pools
A system can run having only one object pool

Problem: if a critical task needs an object, the object pool may be
emptied by other tasks
Solutions: individual object pools for critical tasks
Guarantees a maximal number of usable objects

Virtual and Real Object Pools
Real object pools

Objects exist as real objects within the object pool
With the creation of the object pool, the objects are immediately
needed and assigned
Objects are extracted from source object pools
Virtual object pools

Request objects from source object pool if required
An object pool can be source for several virtual object pools
The sum of objects in virtual object pools can be larger than the
number of objects in the source object pool

Real and Virtual Object Pool
Realer Objektpool
Virtueller Objektpool

Object Pools - Procedure
A new virtual object pool opool is

created
Three objects from the tasks
opool = PxOp oolReque st ( PXOpoolVirtual ,
3,
default object pool are inserted into
PXOpoolTaskdefault ,
P X O p o o l S y s t e m d e f a u l t );
this object pool
The general object which is
transferred to the new object pool,
is taken from the system default
object pool

Handlers
Handlers can handle hardware or software interrupts

Handlers can be inserted directly into the interrupt vector table of
the processor
Dynamical installation of interrupt handlers by C functions
Handlers have no context and thus no memory
Asynchronous activation by internal or external interrupts
Processor context is destroyed
Used resources must be saved and restored

Fast interrupt handler
Fast interrupt handler are executed in supervisor mode on interrupt

level
Are installed with
PxIntInstallFastHandler (PxUInt_t intno, void ( inthandler )(PxArg_t),
Installing Task needs access right PXACCESS_HANDLERS

Normal interrupt handler
Normal interrupt handler are executed in the context of the

requesting task
Is executed like a software interrupt handler
Are installed with
PxIntInstallHandler (PxUInt_t intno, PxInterrupt_t intObj , void ( intha
Installing Task needs access right
PXACCESS_INSTALL_HANDLERS
Needs an interrupt object required with PxInterruptRequest()

PXROS-HR services
Some PXROS-HR services may be installed as an interrupt handler

The service is executed in supervisor mode on interrupt level
Are installed with
PxIntInstallService (PxUInt_t intno, PxUInt_t service , PxArg_t arg, PxE
Installing Task needs access right
PXACCESS_INSTALL_SERVICES
Service may be one of
PxTickDefine IntHnd SvNo
PxTaskSignalEvents IntHnd SvNo
PxTaskSchedRemproc IntHnd SvNo
PxTaskSchedRemhnd IntHnd SvNo

Name Server
The Name Server stores any data with a unique ID

The unique IDs have the format n.n.n.n wherein n is any number
between 0 and 255
The namespace 1.n.n.n is reserved for the basic system
The Name Server supports register and query of any data
The Name Server is accessible from every Task
The Name Server may be used to interchange data to avoid the use
of global variables

Types and Services
Types
typedef union {
unsigned char part [4];
unsigned int id ;
} PxNameId_t;
Services
Register Data at the Name Server
PxError_t PxNameRegister(PxNameId_t, PxSize_t, void const )
Change the registered data
PxError_t PxNameReRegister(PxNameId_t, PxSize_t, void const )
Query the registered data
PxError_t PxNameQuery(PxNameId_t, PxSize_t, void , PxSize_t )

Access to peripheral registers
User-1 mode tasks may access peripheral registers directly

User-0 mode tasks may not access peripheral registers directly
They have to use PXROS-HR functions:
PxRegisterRead
PxRegisterWrite
PxRegisterSetMask
To use these function, the task has to have the access right
PXACCESS_REGISTERS
The address ranges of the peripheral register has to be set in the
extended protection areas of the task

Error handling MPU trap handling PxMonitor Porting an existing PXROS application to PXROS-HR PXview
11 Error handling
12 MPU trap handling
13 PxMonitor
14 Porting an existing PXROS application to PXROS-HR
15 PXview

Error handling
There are several ways how PXROS signals the occurrance of an error:
The object identifier contains an error value.
A PXROS function returns an error of type PxError_t
A PXROS error code is stored in the tasks context
The function PxRegisterRead for example returns the content of the
given register or 0 if the task has no right to access the register. But
this function may return a 0 as register content.
In this case, a call of PxGetError() returns the last PXROS error code
PxSetError() clears this value.

Error function
If PXROS detects a severe error situation (e.g. Task calls a handler

function), an error function is called
This function is PxMessageFunDefault() by default
This error function may be overwritten by the application with
PxSetMessageFun(function)
This function has 5 parameters:
PxMessageClass_t severity
PxError_t errno
3 error specific arguments
If the severity is greater than PXWarning the system may be insecure
The function PxPanic() activates a software reset

MPU trap handling
The MPU trap handling consists of 3 steps:

The PXROS-HR internal trap handling
An user defined MPU trap handler
A software reset

Internal MPU trap handler
The internal MPU trap hander

Determines the address, where the MPU trap happened
Checks if the task has access to the address, because the address is
part of
A message the task has in use
One of its additional protection areas
In this case the trap handler changes TriCores protection registers
And returns to the trap address, where the task can continue its
execution

user defined MPU trap handler
The user defined MPU trap hander

Has to be installed with PxTrapInstallHandler ()
Obtains 5 parameters:
The trap number (MPU trap no = 1)
The trap indication number TIN
An user defineable argument
The id of the trapped task
The tasks CSA
Decides, which action has to take place:
Determine the trapped task
Shutting down the whole system
Other application dependent action

Example for an user defined MPU trap handler
Installing an user defined MPU trap handler

...
P x T r a p I n s t a l l H a n d l e r (1 , MyTrapHandler , PxTaskIdGet ( myid ));
...
An user defined MPU trap handler

PxBool_t MyTrapHandler ( PxUInt_t trapno , PxUInt_t tin , PxUInt_t arg , PxUInt_t id , TC_CSA_t * csa )
{
PxTask_t MyId = ( PxTask_t ) arg ;
if ( MyId == id )
// I caused the trap -> severe error !
PxPanic ();
if ( id == N o t I m p o r t a n t T a s k I d )
{
P x T a s k S u s p e n d _ P x h n d ( id );
P x T a s k S i g n a l E v e n t _ H n d ( MyId , E V _ K I L L _ T H E _ N O T _ I M P O R T A N T _ T A S K )
return true ;
}
// We could not solve the problem , let the trap handler force a software reset
return false ;
}

PxMonitor
PxMonitor is a special task, which can be started with PxMonitorInitTcp.

This task provides:
Memory space for the program code and data of a reloaded task.
A virtual object pool for this task with 20 objects.
An environment to communicate with an external debugger to
Download the task
Debug the task (setting breakpoints, examining variables, ...)
Terminate the task from the debugger

PxMonitor benefits
PxMonitor may be used to

Test new software components without affecting the existing system
Run systematical tests in a reloaded task
Load application specific subsystems depending on the existing
configuration (e.g. additional functionality for user specific parts of a
system)
The reloaded task can exchange communication data like mailbox ids via
the nameserver and can interact with the base system sending messages
to these mailboxes.

Shared libraries
Reloaded tasks use shared libraries for PXROS-HR or PXTCP calls.

These libraries make it unnecessary to link the whole libraries.
Their names are
libpxconn.a
libpxtcpclnt.a

Migrating from PXROS to PXROS-HR
Steps
Change PXROS calls and structures
Assign data to tasks
Use nameserver for former global data used by several tasks
Separate task into own projects / libraries
Use the MPU
Set tasks to user 0 mode, where possible
Restrict access rights
Encapsulate remaining global data

PXROS vs. PXROS-HR
PXROS
Object ids are pointer to system memory
Most functions return an error code
Tasks do not need special rights to use PXROS services
Task-global data stored in common data area
Global data used by different tasks
PXROS-HR
Object ids are an index to internal tables plus an error code
Most functions return an object identifier
Task need appropriate access rights to use some PXROS-HR features
Task-global data stored in task specific data area
Global data may not be used by different tasks
System and task specification structure changed significantly

In PXROS-HR task specific global data like task stack, other task
ids or mailboxes, are collected into an own data area
Thie data area is assigned to the task by the linker description file
In the task specification the base and end address of this area are
entered into a task context structure
PXROS-HR sets the appropriate MPU register pair to these values
to prevent task access beyond these borders

Example
# pragma section . L e d S e r v e r _ d a t a _ b e g i n 4 aw
static int L e d S e r v e r _ d a t a _ b a s e [0];
# pragma section
...
PxUInt_t GlobalVar ;
...
# pragma section . L e d S e r v e r _ d a t a _ e n d 4 aw
static int L e d S e r v e r _ d a t a _ e n d [0];
# pragma section
static const P xT as kC o nt ex t _T L e d S e r v e r _ C o n t e x t =
{
. protection [0] = // read only area inherited by creator
{
. lowerBound = 0 ,
. upperBound = 0 ,
. prot = N o A c c e s s P r o t e c t i o n
},
. protection [1] =
{
. lowerBound = ( PxUInt_t ) LedServer_data_base ,
. upperBound = ( PxUInt_t ) LedServer_data_end ,
. prot = WRProtection
}
};
const PxTaskSpec_T L edServe r_Spec =
{
...
. ts_context = & LedServer_Context ,
...
};

PXROS without nameserver
In PXROS application it was useful to import task ids or mailbox ids

from other task:
CreatorTask:
PxTask_t PartnerId ;
PxMbx_t Par tnerMai lbox ;
...
Err = PxTaskCreate (& PartnerId , ...);
PartnerMail box = PxTaskGetMbx ( PartnerId );
...
UserTask:
extern PxTask_t PartnerId ;
extern PxMbx_t PartnerM ailbox ;
...
P x T a s k Si g n a l E v e n t s ( PartnerId , EV_WAKEUP );
Err = PxMsgSend (& Msg , Pa rtnerMai lbox );
...

In PXROS-HR application it is not possible for the UserTask to access

CreatorTasks address space, so the tasks have to use the nameserver:
common headerfile:
# define _ _ P a r t n e r I d _ N A M E S E R V E R I D { 2 , 1 , 1 , 1 }
# define _ _ P a r t n e r M a i l b o x _ N A M E S E R V E R I D { 2, 1, 1, 2 }
# define P a r t n e r I d _ N A M E S E R V E R I D (( PxNameId_t ){ _ _ P a r t n e r I d _ N A M E S E R V E R I D })
# define P a r t n e r M a i l b o x _ N A M E S E R V E R I D (( PxNameId_t ){ _ _ P a r t n e r M a i l b o x _ N A M E S E R V E R I D })

Creator:
CPartnerId = PxTaskCreate ( PXOpoolTaskdefault , & Partner_Spec , PARTNER_PRIO , P A R T N E R _ A C T I V A T I O N _ E V E N T S );
if ( PxTaskIdError ( CPartnerId ) != PXERR_NOERROR )
PxPanic ();
if ( PxNameR egister ( PartnerId_NAMESERVERID , sizeof ( PxTask_t ) , & CPartnerId ) != PXERR_NOERROR )
PxPanic ();
_mbx = PxTaskGetMbx ( CPartnerId );
if ( PxNameR egister ( PartnerMailbox_NAMESERVERID , sizeof ( PxMbx_t ) , & _mbx ) != PXERR_NOERROR )
PxPanic ();
User:
if ( PxNameQuery ( PartnerId_NAMESERVERID , sizeof ( PxTask_t ) ,& PartnerId ,0) != PXERR_NOERROR )
PxPanic ();
if ( PxNameQuery ( PartnerMailbox_NAMESERVERID , sizeof ( PxMbx_t ) ,& PartnerMailbox ,0) != PXERR_NOERROR )
PxPanic ();

Separate task into own projects / libraries
Separating tasks into own libraries

Enhances modularity
Enhances flexibility
Enhances reusability

Use the MPU
In the first steps it might be useful to let all task access the
complete memory
In this step the task specific data areas will be configured and
passed to the MPU
Additional protection areas for the appropriate tasks must be
configured

Set tasks to user 0 mode, where possible
In the first steps it might be useful to let all task run in user 1 mode
In this step all tasks with no access to peripherals run in user 0 mode
Task that have non time critical access to peripherals run in user 0
mode, too
These tasks use the PxRegister ... functions

Restrict access rights
In the first steps it might be useful to give all access rights to all
tasks
In this step the access rights are reduced to the rights needed

Encapsulate remaining global data
There may remain some global shared data

Several task must access these data
Encapsulate the data in a message
This message is stored in a global mailbox
The mailbox id is accessable via nameserver
The tasks take the message from this mailbox to access data

PXview
Events of the application are logged in a circular buffer

User-defined buffer size
User-controlled number of logged events
Recording:
Status changes between tasks and interrupt service routines
Send / receive messages
Send / receive events
Running times of tasks and interrupt service routines
Task changes
User-defined entries


Presentation Tricore

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Presentation Tricore

Caricato da

Copyright:

Formati disponibili

PXROS-HR for TriCore

The safety platform for embedded systems

Author: Mario Cupelli

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

Soft vs. Hard Realtime

HighTec EDV-Systeme GmbH

PXROS Basic Concepts I

Conceived as an object-based multitasking operating system over 20

HighTec EDV-Systeme GmbH

PXROS Basic Concepts II

HighTec EDV-Systeme GmbH

The basic concept for avoiding the propagation of errors is to

HighTec EDV-Systeme GmbH

Using shared memory is prohibited

HighTec EDV-Systeme GmbH

TriCores Memory protection

HighTec EDV-Systeme GmbH

System functions are called by the SVC interface which allows

HighTec EDV-Systeme GmbH

Tasks and Handlers

HighTec EDV-Systeme GmbH

Object Management in PXROS-HR

HighTec EDV-Systeme GmbH

Object Management in PXROS-HR

Speicherklasse / Memory Class

HighTec EDV-Systeme GmbH

Object Management in PXROS-HR

HighTec EDV-Systeme GmbH

PXROS time management services

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

Resource Allocation as the Primary Objective

Occurring errors only have local impact

HighTec EDV-Systeme GmbH

Several tasks are to be processed simultaneously

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

Scheduling Procedures III

Non priority-based superseding scheduling

Priority-based superseding scheduling

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

PXROS-HR has to be initialzed by the function PxInit ()

HighTec EDV-Systeme GmbH

If some hardware specific initialization has to be done in supervisor mode,

HighTec EDV-Systeme GmbH

The application starts in supervisor mode, so all necessary initialization

error = PxInit (& InitSpec );

HighTec EDV-Systeme GmbH

/* Initialize the name server */

TcpIpTaskId = TcpIpStart ();

LedServer_Id = PxTaskCreate ( PXOpoolTaskdefault , & LedServer_Spec , LEDSERVER_PRIO , L E D S E R V E R _ A C T I V A T I O

HighTec EDV-Systeme GmbH

Alternatively, the task may call PxAwaitEvents(0) to remove itself from

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH

Separation of hardware-dependent and hardware-independent

HighTec EDV-Systeme GmbH

HighTec EDV-Systeme GmbH