Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
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.
This tutorial will show you how to set up an AUTOSAR project and include model objects.
This tutorial will show you how to create an Ecu configuration project.
Configuring PDU
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
Page 3
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Application Developer license - The features described in this document are included in the Application Developer license
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 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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Create ImplementationDataType
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
Page 5
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
}
}
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
The complete contents of the file should now look something like this
Page 6
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
package Example.Components
import Example.Interfaces.MySRInterface
import MyProducer.MyProducerBehvior
The complete contents of the file should now look something like this
Page 7
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
package Example.Components
import Example.Interfaces.MySRInterface
import MyProducer.MyProducerBehvior
import MyConsumer.MyConsumerBehavior
Page 8
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
composition MyComposition {
Create a Connector between the ports of the Components inside the composition, by
entering
connect TheProducer.MySenderPort to
TheConsumer.MyReceiverPort
The complete contents of the file should now look something like this
package Example.EcuExtract
import Example.Components.MyProducer
import Example.Components.MyConsumer
composition MyComposition {
connect TheProducer.MySenderPort to
TheConsumer.MyReceiverPort
}
The complete contents of the file should now look something like this
Page 9
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
To create an example application model, check out the Creating an Application Model tut
orial
Page 11
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
What's next?
Take a look at the Arctic Core reference for help on configuring the platform for your ECU
Page 12
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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.
More information is found in the Advanced Usage section of the BSW editor documentation. All
Page 13
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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.
Page 16
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
SEC_CODE Code
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>
Page 17
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
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.
That becomes
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Call Notes
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.
Page 19
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Page 20
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
ProtectionHook Description
return value
PRO_SHUTDOWN Shutdown
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.
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
Page 21
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
YES
The variable it tries to access is not in the right section.
Possible faults:
No
The software has a malfunction accesing memory outside allowed regions.
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")))
#ifdef Abc_START_SEC_VAR_CLEARED_UNSPECIFIED
PARTITION_NT_CLEARED
#endif
Page 22
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
/* .... */
Limitations
Feature Description
1.1
Page 23
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Page 24
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Consistency Check
Page 25
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
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)
Page 26
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Makefile Expand
# Add target to create hash file
source
all-mod += PreCompiledDataHash.h
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):
Page 27
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
The configuration generation will fail if the limits are exceeded, both in in the development project
and the post build project.
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.
Page 28
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
build_config.mk Expand
# Version of build system
source
REQUIRED_BUILD_SYSTEM_VERSION=1.0.0
# 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
PROJECTNAME=PostbuildProject
Page 29
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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).
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.
Page 31
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
The WdgMMode container has four types of sub containers that corresponds the different types of
supervisions, they are named WdgMAliveSupervision, WdgMDeadlineSupervision,
WdgMLocalStatusParam, and WdgMTriggers.
Modes
Reporting
Status
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Page 34
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
SPI defines Clock Polarity (CPOL) and Clock Phase ( CPHA). These can be translated to Autosar
wording as:
Page 38
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
Page 39
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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 */
Files
Spi.c
Spi_<arch>.c
Spi_internal.h
Spi.h
Units/Controllers
Page 40
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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)
Page 43
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Page 44
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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);
if (EcuMConf_EcuMWakeupSource_WakeupSourcePin & source) {
initPinForWakeup();
}
if (EcuMConf_EcuMWakeupSource_WakeupSourceRtc & source) {
initRTCforWakeup();
}
}
void EcuM_DisableWakeupSources(EcuM_WakeupSourceType source) {
if (EcuMConf_EcuMWakeupSource_WakeupSourcePin & 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 */
}
if (EcuMConf_EcuMWakeupSource_WakeupSourceRtc & source) {
uint32_t wkupSrc = WKUP_BITS_RTC;
WKUP.WRER.R &= ~wkupSrc;
WKUP.WIREER.R &= ~wkupSrc;
Page 45
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Introduction
Overview
Examples
Page 46
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
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
To be added at a later stage
STM32
To be added at a later stage
All of the files listed in the table can be copied to your own project.
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.
Copy a linkscript_<COMPILER>.ldf file to your project and rename it to for example linkscipt_gcc_mine.ldf
Page 47
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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.
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.
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
Page 49
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Page 50
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
Child Pages
Page 51
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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
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
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
So just
Connect
Page 53
Copyright © 2015, ArcCore
ArcCore User Documentation for AUTOSAR 4.x Products
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:
Page 54
Copyright © 2015, ArcCore