Arccore User Documentation For Autosar 4.X Products

ArcCore User Documentation for
AUTOSAR 4.x Products

1. Arctic Guides . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Creating an Application Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Creating an Ecu Configuration Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Introduction to Complex Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.4 IO Hardware Abstraction Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Memory Protection Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.6 Post Build Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.7 Watchdog Configuration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.8 Configuring PDU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
1.9 Configuring the SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
1.10 Low Power Mode Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
1.11 Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
1.12 Configure Jump from Application to Boot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
ArcCore User Documentation for AUTOSAR 4.x Products
Arctic Guides
Welcome to the Arctic Guides which is a collection of tutorial like articles with the purpose of teaching users to work with Arctic Studio tools and
Arctic Core. Before starting to follow any of these guides be aware that there are prerequisites setting up the development environment. Please
read "Begin Here" before starting with any of the guides in this section.
Creating an Application Model
This tutorial will show you how to set up an AUTOSAR project and include model objects.
Creating an Ecu Configuration Project
This tutorial will show you how to create an Ecu configuration project.
Introduction to Complex Drivers
A guide on how to create create and design complex drivers
IO Hardware Abstraction Guide
A guide on how to IOHWAB.
Memory Protection Guide
Post Build Guide
A guide on how to use post build
Watchdog Configuration Guide
A guide on how to configure the Watchdog
Configuring PDU
A guide on how to configure PDU
Configuring the SPI
Low Power Mode Guide
This guide aids in the configuration of Low Power Mode (LPM) on a Freescale mpc5607b and how to wakeup from it.
Integration
The integration sections describe the integration exercises that are normally needed when the system is being created. Although
Configure Jump from Application to Boot
Page 3
Copyright © 2015, ArcCore
Creating an Application Model
Application Developer license - The features described in this document are included in the Application Developer license
Introduction On this page:
This tutorial will show you how to set up a modelling project and create a model of a tiny system of Introduction
two software components. Create project
Create Data Types
Create Interface
Create Component Types
Create project Create an Ecu Extract
What's next?
Click File > New > Other...
Select ArcCore AUTOSAR Project under ArcCore and click Next
Name the project "example-application"
Set the AUTOSAR Release settings to any of the 4.x releases
Click Finish
The workbench will suggest opening the AUTOSAR perspective, it is recommended to
accept.
(Unlike Ecu Configuration Projects, this project does not require any references to other
projects)
Create Data Types

This section describes how to create the diferent AUTOSAR data types.
Create arxml File
Click File > New > Other

Select ArcCore AUTOSAR File under ArcCore and click Next
Set File Name to "BaseTypes.arxml"
Select With an ARPackage and name it "BaseTypes"
Create SwBaseType
If you earlier opened the AUTOSAR perspective, you will have the Autosar Navigator vie
w in the left part of your screen
If you do not see the Autosar Navigator:
Click Window > Show View > Other...
Select AUTOSAR Navigator under ArcCore and click OK
In the AUTOSAR Navigator view, browse down to the element "BaseTypes
[ARPackage]"
Right-click on "BaseTypes [ARPackage]" and click New Child > Elements > Sw Base
Type
Edit SwBaseType
In the AUTOSAR Navigator view, browse down to the element "Sw Base Type
[SwBaseType]"
Click Window > Show View > Properties
In the Properties view set Short Name to "uint8"
In the Properties view set Category to "VALUE"
Right-click on "uint8 [SwBaseType]" and click New Child > Base Type Definition > Bas
e Type Direct Definition
Select Base Type Direct Definition [BaseTypeDirectDefinition]
In the Properties view set Native Declaration to "uint8"
Page 4
Create ARText swcd File

Select ARText swcd File under Other and click Next
Make sure Container points to the example-application project
Set File Name to "Types"
Set Package Name to "Example.Types"
Click Finish
Open the new file by double clicking it in AUTOSAR Navigator or Project Explorer
If asked to add the ARText nature to the project, click Yes
You will now see the file opened in the SWCD Editor, with the contents
package Example.Types
Create ImplementationDataType
In the SWCD Editor import the SwBaseType by entering

import BaseTypes.uint8
Create an ImplementationDataType by entering

int impl MyInt extends uint8
You can get suggestions and templates from the SWCD Editor's Content Assist feature
by pressing Ctrl+Space at any location in the file
Create Interface
Follow the steps of Create ARText swcd File above, but this time with
File Name set to "Interfaces"
Package Name set to "Example.Interfaces"
Open the file Interfaces.swcd
Import the Data Type by entering
import Example.Types.MyInt
Imports can mostly be handled automatically by the SWCD Editor when using
the Content Assist feature
Create a Sender Receiver Interface with one Data Element by entering

interface senderReceiver MySRInterface {
data MyInt MyElement
}
Create Component Types

File Name set to "Components"
Package Name set to "Example.Components"
Open the file Components.swcd
Create an Application Software Component Type by entering
Page 5
component application MyProducer {

ports {
}
}
Add a Provider Port to the ports section of the Component Type by entering
sender MySenderPort provides MySRInterface
If the above was done using Content Assist, the required imports were added
automatically, otherwise add
import Example.Interfaces.MySRInterface
below the package declaration at the top of the file

Create an Internal Behavior at the root level of the file, by entering
internalBehavior MyProducerBehvior for MyProducer {
Create a Runnable inside the internalBehavior block by entering

runnable MyProducerRunnable [1.0] {
Create a Timing Event inside the runnable block, by entering

timingEvent 1.0
Create an Implementation at the root level of the file, by entering

implementation MyProducerImplementation for MyProducerBehvior {
language c
codeDescriptor "src"
}
The complete contents of the file should now look something like this
Page 6
package Example.Components
import MyProducer.MyProducerBehvior

ports {
}
}

timingEvent 1.0
}
}
implementation MyProducerImplementation for

MyProducerBehvior {
language c
}
Create another Application Software Component Type, by entering

component application MyConsumer {
ports {
receiver MyReceiverPort requires MySRInterface
}
}
Create an Internal Behavior for it, by entering

internalBehavior MyConsumerBehavior for MyConsumer {
runnable MyConsumerRunnable [1.0] {
timingEvent 1.0
}
}
Create an Implementation for it, by entering

implementation MyConsumerImplementation for
MyConsumerBehavior {
language c
}
Page 7
package Example.Components
import MyProducer.MyProducerBehvior
import MyConsumer.MyConsumerBehavior

ports {
}
}

timingEvent 1.0
}
}
implementation MyProducerImplementation for

MyProducerBehvior {
language c
}
component application MyConsumer {

ports {
receiver MyReceiverPort requires MySRInterface
}
}
internalBehavior MyConsumerBehavior for MyConsumer {

runnable MyConsumerRunnable [1.0] {
timingEvent 1.0
}
}
implementation MyConsumerImplementation for

MyConsumerBehavior {
language c
}
Create an Ecu Extract

File Name set to "EcuExtract"
Package Name set to "Example.EcuExtract"
Open the file EcuExtract.swcd
Create a Composition, by entering
Page 8
composition MyComposition {
Create Prototypes of the Software Components inside the composition, by entering

prototype MyProducer TheProducer
prototype MyConsumer TheConsumer
Create a Connector between the ports of the Components inside the composition, by
entering
connect TheProducer.MySenderPort to
TheConsumer.MyReceiverPort
package Example.EcuExtract
import Example.Components.MyProducer
import Example.Components.MyConsumer
composition MyComposition {
prototype MyProducer TheProducer

prototype MyConsumer TheConsumer
connect TheProducer.MySenderPort to
TheConsumer.MyReceiverPort
}
Create an ARText System Definition file

Select ARText sysd File under Other and click Next
Make sure Container points to the example-application project
Set File Name to "EcuExtract"
Set Package Name to "Example.EcuExtract"
Click Finish
Create a system by entering

system MySystem {
Point to the root composition inside the system, by entering

rootComposition MyComposition
Create implementation mappings inside the system by entering

mapping {
implMap MyProducerImplementation to TheProducer
implMap MyConsumerImplementation to TheConsumer
}
Page 9
package Example.EcuExtract
import Example.Components.MyProducerImplementation
import Example.EcuExtract.MyComposition.TheProducer
import Example.Components.MyConsumerImplementation
import Example.EcuExtract.MyComposition.TheConsumer
system MySystem {
rootComposition MyComposition
mapping {
implMap MyProducerImplementation to TheProducer
implMap MyConsumerImplementation to TheConsumer
}
}
What's next?
The tutorial Creating an Ecu Configuration Project will show you how to import your
application model into an Ecu Configuration project
Page 10
Creating an Ecu Configuration Project
Platform Developer license - The features described in this document are included in the Platform Developer license
This tutorial will show you how to create an Ecu configuration project, import an application model Introduction
and create an empty Ecu configuration file. Create Project
Import Application Model
from SWCD
Create Ecu Configuration
Create Project File
Connect to Ecu Extract
What's next?
Click File > New > C Project
Set Project name to "example-ecu"
Set Project type to Empty Arctic Core Project
Set Toolchain to the appropriate Core Builder Toolchain for your MCU
Click Next
Set Arctic Core source path to point to your Arctic Core project
If the project resides in your workspace folder, enter "${workspace_loc:/core}"
Otherwise, click Browse.. to locate your Arctic Core folder
Set AUTOSAR Version to one of the 4.x versions
Click Finish
When prompted, select the target board that you want the project to build against
Click OK
Import Application Model from SWCD
To create an example application model, check out the Creating an Application Model tut
orial
This section assumes you have done that tutorial
Open any swcd file in the example-application project

If you do not see the AUTOSAR Navigator view:
Click Window > Show View > Other...
Select AUTOSAR Navigator under ArcCore
In the AUTOSAR Navigator view, expand the Merged Model element, select all its
packages and right-click > Export to AUTOSAR XML
In the dialog, select the example-ecu project and set File Name to "EcuExtract.arxml"
Click OK
Create Ecu Configuration File

Click File > New > ArcCore Autosar File
Set Parent folder to the example-ecu project
Set File name to "EcuConfiguration.arxml"
Select Create Ecu Configuration and set the name to "MyEcu"
Select With an ARPackage and set the name to "Example"
Open the file with the BSW Editor by double clicking it
Connect to Ecu Extract

Set ecuExtact in the ECU Information and options section by clicking the tree button
In the dialog, select MyCompositionEcuExtract and click OK
Page 11
What's next?
Take a look at the Arctic Core reference for help on configuring the platform for your ECU
Page 12
Introduction to Complex Drivers

Introduction
Complex drivers are software modules that are not defined by AUTOSAR. The main purpose of
complex drivers is to add support for complex sensors or actuators. They may also be used to
extend or enhance the AUTOSAR standard in various ways e.g. encapsulating legacy functionality.
The complex drivers may have three different interface categories:
BSW modules
Micro Controller/Hardware
SWC interface provided by the RTE
Recommendations for complex drivers are available in CDD Design And Integration Guideline whi
ch was introduced in AUTOSAR version 4.1. It is encouraged to follow these recommendations and
this document also describes the capabilities of complex drivers in further detail.
The recommendations includes a file structure that is very similar to any other BSW module. This
means that the configuration is separated into configuration files that are included by the actual
implementation files.
Basic Software Modules Interfaces

The interfaces of the BSW modules are found in core/include. The path is included when building
projects so the headers files may be included without any path. The only file that needs to be
included to use a BSW module is the corresponding header file. That header file includes all types
and configuration files. E.g. only CanIf.h needs to be included in order to use CanIf.
Micro Controller/Hardware Interfaces

The register definitions for the micro controllers are found in core/arch/<architecture>/drivers or in
one of its sub directories. The path is included when building projects so the headers files may be
included without any path.The register file for mpc5516 is found in core/arch/ppc/drivers/mpc5516.
h.
SWC Interfaces
The SWC interfaces are generated by the RTE generator and provides a service interface to the
complex driver. ArText files are used to model the service the way of working is similar to modelling
a ordinary SWC. The service components in Arctic Core does exactly this and may be used as
inspiration when writing the service interface for the complex driver.
Arctic Core/Studio Integration

Complex drivers may be integrated in Arctic Core either by using Arctic Studio to configure the
driver or handling the configuration manually by editing the configuration files. All files related to the
complex driver should be located in the project and not in the Arctic Core folder.
Arctic Studio Integration

Arctic Studio provides a powerful way of designing complex drivers to make them available as any
other BSW module.
Configuration file generation using Xpand templates

ArText file generation for providing functionality to SWCs using Xpand templates
Validation using Check files
Customized GUI using style sheets
More information is found in the Advanced Usage section of the BSW editor documentation. All
Page 13
standard BSW modules in Arctic Studio are realized using this functionality.
This is probably the preferred way of working if there is a lot of configuration needed for the
complex device driver or if the configuration changes a lot. This is also a nice way of simplifying the
usage and configuration if the complex driver is a product in itself that is marketed to external
customers.
The generator, check, and stylesheets should be located in the project and not in Arctic Core.
Manually configuration
The configuration files and ArText files may of course be created and edited manually without using
Artic Studio.
This is probably the preferred way of working if configuration is limited and static.
Page 14
IO Hardware Abstraction Guide

Introduction
The IO Hardware abstraction main purpose is to provide access to hardware in the software
components. Digital signals (DIO), Analog signal (ADC), and Pwm Signals (PWM) are supported.
It also offers some additional functionality that reduce the complexity of the software components:
Scaling e.g. the ADC values may be scaled to the actual physical values
Electrical diagnostics e.g. a ADC value is read outside the valid range will report an error
to the DEM
Input/Output control handling by providing an interface to the DCM.
Dio extension via SPI (or any other underlying driver)
Information about individual parameters are available in BSW Editor or in the IO Hardware
Abstration reference page.
Limitations
BSW Software
Dio electrical diagnostic is will read port register values and not actual values on the pins.
This means that the read back will not work and error codes will not be set.
IO control for PWM only support setting the duty cycle. The frequency will get the last set
value.
A2L Exporter
The A2L exporter has not support for COMPU METHODS. This means that the A2L file
will not be include correct scaling information about the ADC electrical diagnostic values.
Functionality
Digital Signals
There are two top level containers used by digital signals, the digital signal container and the
external device container. A digital signal will either use the Dio module interface or the external
device interface. This is selected for each digital signal and the project must provide the
implementation of the external device when used. A header file is generated for each external
device that simplifies the handling of devices for the integrator.
There are three types of digital signals
Read
Write
WriteReadBack
For write read back signals, it is possible to add electrical diagnose that will trigger a DEM event
when it is not possible to set a write signal. There is also a simple scaling for Dio that may be used
to invert values.
Analog Signals
There are two top level containers used by analog signals, the analog signal container itself and
the scaling container. An analog signal requires a scaling and refers a scaling container. The
scaling is includes a scale, offset, and a type e.g. volt.
It is possible to add electrical diagnose that will trigger and DEM events. There are three types of
diagnostic triggers and it is possible to have different events for different triggers.
Page 15
Low - will trigger when the value in volt in below a limit

High - will trigger when the value in volid is above a limit
Range - will trigger when the value is outside a range
The limits are calibratible (if used in the project) and the corresponding parameters is enabled in
the general IoHwAb configuration settings.
PWM Signal
There is only container for the PWM Signals. It specifies the PWM Channel and the type of signal.
The type can either be DUTY_CYCLE or DUTY_CYCLE_AND_FREQUENCY.
Input Output Control

Input output control is a part of the DCM making it possible to control values read and written by
the SWCs. It is possible to freeze the current values, set a value, set the default value as specified
in IoHwAb. E.g if set to default value, the default will be read by the SWCs for input signals
regardless of the actual values read by the hardware. If default value is set for output signals, that
value will be used to set the actual hardware value regardless of what the SWCs writes.
For PWM signals, IO Control only supports setting the duty cycle value and not the frequency.
Integration
The IoHwAb module depends on a the iohwab.c file which is not a part of the platform and must be
implemented with the project. The platform proposes a design how to implement it by providing a
iohwab.h file. The header file depends on the configuration and will declare prototypes for the
required functions:
void IoHwAb_Init(void)
void IoHwAb_MainFunction(void)
Adc_ValueGroupType IoHwAb_Adc_ReadSignal(Adc_GroupType group, Adc_ChannelTy
pe channel, IoHwAb_StatusType * status)
Pwm_PeriodType IoHwAb_Pwm_ConvertToPeriod( Pwm_NamedChannelsType channel,
IoHwAb_FrequencyType freq)
The implementation of these functions are often simple. The IoHwAb_MainFunction() will
continuously read ADC values and the IoHwAb_Adc_ReadSignal() will return the latest value.
The IoHwAb_Pwm_ConvertToPeriod converts a frequency to the period for the specific PWM
channel.
An example is available in the HelloWorld example application.
Page 16
Memory Protection Guide

This chapter describes what to think about then configuring and implementing memory protection. Introduction
Functional Description
Accessing
permissions
Functional Description Sectioning
Memory Region
Memory protection is used to control memory access rights for OS-Applications and its objects Permissions
(tasks,ISR2, etc). Trusted Functions
Autosar divides OS Applications into two types, Trusted and Non-Trusted. A trusted application Error Handling
have unlimited access Hooks
to memory and I/O whereas a Non-Trusted application only have access to internal data and CPU
shared code/data. specific
The Trusted, Non-Trusted types are mapped to CPU modes commonly called supervisor and user Adding Memory Protection
mode. Limitations
The CPU hardware to control memory access is done by a MMU or a MPU. The MMU is always
local to the CPU
core whereas the MPU can be located local or on a system level. The big difference between MMU
and MPU is that
the MPU does not support virtual memory. The access rights associated with a memory region are
often
R-Read, W-Write, X-Execute and Supervisor/User mode.
Accessing permissions
It's allowed to access all OS-objects that belongs to the same OS-Application. To access OS-object
that belongs to another Application you need to give that Application specific rights to do so.
Sectioning
Memory protection relies on that the software can be sectioned beyond the normal text/bss/data
sections. Every task must be assigned memory regions that it may use. To do this in a static
memory allocated world the code/data must be put into sections. These sections are created by
compiler directives that are defined in MemMap files (MemMap.h,<SWC>_MemMap.h, etc) that are
defined by Autosar.
The RTE generator will create sections of the following MemMap types
MemMap type Description
VAR_CLEARED_UNSPECIFIED Zero initialized data.
VAR_INIT_UNSPECIFIED Initialized data
SEC_CODE Code
SEC_CALIB_UNSPECIFIED Calibration data
Example
#define Abc_START_SEC_VAR_CLEARED_UNSPECIFIED
#include <Abc_MemMap.h>
uint32 myVar;
#define Abc_STOP_SEC_VAR_CLEARED_UNSPECIFIED
#include <Abc_MemMap.h>
ARCCORE MemMap.h does not use MEMMAP_ERROR pre-processor directive and

hence does NOT warn about unmapped sections.
Page 17
Memory Region Permissions

The current design of memory protection assumes the following:
ALL Applications have read and execute permissions to the entire memory.
Tasks that belong to Non-Trusted Applications have the following write permissions
To it's own stack
To it's initialized data
To it's zero initialized data.
To support these permissions a number of symbols are generated for a task that belong to a
Non-Trusted Application.
The symbols can later be used in the linkfile to decide what is private bss/data.
Symbol Description
__OS_START_SEC_data_<task> Start of <task> private data area
__OS_STOP_SEC_data_<task> Stop of <task> private data area
__OS_START_SEC_bss_<task> Start of <task> private bss area
__OS_STOP_SEC_bss_<task> Stop of <task> private bss area
No symbols are generated for the stack since the OS knows that already.
The permissions are setup in files named os_mpu_xxx.c, where xxx is the MCU variant(s), and are
located in
arch/ppc/mpc55xx/integration.
An example configuration could be:
Flash : 0x0000_0000 to 0x1FFF_FFFF

SRAM : 0x4000_0000 to 0x4FFF_FFFF
That becomes
# Description Permissions Trusted or Start Addr End Addr

Not
0 Supervisor+us SM_RWX + Trusted 0x0000_0000 0x1fff_ffff

er code UM_RWX
1 Supervisor I/O SM_RWX Trusted 0xfc00_0000 0xffff_ffff
2 Supervisor SM_RWX + Trusted 0x4000_0000 0x4fff_ffff

data UM_R
3 User Mode, UM_RW Not

stack

.data

.bss
SM - Supervisor Mode
UM - User Mode
R-Read, W-Write, X-Execute
Trusted Functions
The trusted functions are implemented using a SYS_CALL_ prefix in front of the selected OS
services.
Page 18
You can currently not define your own trusted functions.
Call Notes
SYS_CALL_INDEX_EnterSupervisorMode Should only be used by the RTE.

It's there for effeciency reasons.
SYS_CALL_ResumeAllInterrupts
SYS_CALL_SuspendAllInterrupts
SYS_CALL_WaitEvent
SYS_CALL_ClearEvent
SYS_CALL_SetEvent
SYS_CALL_ActivateTask
SYS_CALL_GetEvent
SYS_CALL_INDEX_TerminateT
ask
SYS_CALL_INDEX_write This is used by Arccore printf() to print from
user mode.
Error Handling
This chapter describes what to expect from the OS and how to debug memory mapping problems.
Hooks
The hooks are there to aid in finding errors related to memory protection. Below are the error hooks
that matter to memory protection described.
Hook Error Description
ProtectionHook E_OS_PROTECTION_ME Memory violations

MORY
E_OS_PROTECTION_EXC Instruction exceptions

EPTION
ErrorHook With error=E_OS_ACCESS A task tries to do use a

system service (often
SetEvent()/ActivateTask() )
that it's not allowed to.
If the task should be
allowed to perform the
system service, add the
application to the task by
selecting
the application under
"Os Task Accessing
Application" in the
OS-Editor
ShutdownHook E_OS_PANIC This may be related to

memory protection. You
need to have protection
hook to find out if it is.
Page 19
The error to ShuwdownOS(..)/ShutdownHook(..) will always be E_OS_PANIC regardless
if the protection hook is configured or not.
Page 20
Supported return values from the protection hook are
ProtectionHook Description
return value
PRO_IGNORE Ignore the error
PRO_SHUTDOWN Shutdown
.. Not supported or has no meaning

for memory protection
CPU specific
MPC5xxx MPU
Overview
When a privilege violation occurs you either a IVOR1 or IVOR2 exception. What you
get differ from one MCU implementation to the next.
MCU Exception SPR registers
MPC5516 IVOR2 SRR0 - instruction

address where the
violation occurred.
SRR1 - MSR at
the time of the
exception
ESR - indicates
what kind of error
it is.
DEAR - contains
the faulting
address
MPC5643L IVOR1 Machine Check

Exception
MCSRR0 - instruct
ion address where
the violation
occurred.
MCSRR1 - MSR at
the time of the
exception
MCSR - What kind
of error
The MPU error registers will also be written but does not normally contain any more information
than the core has.
Debugging
Set a breakpoint on exception_IVOR1 or exception_IVOR2 depending on MCU

flavor.
(make sure you load the global symbol take when you load *.elf so you get the
symbols)
With the help of the debugger check what creates the violation by listing from the
instruction address
in [MC]SRR0.
You will find an assembler instruction that either tries to load or store something,
e.g. ldw, stw, etc
Page 21
What memory address does the instruction try to access?

Take the appropriate action:
Should memory access be allowed?
YES
The variable it tries to access is not in the right section.
Possible faults:
The memory address is not a section that is not in MemMap.h

The task that causes the violation have it's private data/bss limits set wrong
No
The software has a malfunction accesing memory outside allowed regions.
Adding Memory Protection

This chapter describes how to add OS-objects and code to support memory protection.
Config: Open the OS-module with the BSW Editor

Set OsOS:Os Scalability Class to SC3
Set OsOS:OsHooks:Os Error/Protection/Shutdown Hook to
True
Create an OsTask, "MyTrustedTask"
If another OsApplication should activate the task add that OsApplication
to "Os Task Accessing Application"
Create an OsApplication, "MyTrustedApplication" with "Os Trusted" = False
Code: Create a variable in c-code
You cannot access a global/static varibles from MyTrustedTask without placing it
into
a section, we do that first.
#define Abc_START_SEC_VAR_CLEARED_UNSPECIFIED
#include <MemMap.h>
uint32 Abc_myVar;
#define Abc_STOP_SEC_VAR_CLEARED_UNSPECIFIED
#include <MemMap.h>
To place the variable into the right section we also need to define it in MemMap.h
Create a convenience macro to use later:
#define PARTITION_NT_CLEARED __attribute__ ((section
(".partition_nt_bss")))
Apply the attribute to section Abc_START_SEC_VAR_INIT_UNSPECIFIED
#ifdef Abc_START_SEC_VAR_CLEARED_UNSPECIFIED
PARTITION_NT_CLEARED
#endif
When compiling Abc_myVar will now end up in section ".partition_nt_bss"
We now need to place the section ".partition_nt_bss" in memory somewhere. This is

done in the linker file.
For the Diab compiler that would look something below and the section should be placed
in an area that is cleared by software:
__OS_START_SEC_bss_MyTrustedTask = .;
.partition_nt_bss (BSS) : {}
__OS_STOP_SEC_bss_MyTrustedTask = .;
Page 22
If you would compile and link now you would get link errors on __OS_START_SEC_data
sections so lets setup one of these too.
In code
#define Abc_START_SEC_VAR_INIT_UNSPECIFIED
#include <MemMap.h>
uint32 Abc_myVar_Init = 5;
#define Abc_STOP_SEC_VAR_INIT_UNSPECIFIED
#include <MemMap.h>
In MemMap.h
#define PARTITION_NT_INIT __attribute__ ((section
(".partition_nt_data")))
#ifdef Abc_START_SEC_VAR_INIT_UNSPECIFIED
PARTITION_NT_INIT
#endif
In linkfile
/* Create a hole in ROM */

__PARTITION_NT_ROM = .;
.=.+SIZEOF(.partition_nt_data);
/* .... */
/* Load ROM section to RAM */

__OS_START_SEC_data_MyTrustedTask = .;
.partition_nt_data (DATA) LOAD(__PARTITION_NT_ROM) : {}
__OS_STOP_SEC_dataMyTrustedTask = .;
Now compile and link

Done!
Limitations
Feature Description
1.1
Internal requirement Description
MPCORE-007 There is only one trusted partition
MPCORE-006 All BSW modules execute in the trusted

partition
MPCORE-010 Multiple instansiation is not supported if SWCs

are located in different partitions
Page 23
DEV_3 CallTrustedFunction() will not be implemented.
DEV_5 Restart Partition will NOT be supported
DEV_8 Read will be allowed to entire memory

space from a Non-Trusted partition.
DEV_10 ISRs will execute only execute in trusted mode
Page 24
Post Build Guide

Introduction
Post build is used to update parts of the configuration after compile time and is typically used by
the OEM. The post build parameters are located in a separate memory area which may be
replaced by a new configuration that may be downloaded independently of the other parts for the
ECU software. Post build and calibration are two different concepts; post build offers the possibility
to add and remove parameters while calibration only offers to change parameters.
The following modules supports post build:
CanIf
PduR
Com
CanNm
CanTp
There are two kinds of project when it comes to post build. The development project that is used for
configuring the Ecu and the post build project that is used to make post build changes. This guide
describes how to adapt the development project to support post build and how to create a postbuild
project.
This guide also addresses how to update the post build configuration, consistency checks, and
limitations.
Limitations
Basic Software Limitations

There are two versions of post build in AUTOSAR named selectable and loadable. Only
loadable is supported.
It is configurable whether post build should be used within the project or not. When
enabled all of the above module configurations are placed in the post build area. It is not
possible to select a subset.
ComNotifications may not be removed all together in post build. It is possible to move it
from one signal to another though.
Post build is only supported for the Code Warrior compiler.
Communication matrix importer limitations

There is no support NPdu and DcmIPdus and these needs to be handled manually. All
these IPdus will be assumed deleted. All deletions must however be confirmed and
pressing "No" will keep the IPdus.
An IPdu without a FrameToPduMapping will be assumed deleted. If pressing "No" upon
confirmation, the IPdu will be removed for the ComIPduGroup and its signals will be
disconnected. This means that the frame will not be transmitted/received anymore but the
signals and pdus will still exist.
A signal without a ISignalToIPduMapping will be assumed deleted. If pressing "No" upon
confirmation, the signal will just be disconnected from the IPdu. The init values will be
used.
The ComIPdu are named according to the underlying frame e.g. CanFrame. The
shortName of the IPdu is not used. Example: Assume there exist one IPdu named IPdu0
and it is mapped to a frame named Frame0. A new IPdu is added named IPdu1. All signals
is moved from IPdu0 to IPdu1 and the frame mapping from Frame0 to IPdu0 is updated to
IPdu1 instead. Importing this communcation matrix will no effect the BSW configuration at
all.
There is not full support for CanTp import - it should only be used when importing in pre
compile mode. It should not be used in postbuild mode and the corresponding container
should be disabled in the import wizard.
All frames related to diagnostics including UUDT frames are not supported. All these
frames should be excluded from the import in the import wizard. Choose to keep all frames
when the question appears to delete frames related to diagnostics.
Consistency Check
Page 25
The post build configuration must be compatible with the configuration used at compile time of the
ECU. E.g. it is not possible to update a PduR Zero Cost parameter since this is parameter has an
effect on the actual code and not only on the data in the post build configuration.
The consistency check is achieved by creating an MD5 checksum of all pre compile configuration
files of the post build modules, both when at compile time of the whole ECU and at compile time of
the post build configuration. This checksum is then compared in EcuM when the node is started
and also when compiling the post build configuration. (It is also possible to perform this check in
the bootloader but it is up the platform integrator). This consistency will ensure:
Compatible generators
Compatible configurations
Valid postbuild memory area
Adapting the Development Project

The development project needs to be adapted to create the MD5 checksum file used for the
consistency check. This is done by changing the build_config.mk and makefile. The changes
needed is described in the examples below:
build_config.mk Expand
# Files used fore checksum in consistency check, this is all the
source
pre compile config files. The order needs to be the same
# in the post build project.
pc-checksum-files = $(addprefix ../config/, CanIf_Cfg.h
CanIf_Cfg.c CanNm_Cfg.c CanNm_Cfg.h CanTp_Cfg.h)
pc-checksum-files += $(addprefix ../config/, Com_Cfg.h Com_Cfg.c
PduR_Cfg.h PduR_Cfg.c)
# CFG_POSTBUILD enables post build support in the platform

# POSTBUILD_ADDRESS specifies the address for the post build
section
# CFG_POSTBUILD_PARTNUMBER enables 8-byte partnumber in the
postbuild header
def-y += CFG_POSTBUILD
def-y += CFG_POSTBUILD_PARTNUMBER
def-y += POSTBUILD_ADDRESS=0x808000
Page 26
Makefile Expand
# Add target to create hash file
source
all-mod += PreCompiledDataHash.h
# Creation of hash file

# md5 sum of the content of the precompile configurations
specfied in the build_config.mk
# This is then piped into sed in order to create the header file
(tr is only used to create new line )
.PHONY: PreCompiledDataHash.h
PreCompiledDataHash.h :
$(Q)cat $(pc-checksum-files) \
| md5sum \
| $(SED) 's/$[a-f0-9]\{16\}$$[a-f0-9]\{16\}$.*/#define
PRE_COMPILED_DATA_HASH_LOW 0x\1=#define
PRE_COMPILED_DATA_HASH_HIGH 0x\2/' \
| tr "=" "\n" > $@.tmp
$(Q)( diff -q $@.tmp $@ > /dev/null 2>&1; \
if [ $$? != 0 ]; then cp $@.tmp $@; fi \
)
$(Q)rm $@.tmp
The file PreCompiledDataHash.h will be included by the platform and is a requisite to build when
post build is enabled.
There are a few parameters that should be considered in the BSW that limits the maximum number
of items that requires RAM. This is due to the fact that memory is only allocated statically and must
be reserved by the application in the development project. The follow parameters should be
considered (and these are naturally not possible to change in post build):
Parmeter Path Description
CanIf/ArcCanIfPublicMaxNumberOfTxBuffers The maximum number of tx buffers. This

parameter should usually no need to be
adjusted in post build.
CanIf/ArcCanIfPublicTxBufferSize The total size of the tx buffers. This parameter

should usually no need to be adjusted in post
build.
PduR/PdurRoutingTables/ArcPduRMaxRoute The maximum number of routing paths in

Count PduR
Com/ComGeneral/ComRamBufferSize The the number of bytes allocated for buffering

in Com. The formula to calculate the need is
sum(IPdu sizes) +
sum(Ipdu sizes for all Ipdus with group signals)

+ sum(IPdu sizes for all Ipdus that is Rx and is
defferred)
Com/ComGeneral/ComSupportedGroupSignal The maximum number of groups signals i

s Com.
Com/ComGeneral/ComSupportedIPduGroups The maximum number of IPdu groups in Com.
Com/ComGeneral/ComSupportedIPdus The maximum number of IPdus in Com.
Com/ComGeneral/ComSupportedSignals The maximum number of signals (ComSignals

and ComSignalGroups) in Com.
Page 27
The configuration generation will fail if the limits are exceeded, both in in the development project
and the post build project.
Creating Post Build Project

The post build project is based on the project used during development and contains a subset of
the modules. It must contain all the postbuild module and the Can and ComM modules since they
are referenced by the postbuild modules. The post option in Arctic Studio should be enabled before
delivery to OEM,
The post build project is just like any other project but it does not contain any source code. Only the
configuration files and perhaps some project specific headers files. It needs to reference core like
any other project, the compiler is setup in the same way etc.
The PreCompiledDataHash.h must be copied to the post build project from the development
project. It is named ReferenceDataHash.h in this guide and it is only used to determine post build
compatibility at compile time. The build will fail if the ReferenceDataHash.h differs from the file
created when compiling the post build project.
The build_config.mk and Makefile with explainations is found below:
Page 28
build_config.mk Expand
# Version of build system
source
REQUIRED_BUILD_SYSTEM_VERSION=1.0.0
# Build no modules but use the defines

MOD_USE =
# The defines are need due to pre processing in the config files
def-y += USE_CANTP
def-y += USE_PDUR
def-y += USE_CANNM
def-y += USE_CANIF
def-y += USE_COM
def-y += USE_NM
# Postbuild binary definitions

pb-loadable = pb
pb-loadable-srec = $(pb-loadable).s19
pb-loadable-exe = $(pb-loadable).elf
pb-loadable-map= $(pb-loadable).map
obj-pb-loadable = CanIf_PBCfg.o CanTp_PBCfg.o CanNm_PBCfg.o
Com_PbCfg.o PduR_PbCfg.o EcuM_PBHeader.o
# Files used fore checksum in consistency check, this is all the

pre compile config files. The order needs to be the same in
# development project
pc-checksum-files = $(addprefix ../config/, CanIf_Cfg.h
CanIf_Cfg.c CanNm_Cfg.c CanNm_Cfg.h CanTp_Cfg.h)
pc-checksum-files += $(addprefix ../config/, Com_Cfg.h Com_Cfg.c
PduR_Cfg.h PduR_Cfg.c)
# Same as in the devlopment project

def-y += CFG_POSTBUILD
def-y += CFG_POSTBUILD_PARTNUMBER
def-y += POSTBUILD_ADDRESS=0x808000
PROJECTNAME=PostbuildProject
Page 29
Makefile Expand
ROOTDIR?=../../../..
source
all-mod += PreCompiledDataHash.h
all-mod += postbuild
VPATH += .
inc-y += .
VPATH += ../config
inc-y += ../config
# For MemMap
VPATH += ../src
inc-y += ../src
# For EcuM_PBHeader
VPATH += $(ROOTDIR)/system/EcuM
inc-y += $(ROOTDIR)/system/EcuM
ldcmdfile-y = ../linkscript_$(COMPILER).lcf
PBLDFLAGS = -gdwarf-2 -map $(pb-loadable-map) -srec $@ -m
Postbuild_Config
# Same as for the development project and then a check that the
create file is identical to the ReferenceDataHash.h
# The ReferenceDataHash.h must be copied from the development
proejct
.PHONY: PreCompiledDataHash.h
PreCompiledDataHash.h :
cat $(pc-checksum-files) | md5sum | $(SED)
's/$[a-f0-9]\{16\}$$[a-f0-9]\{16\}$.*/#define
PRE_COMPILED_DATA_HASH_LOW 0x\1=#define
PRE_COMPILED_DATA_HASH_HIGH 0x\2/' | tr "=" "\n" > $@
@echo "Precompiled configuration consistency check"
diff PreCompiledDataHash.h ../ReferenceDataHash.h
$(pb-loadable-srec) : $(obj-pb-loadable) $(ldcmdfile-y)

$(Q)$(LD) $(PBLDFLAGS) $(LD_FILE) $(ldcmdfile-y) -o
$(pb-loadable-exe) $(libpath-y) $(LD_START_GRP)
$(obj-pb-loadable) $(lib-y) $(libitem-y) $(LD_END_GRP)
$(LDMAPFILE)
$(Q)touch $@ # Timestamp of srec sometimes newer than exe, so
correct it here
postbuild: $(pb-loadable-srec)
@echo "Build complete" > postbuild
Changing Post Build Parameters

Open the post build project and make sure Post-build mode is enabled on the BSW Editor overview
page. It is now only possible change all parameters and containers that have support for post build.
Elements that is not editable will be grayed out. It is possible to add containers when supported as
well. This means that the working with the post build configuration is very much like working with
any other configuration.
It is also possible to use the Communication Matrix importer in post-build mode. It will only update
parameters and containers that may be changed in postbuild. It will however not automatically
delete any elements and this must be confirmed by the user. A dialog will appear for each deletion
stating the container and module.
Page 30
When the new configuration has been created, it needs to be generated and compiled. This is done
in the same way as a any other project in Arctic Studio. If the consistency check is added to the
build system, inconsistencies will be discovered when compiling. This check is made in the
Makefiles and must be explicitly added (see chapter above).
Adding and removing elements used by application

It is supported to add and remove signals, signal groups, group signals, pdus and pdu groups in
Com and this must be done carefully since the application will still use the identifiers generated
when in the development project. The identifiers will be a part of Com_PbCfg.h and there will not
be any consistency check against the configuration that is used by the application. To handle this,
the identifier handles must be specified for those items and there may not be any gaps in the range
which is checked when generating the configuration.
Example: Renaming a signal
It may be seen as a removal followed by an addition. Renaming it is BSW Editor will just effect the
symbolic name but the id will remain the same so this means no extra work. If the signal is
renamed in the communication matrix in the extract some manual steps are needed to make it work
as expected. The ComHandleId will not be set automatically and must be set manually to the same
id as the signal removed. If ComNotifications were added for that signal, those will not be set either
and must be set manually in BSW Editior (the ComNotification isn't really post build changable but
if no new callbacks are added it may be added in BSW Editor pre compile mode. Adding a new
(and invalid) callback will checked in consistency check against the pre compile configuration when
compiling).
Identifiers in other modules will not effect the application since they are not used the application.
This means the ids in PduR may be automatically assigned and may differ from when compiling the
application.
The ComSystemTemplateSystemSignalRef in Com does not need to be set in postbuild. It not

used when generating the other modules than the RTE(which has not post build support).
Page 31
Watchdog Configuration Guide

Introduction
The watchdog function is realized using three AUTOSAR modules and an introduction and a
detailed parameter reference is available on the corresponding reference page.
Watchdog Manager (WdgM)

Watchdog Interface (WdgIf)
Watchdog Driver (Wdg)
The Watchdog Driver and Watchdog Interface are straight forward to configure and these
interfaces are never used by the application. The application only interfaces the WdgM. It is
therefore natural that this guide focuses on the Watchdog Manager.
Configuration
The module configuration is organized into two major parts; supervised entities and modes
Supervision Entities
The supervised entities are the logical units of supervision and is found as a sub-container to the
WdgMGeneral container. There is no fixed relationship between supervised entities and the
architectural building blocks in AUTOSAR, i.e. SW-Cs, CDDs, RTE, BSW modules. Typically a
Supervised Entity may represent one SW-C or a Runnable within an SW-C, a BSW module or CDD
depending on the choice of the developer.
Important places in a supervised entity are defined as checkpoints. The code of supervised entities
calls the Watchdog Manager when they have reached a checkpoint. A supervised entity may also
have transitions between the checkpoints. The checkpoints and the transitions forms a program
flow graph for the supervised entity.
A graph has an initial checkpoint and a final checkpoint. Any sequence starting in an initial
checkpoint and finishing in a final checkpoint is correct (assuming that the checkpoints belong to
the same graph). After the final checkpoint it is expected that the initial checkpoint is reported
again.
The granularity of checkpoints is not fixed by the Watchdog Manager. Few coarse-grained
checkpoints limits the detection abilities of the Watchdog Manager. For example, if an application
SW-C only has one checkpoint that indicates that a cyclic Runnable has been started, then the
Watchdog Manager is only capable of detecting that this Runnable is re-started and check the
timing constraints. In contrast, if that SW-C has checkpoints at each block and branch in the
Runnable the Watchdog Manager may also detect failures in the control flow of that SW-C. High
granularity of Checkpoints causes a complex and large configuration of the Watchdog Manager.
The WdgMSupervisedEntity has two types of sub containers that corresponds to checkpoints and
transitions, they are named WdgMCheckpoint and WdgMInternalTransition.
Modes
It is possible to configure different modes to the Watchdog manager. Each mode specifies the
supervision entities that shall be supervised and what kind of supervision that is active for the
supervised entities. The modes usually corresponds to application modes where only the active
parts of the application is supervised.
The alive supervision is used to supervise that a particular checkpoint is reached within a certain
time frame. This is the simplest type of supervision and it ensures that a the entity is executed
periodically.
The deadline supervision is used to supervise the time between two checkpoints. It specifies two
checkpoints and the expected time between this two checkpoints.
The program flow supervision is used to supervise the order of the supervision entity execution and
uses the graph defined for the supervised entity.
The mode also specifies the different hardware watchdog modes i.e.g FAST, SLOW, and OFF. The
SLOW mode is usually used during initialization and when the unit is in steady state the watchdog
mode is switched to FAST.
Page 32
The WdgMMode container has four types of sub containers that corresponds the different types of
supervisions, they are named WdgMAliveSupervision, WdgMDeadlineSupervision,
WdgMLocalStatusParam, and WdgMTriggers.
Integrating the WdgM Supervision

When the configuring is done it is time to interface the Watchdog Manager in the application or
complex driver. A summary of the interface is available below and refer to the WdgM specification
for detailed information.
Modes
WdgM_SetMode Sets the WdgM mode
WdgM_GetMode Gets the WdgM mode
Reporting
WdgM_CheckpointReached Used for reporting that a checkpoint has been

reached.
WdgM_UpdateAliveCounter Deprecated - should not be used.
Status
WdgM_GetLocalStatus Get the status of a supervised entity
WdgM_GetGlobalStatus Gets the global status of all supervised entities
WdgM_GetFirstExpiredSEID Gets the id of the first expired supervision

entity
Example
The RTE simple contains a basic example how to use alive supervision. It is found in the examples
directory in the core bundle.
It has two configured modes (WatchdogOn and WatchdogOff) and two supervision entities
(Supervised1000msTask and Supervised100msTask) with one checkpoint each. The two entities
have alive supervision in the WatchdogOn mode and no supervision in WatchdogOff.
The mode is default off and is set in the startup task with:
WdgM_SetMode(WATCHDOGON_MODE_ID, 0);
Each one of supervised entities corresponds to a task and the checkpoint reporting is done in the
task:
WdgM_CheckpointReached(SUPERVISED1000MSTASK_SE_ID,
SUPERVISED1000MSCHECKPOINT_CP_ID );
Page 33
Page 34
Configuring PDU
Port Configuration
Add the Port Module by selecting add and choosing the port module from the list.
Enter port configuration by double clicking on the port module in the module list of your
ECU configuration. Here, open Port->PortConfigSet->PortContainer:s and look for the
CAN port container. If in case it is not present, create a new port container by right clicking
on the PortContainer:s and selecting Create PortContainer.
For the new PortContainer fill the PortContainer shortName as CAN
Move inside the newly created CAN PortContainer and right click on the PortPin:s and
select Create PortPin (by function) and select the correct ports that is intended to be used
for the CAN communications that are available for your microcontroller, both for receiving
and sending.
CAN Configuration
Add the CAN module by selecting add and choosing the CAN for the appropriate
microcontroller from the list.
Enter the CAN module and configure the baudrate for the CAN bus to be used in CAN->C
anConfigSet->CanController:s->CanController->CanControllerBaudrateConfig:s->
CanControllerBaudrateConfig. After setting the parameters, move back to the CAN->CanC
onfigSet->CanController:s->CanController and select the default baudrate and the Can
Controller ID to be used for that Can controller. As we see in the configuration, there can
be multiple Can Controllers configured with different baudrates.
Then, we move on to the CanHardwareObjects. Here, we need to configure hardware
objects for both incoming and outgoing messages and the Can Hardware filter for them, if
required. While configuring, keep in mind that some of the fields are depreciated and need
not be filled in the configuration. If these fields are used, a warning will be generated
during the validation of the module.
EcuC Configuration
Add the EcuC module by selecting add and choosing the EcuC from the list. Enter the
EcuC module for configuring it.
In EcuC->EcuCPduCollections, right click and add Pdu. And then configure it by specifying
the name and the Pdu length of Pdu. Do this for as many Pdus to be used in your project.
CANIF Configuration
Add the CANIF module by selecting add and choosing the CANIF from the list. Enter the
CANIF module for configuring it.
Right click CanIf->CanIfInitCfg and select add CanIfHohCfg. After this, right click on the
newly created CanIfHohCfg and add the CanIfHrhCfg for configuring a Hardware Receive
Handle and/or add the CanIfHthCfg for configuring a Hardware Transmit Handle.
Configure the added handles by giving a Can If Can Ctrl Id Ref = CanIfCtrlCfg and Can
If Hth Sym Ref/ Can If Hrh Sym Ref = The CanConfigSet from the Can Module.
In CanIf->CanIfInitCfg, now add the CanIfBufferCfg and in its configuration reference the
CanIfHthCfg that was newly created and configured. Complete the rest of the
configurations according to requirements.
In CanIf->CanIfInitCfg, next add the CanIfRxPduCfg and the CanIfTxPduCfg. The
configuration of both these Rx and Tx Pdus ask for Pdu references from the EcuC->EcuC
PduCollections. Hence, this has to be previously configured. Complete the configuration
for both with details about the CAN messages used.
Lastly, in the CanIf->CanIfCtrlDrvCfg:s-> CanIfCtrlDrvCfg, give the reference of Can If Ctrl
Drv Init Hoh Config Ref to CanIfInitHohCfg.
PduR Configuration
Add the PduR module by selecting add and choosing the PduR from the list. Enter the
PduR module for configuring it.
Page 35
Right click on PduR and add the PduRBswModules. Change its shortName to CanIf and
set the Pdu RLower Module to True and Pdu RUpper Module to False.
Again, add another PduRBswModules. Change its shortName to Com and set the Pdu
RLower Module to False and Pdu RUpper Module to True.
Give the PduRRouting Tables a Pdu RConfiguration Id. Then, add a new PduRRouting
table by right clicking on the PduRRouting Table and then add new PduRRoutingPaths to
the routing table. Enter PduR->PduRRoutingTables->PduRRoutingTable->PduRRoutingP
ath->PduRDestPdu and set the appropriate Arc Overriden Dest Module as Com (for
incoming CAN messages) or CanIf (for outgoing CAN messages) and also the Pdu RDest
Pdu Ref to the ones in EcuC->EcuCPduCollections.
Com Configuration
Add the Com module by selecting add and choosing the Com from the list. Enter the Com
module for configuring it.
Inside Com->ComConfig, add one ComIPduGroup for receiving and another for sending
IPdus.
Inside Com->ComConfig, add ComSignals which has to be configured in order to
reference the com signal mapping to the IPdus along with other data information. There
will be as many ComSignals configured here as there are signals.
Inside Com->ComConfig, add ComIPdu as required. Configure them by specifying the
direction and giving references to the ComIPduGroup it belongs to, the EcuC->EcuCPduC
ollections and the Com IPdu Signal. For the transmit IPdu, add a ComTxIPdu and to that
add ComTxModeTrue or ComTxModeFalse. And here we can define of the mode of
transmission (Periodic or Mixed) and define the time period or other configuration details.
In the Com->ComGeneral, configure according to your specification.
Page 36
Configuring the SPI

On this page: Module SPI
Description AUTOSAR 4.1.2
Scalability version
Operation
Clock and Phase Compatible -
Buffers AUTOSAR
Priority and Channel Index versions
Queuing
Files Variants N/A
Units/Controllers
Notifications and Status
Description
The driver provides the services to transmitt and receive data over the SPI bus.
This document will in short describe the core functionallity of the driver with the purpose to give a
better understanding of how to use it.
For some of the architectures there are specific driver features and limitations, they are described
in the SPI section under each architecture.
Scalability
The SPI driver have three different levels of scalable functionality which are all supported.
LEVEL 0
Simple synchronous
LEVEL 1
Basic asynchronous (polling mode only)
LEVEL 2
Enhanced synchronous/asynchronous
With a synchronous transmission (ie Spi_SyncTransmit()) the caller is blocked until the
transmission is complete. With asynchronous transmission the caller is not blocked while the
transmission is on-going.
The asynchronous mode can be used with two different modes, polling mode (default) and interrupt
mode. When the polling based mode is used the function Spi_MainFunction_Handling() must be
called to get the result. To enable asynchronous transmit with interrupts a call
to Spi_SetAsyncMode must be done in order to change from polling mode.
Operation
The SPI driver is based on Channels, Jobs and Sequences. A Sequence is one or more jobs and a
job consists of one or more channels. The Job is always related to the the CS and as long a job is
active the CS is. The job is also related to the device it's communicating with. The device have
attributes such as CS identifier, baud-rate, CS polarity, etc. The channel have attributes such as
data width, buffer length, etc.
Below is a sequence, Sequence S that consists of Jobs x and y. Job x consist of channels a and b
and Job y consist of channel c.
Page 37
Clock and Phase
SPI defines Clock Polarity (CPOL) and Clock Phase ( CPHA). These can be translated to Autosar
wording as:
CPOL CPHA SpiShiftClockIdleLeve SpiDataShiftEdge Description

l
00 STD_LOW LEADING Clock idle level is 0

Data is captured on
clocks rising edge
01 STD_LOW TRAILING Clock idle level is 0

Data is captured on the
clocks falling edge
Page 38
10 STD_HIGH LEADING Clock idle level is 1

Data is captured on the
clocks falling edge
11 STD_HIGH TRIALING Clock idle level is 1

Data is captured on
clocks rising edge
The figure below show where the sample point is taken depending on CPOL and CPHA.
Buffers
There are two types of buffers in the Autosar specification, but only external buffers are supported
by the driver.
The external buffers are setup with the Spi_SetupEB and the user provides the source and
destination buffers for write/read data:
Std_ReturnType Spi_SetupEB( Spi_ChannelType Channel,
const Spi_DataBufferType*
SrcDataBufferPtr,
Spi_DataBufferType*
DesDataBufferPtr,
Spi_NumberOfDataType Length );
The max size of the external buffers are specificed for each channel
through SpiEbMaxLength. The SpiEbMaxLength is given for consistency check only.
Priority and Channel Index
Page 39
Jobs in a sequence are sent in priority order using priorities 0 to 3, 0 is low and 3 high priority. The
priority is set in SpiJobPriority.
Channels on the other hand have a index (0 to 255) that defines the order of the channels within a
job, set by SpiChannelIndex. A channel with index 0 will be transmitted first.
Queuing
Asynchronous jobs may be queued if they use the same controller and access different external
devices (=on the same bus but does not share jobs).
Note: We do not recommend queuing up multiple sequences where jobs of the queued sequences
are shared.
Example sequences:
Asynchronous Polling
Spi_SetAsyncMode(SPI_POLLING_MODE);
Spi_AsyncTransmit(0); /*
[0]:SPI_JOB_OK->SPI_JOB_QUEUED->SPI_JOB_PENDING */
Spi_AsyncTransmit(1); /* [1]:SPI_JOB_OK->SPI_JOB_QUEUED */
Spi_MainFunction_Handling();
/*..*/
Spi_MainFunction_Handling(); /* [0]: SPI_JOB_PENDING->SPI_JOB_OK
* [1]: SPI_JOB_QUEUED
->SPI_JOB_PENDING */
/*..*/
Spi_MainFunction_Handling(); /* [1]: SPI_JOB_PENDING->SPI_JOB_OK
*/
Asynchronous Interrupt
Spi_SetAsyncMode(SPI_INTERRUPT_MODE);
Spi_AsyncTransmit(0); /*
[0]:SPI_JOB_OK->SPI_JOB_QUEUED->SPI_JOB_PENDING */
Spi_AsyncTransmit(1); /* [1]:SPI_JOB_OK->SPI_JOB_QUEUED */
/* Both Sequence 0 and 1 will now be sent by interrupt */
Files
Spi.c
Spi_<arch>.c
Spi_internal.h
Spi.h
Units/Controllers
Page 40
To keep track of units and controllers a number of defines are used
#define SPI_USE_HW_UNIT_0 STD_OFF

#define SPI_USE_HW_UNIT_1 STD_ON
This indicates that if the MCU have 2 SPI controllers, only controller 1 is used here.
Controller will always be a running number from from 0 and up. It's used to get hold
of the HW address of the controller memory space.
Unit will be used for used Controllers. Will have a be a number from 0 and up. Will
always be smaller or equal to Controller.
The define SPI_CONTROLLER_CNT is the number of controllers that are actually used (it's not the
number of controllers it has)
Internally the array Spi_Unit[] is used to collect all the information about a specific controller. In the
example above Spi_Unit[0] will actually we "HW_UNIT_1" since "HW_UNIT_0" is not used.
Notifications and Status

Job1 Job2
|---------------|---------------|
JN JN,SN
Status IDLE BUSY BUSY IDLE
HwStatus IDLE BUSY BUSY IDLE
JobResult JOB_OK JOB_PENDING JOB_PENDING JOB_OK,SPI_JOB_FAILED
SeqResult SEQ_OK SEQ_PENDING SEQ_PENDING
SEQ_OK,SEQ_FAILED,SEQ_CANCELLED
JN - Job Notification
SN - Sequence Notificaiton
When a sequence has been sent on transmission it will be set to SEQ_PENDING. All jobs of the
sequence will be set to pending/queued. When a job has been transmitted it will be set to JOB_OK.
When the sequence is done it will be set to SEQ_OK.
Should a job fail it will be set to JOB_FAILED and the sequence will also be set to SEQ_FAILED.
Page 41
Low Power Mode Guide

On this page:
Introduction
Introduction
This guide aids in the configuration of Low Power Mode (LPM) on a Freescale mpc5607b and how Overview
to wakeup from it. Examples
MPC5607B
Overview
The EcuM controls the startup/shutdown of the ECU. The state-machine in the EcuM is quite
complex and is described in EcuM.
Below is a simplified sequence diagram how EcuM interacts with other modules in this guide.
Page 42
Although the sequence chart is quite big only the parts marked "USER CODE", is needed for most
cases, e.g. pin wakeup, timer wakeup.
Examples
MPC5607B
The user integration file EcuM_Callout_Stubs.c is meant to be modified for this purpose. If you
don't already have a copy if it in your project, copy from
core/arch/ppc/integration/EcuM_Callout_Stubs.c and copy functions/code from below.
#include "EcuM_Cbk.h"
#include "EcuM_Generated_Types.h"
#include "mpc55xx.h"
/* 5 seconds */
#define WAKEUP_TIMEOUT (( 2000 * 1000/32)/1000)
#define _B_SIRCDIV(_x) ((_x)<<(31-23))

#define _B_SIRCON_STDBY 1
#define _B_CNTEN (1<<(31-0))
#define _B_FRZEN (1<<(31-2))
#define _B_RTCVAL(_x) ((_x)<<(31-15))
#define _B_CLKSEL(_x) ((_x)<<(31-19))
#define SIRCON_STDBY 1
#define S_SIRC (1<<(31-27))
#define SIRCDIV(_x) ((_x)<<(31-23))
#define CLKSEL_SXOSC 0
#define CLKSEL_SIRC 1
#define CLKSEL_FIRC 2
#define PCR_PA(_x) ((_x)<<10)
#define PCR_OBE (1<<(15-6))
#define PCR_IBE (1<<(15-7))
#define PCR_ODE (1<<(15-10))
#define PCR_SRC(_x) ((_x)<<(15-13))
#define PCR_WPE (1<<(15-14))
#define PCR_WPS (1<<(15-15))
#define ME_RUN_PC0 0
#define ME_RUN_PC1 1
#define MODE_DRUN 3
/* Same on all MPC560x devices */
#define WKUP_BITS_API 0x1
#define WKUP_BITS_RTC 0x2
#define WKUP_BITS_PE0 0x40
/* Wakeup on KEY1 (PE0)
* PE0 = WKUP[6] on all MPC560x devices it seems
*/
static void initPinForWakeup(void) {
uint32_t wkupSrc = WKUP_BITS_PE0; /* PE0 = WKUP[6] on all
MPC560x devices it seems */
SIU.PCR[64].R = 0x103; /* KEY1 wake-up input - PE[0] =
WKUP[6] */
WKUP.WIPUER.R = (0x0003ffff & (~wkupSrc)); /* Weak pull-ups
on the rest */
WKUP.IRER.R = 0; /* No need to trigger interrupt
*/
WKUP.WISR.R = wkupSrc; /* Clear wake-up flags */
Page 43
WKUP.WRER.R |= wkupSrc; /* Enable wake-up event */

WKUP.WIREER.R |= wkupSrc; /* Enable on both rising and
....*/
WKUP.WIFEER.R |= wkupSrc; /* .. falling edge */
WKUP.WIFER.R = wkupSrc; /* Enable some analog filter */
}
/**
* Init for RTC wakeup
*/
static void initRTCforWakeup(void) {
uint32_t wkupSrc = 2; /* RTC wakeup (WKUP[1]) */
/* Wakeup sources:
* 2 Internal, WKUP[0:1] and 18 external sources
WKUP[2:19]
*
* Wakeup lines mapped to interrupt vectors:
* Interrupt 0
* WKUP
* 0 API
* 1 RTC
* ...
* Interrupt 1
* ..
* Interrupt 2
* ..
*/
WKUP.WRER.R |= wkupSrc; /* Enable RTC wake-up (WKUP[1]) */
WKUP.WIREER.R |= wkupSrc; /* Enable Rising Edge of WUP[1] */
WKUP.WIFEER.R |= wkupSrc; /* Enable Rising Edge of WUP[1] */
WKUP.WISR.R = wkupSrc; /* Clear wake-up flags */
/* Setup SIRC (128KHz).... why use this one? */
/* Set SIRCON_STDBY since we its off in standby. Divide
clock by 4 (3+1) -> 32Khz clock
* RTC: 8ms -> 31s
* How do we know that the SIRC is driving the RTC?
* */
/*
* Setup
* - SIRC to clock RTC (with 128KHz/4 = 32Khz) ->
* Minimum: 32ms
* 64ms
* 128ms
*/
/* Set SIRC to 32Khz and to be enabled in STANDBY */
CGM.SIRC_CTL.R = _B_SIRCDIV(3) + _B_SIRCON_STDBY;
/* Setup RTC to be clocked by the SIRC */
RTC.RTCC.R = 0; /* First turn OFF , see CNTEN */
RTC.RTCC.R = _B_CNTEN + _B_FRZEN + _B_RTCVAL(WAKEUP_TIMEOUT)
+ _B_CLKSEL(CLKSEL_SIRC);
WKUP.WISR.R = wkupSrc;
}
void EcuM_CheckWakeup(EcuM_WakeupSourceType source) {
/* Re-enable PLL again */
EcuM_ConfigType *ecuMConfigPtr;
ecuMConfigPtr = EcuM_DeterminePbConfiguration();
(void)
Mcu_InitClock(ecuMConfigPtr->McuConfig->McuDefaultClockSettings)
;
// Wait for PLL to sync.
Page 44
while (Mcu_GetPllStatus() != MCU_PLL_LOCKED) {

;
}
if (EcuMConf_EcuMWakeupSource_WakeupSourceRtc & source) {
/* Some PIN event woke us */
if (WKUP.WISR.R & WKUP_BITS_RTC) {
EcuM_SetWakeupEvent(EcuMConf_EcuMWakeupSource_WakeupSourceRtc);
}
}
if (EcuMConf_EcuMWakeupSource_WakeupSourcePin & source) {
/* Some PIN event woke us */
if (WKUP.WISR.R & WKUP_BITS_PE0) {
EcuM_SetWakeupEvent(EcuMConf_EcuMWakeupSource_WakeupSourcePin);
}
}
}
void EcuM_EnableWakeupSources(EcuM_WakeupSourceType source) {
VALIDATE_STATE(ECUM_STATE_GO_SLEEP);
initPinForWakeup();
}
initRTCforWakeup();
}
}
void EcuM_DisableWakeupSources(EcuM_WakeupSourceType source) {
uint32_t wkupSrc = WKUP_BITS_PE0; /* PE0 = WKUP[6] on
all MPC560x devices it seems */
WKUP.WRER.R &= ~wkupSrc; /* Enable wake-up event */
WKUP.WIREER.R &= ~wkupSrc; /* Enable on both rising and
....*/
WKUP.WIFEER.R &= ~wkupSrc; /* .. falling edge */
}
uint32_t wkupSrc = WKUP_BITS_RTC;
WKUP.WRER.R &= ~wkupSrc;
WKUP.WIREER.R &= ~wkupSrc;
Page 45
WKUP.WIFEER.R &= ~wkupSrc;

}
}
Introduction
Overview
Examples
Page 46
Integration
On this page:
Introduction
Files
Using your own linkfile
Modules without Editors
C-Library
assert.h
Low Level Functions
OS
Install ISR handlers
Exception Handlers
MPC5xxx
Introduction
This section describes the actions needed from an integration perspective and it covers integration files, interrupts, exceptions handlers and
c-libraries that are compiler specific.
At some point in your project you will need to modify some files to suite your needs. These files are integration files and can be copied to your
project.
Files
Files Source Description
EcuM_Callout_Stubs.c Autosar The EcuM_Callout_Stubs defines the
Memmap.h Autosar Refer to Memory Map for further descriptions.
These files often contain code that you want to modify, e.g.
PowerPC
enabling more modules, setup more clocks
Mcu_Arc_mpc55xx.c
Arccore
Mcu_Arc_mpc56xx.cmpc5xxx_callout_stubs.cos_mpu_<mcu>.c
Zynq
To be added at a later stage
TMS570
STM32
linkscript_<compiler>.ldf Arccore The linker file.
All of the files listed in the table can be copied to your own project.
Using your own linkfile

Often you need to use a custom makefile and not the one supplied with Core.
The linkfiles are located under arch/<arch_fam>/<arch>/scripts. Since the linker files a compiler dependent there will be one for each supported
compilker, e.g. linkscript_gcc.ldf, linkscript_diab.ldf.
What linkerfile is selected in directly dependent on the COMPILER environment variable.
To use your own linkerfile
Copy a linkscript_<COMPILER>.ldf file to your project and rename it to for example linkscipt_gcc_mine.ldf
Page 47
Modify the file "makefile" in your project and add:

/* our linkfile (note that it's called ".lcf" as file suffix) */
ldcmdfile-y = linkscript_gcc_mine.lcf
/* Let make know where there "ldf" file is */

vpath %.ldf ..
Modules without Editors

Some modules to not have editors but instead have hand-coded configuration files. The files are located under boards/<board>/config/.
Modules without editors are Eep, Fls and Wdg. To learn more about the modules take a look in the peripherals section.
Autosar Files
Module
Eep Eep_Cfg.h
Eep_Lcfg.h
Fls Fls_Cfg.h
Fls_Cfg.c
Wdg Wdg_Cfg.h
Wdg_Lcfg.c
To use a module that do not have and editor you need to tell the makesystem to build it. Add the module by adding "MOD_USE += <module>" to
the build_config.mk file in your project, r.g. to add the Eep module.
MOD_USE += EEP
C-Library
For most C-library functionality the Core uses the compiler supplied header files and functions.
assert.h
There is a custom assert in clib/assert.h have following call-tree. The reason for having a custom assert instead of the compiler default is to avoid
the different versions of printf() that is used by the different compiler makers.
Low Level Functions
Some higher level functions in the C-library supplied by compiler requires you to implement desired behavior. These functions are normally the
POSIX low level I/O functions plus some more. The following functions need to be ported : open, exit, fstat, getpid, kill, close, isatty, sbrk, read,
write and lseek. The implementation for those functions are located in clib/clib_port.c for most compilers except CodeWarrior that uses
clib/msl_port.c. Most of the functions are empty expect write() that is used to write messages to various debugger terminals.
OS
Page 48
Install ISR handlers
You can install interrupt handlers in two ways:
1. In the OS-Editor
2. By using macros supplied by Isr.h, ie ISR_INSTALL_ISR1(..) and ISR_INSTALL_ISR2(..)
If you install an ISR in both the OS-Editor and the ISR_INSTALL_ISRx macro the OS will ignore the install with the macro.
Example: Install an ISR handler

#include "isr.h"
void MyIsr( void ) {

/*... */
}
void install( void ) {
/* Install vector 243 with priority 8 on core 0 */

ISR_INSTALL_ISR2("MyIsr", MyIsr, 243 /*vector*/, 8 /*priority*/, 0 /*core*/);
}
Exception Handlers
MPC5xxx
For most cases exceptions are handled by the OS and fatal errors end up in ShutdownOS(). However you can if you want to write your own
exception handler.
In the function
uint32_t Mpc5xxx_ExceptionHandler(uint32_t exceptionVector)
in mpc5xxx_handlers.c you do just that. The function takes the exception vector as an argument and lets you control how the OS should behave
for that particular exception.
Possible return values are (bitmasked):
Return Value Description
EXC_NOT_HANDLED The exception was not handled by Mpc5xxx_ExceptionHandler(..)
EXC_HANDLED The exception was handled by Mpc5xxx_ExceptionHandler(..)
EXC_ADJUST_ADDR Adjusts the return address when coming back from the exception and is combined with EXC_HANDLED.
If the exception happened for example on an instruction that does causes a read error you don't want to run
that instruction again (since you will get one more exception). You will want to skip the instruction and go on with the
next. Setting this does just that.
Page 49
Page 50
Child Pages
Page 51
Configure Jump from Application to Boot
Functional Overview
When the application receives a Diagnostic Session Control (Service 0x10) with sub-function Start Programming Session (0x2) the application
should jump to the bootloader.
It does so by:
DCM: Transmitting Response Pending (NRC = RCRRP = 0x78) to the Diagnostic Session Control request.
DCM: On confirmed transmit of the NRC it calls the Dcm_SetProgConditions(..). The callout Dcm_SetProgConditions(..) should leave a
message to the bootloader in a pre-defined area.
DCM: The DCM triggers a mode switch with of ModeDeclarationGroupPrototype DcmEcuReset to
JUMPTOSYSSUPPLIERBOOTLOADER
BswM: The BswM receives the mode switch of DcmEcuReset and triggers a user callback.
Configure DCM
Configuration assumes that you are in Dcm->DcmConfigSet
Add the Diagnostic Session Control Service

Create the Service:
Go to ->DcmDsd->DcmDsdServiceTable->UDSServices.->DcmDsdServices
Create DcmDsdServices
Enter desired values (Service ID must be 16 = 0x10)
Create the Session
Go to: DcmDsp->DcmDspSession->DcmSessionTable
Create a DcmDspSession row, name it for example "PROGRAMMING_SESSION"
Session For Boot: DCM_SYS_BOOT
Session Level: 2 ( Start Programming Session have subfunction = 0x2)
SessionP2Server Max: 0.05
SessionP2StarServerMax: 1.0
Now press the "Export to ..... SWCD format " button ( Icon with the LEGO box and green arrow).
This will generate a "dcm.swcd" with the added "PROGRAMMING_SESSION"
Configure BswM
What we want to do here is configure the BswM so that upon detections of a mode switch of DcmEcuReset to
JUMPTOSYSSUPPLIERBOOTLOADER, it shall trigger a user callout function. In this function the necessary actions for initiating a programming
session are performed.
The steps required for the BswM configuration are shown in the picture below. The arrows represents either a reference or sub-object.
Page 52
So just
Follow the steps 1 through 6 to configure the BswM

Press the Export to swcd format button.
Connect
Page 53
In the root composition you must now connect the DcmEcuReset to the BswM port.
connect dcm.DcmEcuReset to bswm.modeNotificationPort_JumpToBootRequest
Export to arxml
If your project contains an artext project and a main project you will have have to export the merged model back to a *.arxml file .
Do this by:
Select the Autosar Navigator

In your artext project:
Open the Merged Model
Select all packages except ArcCore and Autosar.
Right-click, Export to AUTOSAR XML.
Save in your project
Page 54

Arccore User Documentation For Autosar 4.X Products

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Arccore User Documentation For Autosar 4.X Products

Uploaded by

Copyright:

Available Formats

ArcCore User Documentation for

AUTOSAR 4.x Products

Creating an Application Model

Creating an Ecu Configuration Project

Introduction to Complex Drivers

A guide on how to create create and design complex drivers

IO Hardware Abstraction Guide

A guide on how to IOHWAB.

Memory Protection Guide

Post Build Guide

A guide on how to use post build

Watchdog Configuration Guide

A guide on how to configure the Watchdog

A guide on how to configure PDU

Configuring the SPI

Low Power Mode Guide

Configure Jump from Application to Boot

Creating an Application Model

Introduction On this page:

Create Data Types

Create arxml File

Click File > New > Other

Create ARText swcd File

Click File > New > Other...

In the SWCD Editor import the SwBaseType by entering

Create an ImplementationDataType by entering

Create a Sender Receiver Interface with one Data Element by entering

Create Component Types

component application MyProducer {

below the package declaration at the top of the file

Create a Runnable inside the internalBehavior block by entering

Create a Timing Event inside the runnable block, by entering

Create an Implementation at the root level of the file, by entering

component application MyProducer {

internalBehavior MyProducerBehvior for MyProducer {

implementation MyProducerImplementation for

Create another Application Software Component Type, by entering

Create an Internal Behavior for it, by entering

Create an Implementation for it, by entering

component application MyProducer {

internalBehavior MyProducerBehvior for MyProducer {

implementation MyProducerImplementation for

component application MyConsumer {

internalBehavior MyConsumerBehavior for MyConsumer {

implementation MyConsumerImplementation for

Create an Ecu Extract

Create a Composition, by entering

Create Prototypes of the Software Components inside the composition, by entering

prototype MyProducer TheProducer

Create an ARText System Definition file

Create a system by entering

Point to the root composition inside the system, by entering

Create implementation mappings inside the system by entering

Creating an Ecu Configuration Project

Introduction On this page:

Import Application Model from SWCD

This section assumes you have done that tutorial

Open any swcd file in the example-application project

Create Ecu Configuration File

Connect to Ecu Extract

Introduction to Complex Drivers

The complex drivers may have three different interface categories:

Basic Software Modules Interfaces