3 - TechnicalReference_XCPs
MICROSAR XCP
Technical Reference
Version 2.0.0
Authors
Andreas Herkommer
Status
Released
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Document Information History Author Date Version Remarks Andreas Herkommer 2017-02-13
1.00.00
Initial Version
Andreas Herkommer 2017-11-14
2.00.00
Added new API Xcp_SetStimMode
Reference Documents No. Source Title Version [1] AUTOSAR
AUTOSAR_SWS_XCP.pdf
2.3.0
[2] AUTOSAR
AUTOSAR_SWS_DET.pdf
3.4.1
[3] AUTOSAR
AUTOSAR_SWS_DEM.pdf
5.2.0
[4] AUTOSAR
AUTOSAR_BasicSoftwareModules.pdf
V1.0.0
[5] ASAM
ASAM_XCP_Part2-Protocol-Layer-Specification_V1-1-
V1.1
0.pdf
Scope of the Document This document describes the features, APIs, and integration of the XCP Protocol Layer.
This document does not cover the XCP Transport Layers for CAN, FlexRay and Ethernet,
which are available at Vector Informatik.
Further information about XCP on CAN, FlexRay and Ethernet Transport Layers can be
found in their documentation.
Please also refer to “The Universal Measurement and Calibration Protocol Family”
specification by ASAM e.V.
The XCP Protocol Layer is a hardware independent protocol that can be ported to almost
any hardware. Due to there are numerous combinations of micro controllers, compilers
and memory models it cannot be guaranteed that it will run properly on any of the above
mentioned combinations.
Please note that in this document the term Application is not used strictly for the user
software but also for any higher software layer, like e.g. a Communication Control Layer.
Therefore, Application refers to any of the software components using XCP.
The API of the functions is described in a separate chapter at the end of this document.
Info The source code of the XCP Protocol Layer, configuration examples and
documentation are available on the Internet at
www.vector-informatik.de in a functional
restricted form.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
2
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Caution
We have configured the programs in accordance with your specifications in the
questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector´s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
3
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Contents 1 Component History .................................................................................................... 10 2 Introduction................................................................................................................. 11
2.1 Architecture Overview ...................................................................................... 11 3 Functional Description ............................................................................................... 13
3.1 Features .......................................................................................................... 13
3.1.1 Deviations ........................................................................................ 13 3.1.2 Additions/ Extensions ....................................................................... 15 3.2 Initialization ...................................................................................................... 15 3.3 States .............................................................................................................. 15 3.4 Main Functions ................................................................................................ 16 3.5 Block Transfer Communication Model .............................................................. 16 3.6 Slave Device Identification ............................................................................... 17
3.6.1 XCP Station Identifier ....................................................................... 17 3.6.2 XCP Generic Identification ............................................................... 17 3.7 Seed & Key ...................................................................................................... 17 3.8 Checksum Calculation ..................................................................................... 18
3.8.1 Custom CRC calculation .................................................................. 18 3.9 Memory Access by Application ......................................................................... 18
3.9.1 Memory Read and Write Protection ................................................. 18 3.9.2 Special use case “Type Safe Copy” ................................................. 19 3.10 Event Codes .................................................................................................... 19 3.11 Service Request Messages ............................................................................. 20 3.12 User Defined Command ................................................................................... 20 3.13 Synchronous Data Transfer ............................................................................. 20
3.13.1 Synchronous Data Acquisition (DAQ) ............................................... 20 3.13.2 DAQ Timestamp ............................................................................... 21 3.13.3 Power-Up Data Transfer .................................................................. 21 3.13.4 Data Stimulation (STIM) ................................................................... 22 3.13.5 Bypassing ........................................................................................ 22 3.13.6 Data Acquisition Plug & Play Mechanisms ....................................... 22 3.13.7 Event Channel Plug & Play Mechanism ........................................... 23 3.13.8 Send Queue ..................................................................................... 23 3.13.9 Data consistency .............................................................................. 23 3.14 The Online Data Calibration Model .................................................................. 24
3.14.1 Page Switching ................................................................................ 24 3.14.2 Page Switching Plug & Play Mechanism .......................................... 24 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
4
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
3.14.3 Calibration Data Page Copying ........................................................ 24 3.14.4 Freeze Mode Handling ..................................................................... 24 3.15 Flash Programming .......................................................................................... 25
3.15.1 Flash Programming by the ECU’s Application .................................. 25 3.15.2 Flash Programming Plug & Play Mechanism ................................... 25 3.15.3 Flash Programming with a Flash Kernel ........................................... 26 3.16 Multi Core Support ........................................................................................... 26
3.16.1 Type Safe Copy ............................................................................... 26 3.16.2 DAQ/STIM with Multi Core ............................................................... 27 3.17 En- / Disabling the XCP module ....................................................................... 28 3.18 XCP measurement during the post event time ................................................. 28 3.19 Error Handling .................................................................................................. 29
3.19.1 Development Error Reporting ........................................................... 29 3.19.2 Production Code Error Reporting ..................................................... 30 4 Integration ................................................................................................................... 31
4.1 Scope of Delivery ............................................................................................. 31
4.1.1 Static Files ....................................................................................... 31 4.1.2 Templates – user modifiable ............................................................. 31 4.1.3 Dynamic Files .................................................................................. 31 4.1.4 Generated a2l files ........................................................................... 31 4.2 Critical Sections ............................................................................................... 32
4.2.1 XCP_EXCLUSIVE_AREA_0 ............................................................ 32 4.2.2 XCP_EXCLUSIVE_AREA_1 ............................................................ 32 4.2.3 XCP_EXCLUSIVE_AREA_2 ............................................................ 32 4.3 Memory Mapping ............................................................................................. 33 5 API Description ........................................................................................................... 34
5.1 Type Definitions ............................................................................................... 34 5.2 Services provided by XCP ............................................................................... 35
5.2.1 Xcp_InitMemory ............................................................................... 35 5.2.2 Xcp_Init ............................................................................................ 35 5.2.3 Xcp_Event ....................................................................................... 36 5.2.4 Xcp_StimEventStatus ...................................................................... 36 5.2.5 Xcp_MainFunction ........................................................................... 37 5.2.6 Xcp_SendEvent ............................................................................... 38 5.2.7 Xcp_PutChar.................................................................................... 38 5.2.8 Xcp_Print ......................................................................................... 39 5.2.9 Xcp_Disconnect ............................................................................... 39 5.2.10 Xcp_SendCrm .................................................................................. 40 5.2.11 Xcp_GetVersionInfo ......................................................................... 40 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
5
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.2.12 Xcp_ModifyProtectionStatus ............................................................ 41 5.2.13 Xcp_GetSessionStatus .................................................................... 42 5.2.14 Xcp_GetXcpDataPointer .................................................................. 42 5.2.15 Xcp_SetStimMode ........................................................................... 43 5.3 Services provided by the XCP Protocol Layer and called by the XCP
Transport Layer ................................................................................................ 43
5.3.1 Xcp_TlRxIndication .......................................................................... 43 5.3.2 Xcp_TlTxConfirmation ...................................................................... 44 5.3.3 Xcp_SetActiveTl ............................................................................... 44 5.3.4 Xcp_GetActiveTl .............................................................................. 45 5.4 XCP Transport Layer Services called by the XCP Protocol Layer .................... 46
5.4.1 <Bus>Xcp_Send .............................................................................. 46 5.4.2 <Bus>Xcp_SendFlush ..................................................................... 47 5.4.3 <Bus>Xcp_TlService ........................................................................ 47 5.5 Application Services called by the XCP Protocol Layer .................................... 48
5.5.1 XcpAppl_GetTimestamp .................................................................. 49 5.5.2 XcpAppl_GetPointer......................................................................... 49 5.5.3 XcpAppl_GetIdData ......................................................................... 50 5.5.4 XcpAppl_GetSeed ........................................................................... 51 5.5.5 XcpAppl_Unlock ............................................................................... 51 5.5.6 XcpAppl_CalibrationWrite ................................................................ 52 5.5.7 XcpAppl_MeasurementRead ........................................................... 53 5.5.8 XcpAppl_CheckReadAccess ............................................................ 53 5.5.9 XcpAppl_CheckProgramAccess....................................................... 54 5.5.10 XcpAppl_UserService ...................................................................... 54 5.5.11 XcpAppl_OpenCmdIf ....................................................................... 55 5.5.12 XcpAppl_SendStall .......................................................................... 55 5.5.13 XcpAppl_DisableNormalOperation ................................................... 56 5.5.14 XcpAppl_StartBootLoader ................................................................ 57 5.5.15 XcpAppl_Reset ................................................................................ 57 5.5.16 XcpAppl_ProgramStart .................................................................... 58 5.5.17 XcpAppl_FlashClear ........................................................................ 58 5.5.18 XcpAppl_FlashProgram ................................................................... 59 5.5.19 XcpAppl_DaqResume ...................................................................... 59 5.5.20 XcpAppl_DaqResumeStore ............................................................. 60 5.5.21 XcpAppl_DaqResumeClear ............................................................. 61 5.5.22 XcpAppl_CalResumeStore............................................................... 61 5.5.23 XcpAppl_GetCalPage ...................................................................... 62 5.5.24 XcpAppl_SetCalPage ....................................................................... 62 5.5.25 XcpAppl_CopyCalPage .................................................................... 63 5.5.26 XcpAppl_SetFreezeMode ................................................................ 64 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
6
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.5.27 XcpAppl_GetFreezeMode ................................................................ 65 5.5.28 XcpAppl_CalculateChecksum .......................................................... 65 5.5.29 XcpAppl_ConStateNotification ......................................................... 66 5.5.30 XcpAppl_MemCpy ........................................................................... 66 5.6 Services used by XCP ..................................................................................... 67 6 Configuration .............................................................................................................. 68
6.1 Configuration Variants ...................................................................................... 68 7 Glossary and Abbreviations ...................................................................................... 69
7.1 Abbreviations ................................................................................................... 69 8 Contact ........................................................................................................................ 71 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
7
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Illustrations Figure 2-1 AUTOSAR 4.1 Architecture Overview ....................................................... 11 Figure 2-2 Interfaces to adjacent modules of the XCP ............................................... 12 Figure 3-1 Connection State Machine ........................................................................ 16 Figure 3-2 Data consistency ...................................................................................... 23 Figure 3-3 Application of Xcp_Event function on Multi Core systems ......................... 28 Tables
Table 1-1 Component history.................................................................................... 10 Table 3-1 Supported AUTOSAR standard conform features ..................................... 13 Table 3-2 Deviations from AUTOSAR standard conform features ............................. 13 Table 3-3 Deviations from ASAM standard conform features .................................... 15 Table 3-4 Features provided beyond the AUTOSAR standard .................................. 15 Table 3-5 States ....................................................................................................... 15 Table 3-6 Event codes .............................................................................................. 20 Table 3-7 Service IDs ............................................................................................... 29 Table 3-8 Errors reported to DET ............................................................................. 30 Table 3-9 Errors reported to DEM ............................................................................. 30 Table 4-1 Static files ................................................................................................. 31 Table 4-2 Templates ................................................................................................. 31 Table 4-3 Generated files ......................................................................................... 31 Table 5-1 Type definitions ......................................................................................... 34 Table 5-2 Xcp_ChannelStruct ................................................................................... 34 Table 5-3 Xcp_InitMemory ........................................................................................ 35 4 Xcp_Init .................................................................................................... 35 Table 5-5 Xcp_Event ................................................................................................ 36 Table 5-6 Xcp_StimEventStatus ............................................................................... 37 Table 5-7 Xcp_MainFunction .................................................................................... 37 Table 5-8 Xcp_SendEvent ........................................................................................ 38 Table 5-9 Xcp_PutChar ............................................................................................ 39 Table 5-10 Xcp_Print .................................................................................................. 39 Table 5-11 Xcp_Disconnect ........................................................................................ 40 Table 5-12 Xcp_SendCrm .......................................................................................... 40 Table 5-13 Xcp_GetVersionInfo .................................................................................. 41 Table 5-14 Xcp_ModifyProtectionStatus ..................................................................... 41 Table 5-15 Xcp_GetSessionStatus ............................................................................. 42 Table 5-16 Xcp_GetXcpDataPointer ........................................................................... 43 Table 5-17 Xcp_SetStimMode .................................................................................... 43 Table 5-18 Xcp_TlRxIndication ................................................................................... 44 Table 5-19 Xcp_TlTxConfirmation .............................................................................. 44 Table 5-20 Xcp_SetActiveTl ....................................................................................... 45 Table 5-21 Xcp_GetActiveTl ....................................................................................... 46 Table 5-22 <Bus>Xcp_Send ....................................................................................... 46 Table 5-23 <Bus>Xcp_SendFlush .............................................................................. 47 Table 5-24 <Bus>Xcp_TlService ................................................................................ 48 Table 5-25 XcpAppl_GetTimestamp ........................................................................... 49 Table 5-26 XcpAppl_GetPointer ................................................................................. 50 Table 5-27 XcpAppl_GetIdData .................................................................................. 51 Table 5-28 XcpAppl_GetSeed .................................................................................... 51 Table 5-29 XcpAppl_Unlock ....................................................................................... 52 Table 5-30 XcpAppl_CalibrationWrite ......................................................................... 52 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
8
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Table 5-31 XcpAppl_MeasurementRead .................................................................... 53 Table 5-32 XcpAppl_CheckReadAccess .................................................................... 54 Table 5-33 XcpAppl_CheckProgramAccess ............................................................... 54 Table 5-34 XcpAppl_UserService ............................................................................... 55 Table 5-35 XcpAppl_OpenCmdIf ................................................................................ 55 Table 5-36 XcpAppl_SendStall ................................................................................... 56 Table 5-37 XcpAppl_DisableNormalOperation ........................................................... 56 Table 5-38 XcpAppl_StartBootLoader ........................................................................ 57 Table 5-39 XcpAppl_Reset ......................................................................................... 58 Table 5-40 XcpAppl_ProgramStart ............................................................................. 58 Table 5-41 XcpAppl_FlashClear ................................................................................. 59 Table 5-42 XcpAppl_FlashProgram ............................................................................ 59 Table 5-43 XcpAppl_DaqResume .............................................................................. 60 Table 5-44 XcpAppl_DaqResumeStore ...................................................................... 61 Table 5-45 XcpAppl_DaqResumeClear ...................................................................... 61 Table 5-46 XcpAppl_CalResumeStore ....................................................................... 62 Table 5-47 XcpAppl_GetCalPage ............................................................................... 62 Table 5-48 XcpAppl_SetCalPage ............................................................................... 63 Table 5-49 XcpAppl_CopyCalPage ............................................................................ 64 Table 5-50 XcpAppl_SetFreezeMode ......................................................................... 64 Table 5-51 XcpAppl_GetFreezeMode......................................................................... 65 Table 5-52 XcpAppl_CalculateChecksum ................................................................... 66 Table 5-53 XcpAppl_ConStateNotification .................................................................. 66 Table 5-54 XcpAppl_MemCpy .................................................................................... 67 Table 5-55 Services used by the XCP ........................................................................ 67 Table 7-1 Abbreviations ............................................................................................ 70 © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
9
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
1 Component History The component history gives an overview over the important milestones that are
supported in the different versions of the component.
Component Version New Features
1.00.xx
Initial Version of re-factored AR4 Protocol Layer.
2.00.xx
Series production of MultiCore feature.
3.00.xx
Bugfixes and Continuous STIM feature.
Table 1-1 Component history
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
10
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
2 Introduction This document describes the functionality, API and configuration of the AUTOSAR BSW
module XCP as specified in [1].
Supported AUTOSAR Release*: 4
Supported Configuration Variants: pre-compile
Vendor ID: XCP_VENDOR_ID
30 decimal
(= Vector-Informatik,
according to HIS)
Module ID: XCP_MODULE_ID
212 decimal
(according to ref. [4])
* For the detailed functional specification please also refer to the corresponding AUTOSAR SWS.
2.1 Architecture Overview The following figure shows where the XCP is located in the AUTOSAR architecture.
Figure 2-1 AUTOSAR 4.1 Architecture Overview
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
11
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
The following figure shows the interfaces to adjacent modules of the XCP. The interfaces
of the XCP Protocol Layer and the application call-back header are described in chapte
r 5. class Module Structure Adj acencyMust be implemented
Applicationby the user
XcpApplXCPDETXcpOnCanXcpOnFrXcpOnTcpIpCanIfFrIfSoAd Figure 2-2 Interfaces to adjacent modules of the XCP
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
12
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
3 Functional Description 3.1 Features The Universal Measurement and Calibration Protocol (XCP) is standardized by the
European ASAM working committee for standardization of interfaces used in calibration
and measurement data acquisition. XCP is a higher level protocol used for communication
between a measurement and calibration system (MCS, i.e. CANape) and an electronic
control unit (ECU). The implementation supports the ASAM XCP 1.1 Specification.
The AUTOSAR standard functionality is specified in [1], the corresponding features are
listed in the tables
> Table 3-1 Supported AUTOSAR standard conform features > Table 3-2 Deviations from AUTOSAR standard conform features > Table 3-3 Deviations from ASAM standard conform features Vector Informatik provides further XCP functionality beyond the AUTOSAR standard. The
corresponding features are listed in the table
> Table 3-4 Features provided beyond the AUTOSAR standard The following features specified in [1] are supported:
Supported AUTOSAR Standard Conform Features
ASAM XCP Version 1.1
Table 3-1 Supported AUTOSAR standard conform features
3.1.1 Deviations The following features specified in [1] are not or only partly supported:
Category Description ASR
Version Functional The following features are not supported:
4.2.2
• The command GET_SLAVE_ID
• A CDD as transport layer
API
The following APIs are not provided by XCP:
4.2.2
• Xcp_SetTransmissionMode
API
The API Xcp_<Module>TriggerTransmit is only supported for transport
4.2.2
layer FrIf.
Table 3-2 Deviations from AUTOSAR standard conform features
Category Description ASAM
Version Functional 1.6.4.1.2.4 Get general information on DAQ processor:
1.1
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
13
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
• Bitwise stimulation is not supported
Functional 1.6.4.2 Static DAQ list configuration (stat):
1.1
• Static DAQ lists are not supported; only dynamic DAQ lists are
supported
Functional 1.7.2.3 Interleaved Communication Model:
1.1
• Multiple request messages are not allowed to be transmitted by the
XCP master before receiving the corresponding response
message
Functional 1.6.5.2.4 Set Data Format before Programming:
1.1
• Only the default programming format is supported, therefore the
command PROGRAM_FORMAT is not supported
Functional 1.6.5.2.2 Get specific information for a sector:
1.1
• The command GET_SECTOR_INFO does not return a Program
Sequence Number
Functional 1.6.5.2.7 Program Verify:
1.1
• The command PROGRAM_VERIFY is not supported
Functional Daq configuration:
1.1
• Number of DAQ lists is limited to 0xFF
• Maximum DTO length is limited to 0xFF
• DAQ does not support address extension
• DAQ-list and event channel prioritization is not supported
• DAQ bit offset not supported
• The resume bits in DAQ lists are not set (no indication in response
of command GET_DAQ_LIST_MODE)
Functional 5.1.10 ODT Optimization:
1.2
• The ODT Optimization is not supported
Functional 1.2 Table of Event Codes:
1.1
• XCP does not send any event packet natively. If required, the
implementation has to be added to application
Functional Overload indication by an event is not supported
1.1
Functional 1.3 Table of Service Request Codes (SERV):
1.1
• The Service Request SERV_RESET is not supported
Functional 1.6.1.2.9 Build Checksum over memory range:
1.1
• The checksum type XCP_CRC_16 or XCP_CRC_32 is only supported
if the checksum calculation is forwarded to a AUTOSAR CRC
module
• Maximum checksum block size is 0xFFFF
Functional 1.6.3 Page Switching Commands (PAG):
1.1
• The command GET_PAGE_INFO is not supported
• The command GET_SEGMENT_INFO is not supported
• Only one segment and two pages are supported
Functional Seed and Key:
1.1
• The seed size and key size must be equal or less MAX_CTO-2
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
14
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Functional Consistency only supported on ODT level.
1.1
Functional No other identification field type supported than “absolute ODT number”.
1.1
Table 3-3 Deviations from ASAM standard conform features
3.1.2 Additions/ Extensions The following features are provided beyond the AUTOSAR standard:
Features Provided Beyond The AUTOSAR Standard
Support of CAN-FD
Support transmission and reception of DTO on multiple cores simultaneously.
Table 3-4 Features provided beyond the AUTOSAR standard
3.2 Initialization The XCP gets initialized by call of the following services:
•
5.2.1 Xcp_InitMemory
•
5.2.2 Xcp_Init Xcp_InitMemory has to be called if memory is not initialized by start-up code.
The EcuM takes care of initialization, if no EcuM is used these functions have to be called
by application in correct order.
3.3 States The XCP’s connection state machine is shown in
Figure 3-1, comprises the following
states:
State Name Description XCP_CON_STATE_DISCONNECTED In this state neither CTO nor DTO messages can be received or
transmitted, except of the Connect CTO.
XCP_CON_STATE_CONNECTED
In this state communication is fully supported.
XCP_CON_STATE_RESUME
In this state CTO messages (except of Connection CTO) are
rejected, whereas DTO messages can be received and
transmitted.
Table 3-5 States
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
15
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
stm Connection State MachineInitial
Xcp_Init
Resume Mode
[OFF]
[ON]
DISCONNECTEDXcp_CmdStd_Connect
CONNECTEDRESUMEXcp_CmdStd_Connect
Xcp_Disconnect
Figure 3-1 Connection State Machine
The states can be changed by the XCP master by sending the CTOs Connect and
Disconnect. Additionally, the connection can be broken by the service:
•
5.2.9 Xcp_Disconnect 3.4 Main Functions The Xcp provides a MainFunction:
•
5.2.5 Xcp_MainFunction It must be called cyclically and performs the following tasks:
> Checksum calculation which is done asynchronously in configurable chunks to prevent
extensive runtime
> Resume Mode Handling
The Xcp MainFunction is normally called by the SchM. If you use a 3rd party SchM you
must configure it accordingly such that the function is called cyclically.
3.5 Block Transfer Communication Model In the standard communication model, each request packet is responded by a single
response packet or an error packet. To speed up memory uploads, downloads and flash
programming the XCP commands UPLOAD, DOWNLOAD and PROGRAM support a block transfer
mode similar to ISO/DIS 15765-2.
In the Master Block Transfer Mode can the master transmit subsequent (up to the
maximum block size MAX_BS) request packets to the slave without getting any response
in between. The slave responds after transmission of the last request packet of the block.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
16
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
In Slave Block Transfer Mode the slave can respond subsequent (there is no limitation) to
a request without additional requests in between.
The Block Transfer Mode is limited to a block size of 255 Bytes. On bus systems with a
large max CTO (e.g. 254 Bytes) this Mode might be counterproductive and should stay
disabled.
3.6 Slave Device Identification 3.6.1 XCP Station Identifier The XCP station identifier is an ASCII string that identifies the ECU’s software program
version.
The MCS can interpret this identifier as file name for the ECU database. The ECU
developer should change the XCP station identifier with each program change. This will
prevent database mix-ups and grant the correct access of measurement and calibration
objects from the MCS to the ECU. Another benefit of the usage of the XCP station
identifier is the automatic assignment of the correct ECU database at program start of the
MCS via the plug & play mechanism. The plug & play mechanism prevents the user from
selecting the wrong ECU database.
3.6.2 XCP Generic Identification The XCP provides a generic mechanism for identification by the GET_ID command. For this
purpose a call-back exist which can be implemented by the user to provide the requested
information (see
5.5.3 XcpAppl_GetIdData). 3.7 Seed & Key The seed and key feature allows individual access protection for calibration, flash
programming, synchronous data acquisition and data stimulation. The MCS requests a
seed (a few data bytes) from the ECU and calculates a key based on a proprietary
algorithm and sends it back to the ECU.
If Seed & Key is enabled in the configuration tool the following APIs need to be
implemented by the user:
•
5.5.4 XcpAppl_GetSeed
•
5.5.5 XcpAppl_Unlock The XcpAppl_GetSeed call-back function returns a seed that is transferred to the MCS.
The XcpAppl_Unlock call-back function has to verify a received key based on the seed
and then return the resource that shall be unlocked.
The protection state can also individually be modified by the application. The following
service can be used for this purpose:
•
5.2.12 Xcp_ModifyProtectionStatus © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
17
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Note
Annotation for the usage of CANape:
The calculation of the key is done in a DLL, which is developed by the ECU
manufacturer and which must be located in the EXEC directory of CANape. CANape
can access the ECU only if the ECU accepts the key. If the key is not valid, the ECU
stays locked.
3.8 Checksum Calculation The XCP Protocol Layer supports calculation of a checksum over a specific memory
range. The XCP Protocol Layer supports all XCP ADD algorithms and the CRC16CCITT
checksum calculation algorithm. If the AUTOSAR CRC Module is used also the XCP
CRC32 algorithm can be used.
If checksum calculation is enabled the background task has to be called cyclically.
3.8.1 Custom CRC calculation The Protocol Layer also allows the calculation of the CRC by the application. For this the
call-back is called:
•
5.5.28 XcpAppl_CalculateChecksum This call-back can either calculate the checksum synchronously and return XCP_CMD_OK or
it can trigger the calculation and return XCP_CMD_PENDING for asynchronous calculation of
the checksum. In each case the response frame has to be assembled.
3.9 Memory Access by Application Memory access to measure or to calibrate variables is performed by two call-backs that
can be modified by the user to his needs. Please note that these API are only used for
polling access by default. DAQ/STIM uses direct memory access out of performance
reasons.
DAQ/STIM
access
via
these
call-backs
can
be
enabled
by
/MICROSAR/Xcp/XcpGeneral/XcpDAQMemAccessByApplication.
The following call-backs are called by the Protocol Layer whenever a memory access is
performed:
•
5.5.6 XcpAppl_CalibrationWrite
•
5.5.7 XcpAppl_MeasurementRead These APIs can be used to perform the memory access synchronously, asynchronously
(e.g. for EEPROM access), and they can deny the memory access, depending on the
return value.
3.9.1 Memory Read and Write Protection Memory protection can easily be performed by the two above mentioned call-backs
returning XCP_ERR_ACCESS_DENIED.
Additionally the configuration switch
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpMemoryReadProtection enables the call-
back:
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
18
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
•
5.5.8 XcpAppl_CheckReadAccess This call-back is required for other services like CRC calculation to check the requested
memory size beforehand.
As Flash programming uses a different memory access mechanism, a different set of call-
backs is used.
The configuration switch
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming/XcpProgrammingWriteProtection enables
the call-back:
•
5.5.9 XcpAppl_CheckProgramAccess This call-back can be used to check the memory range whenever a flash segment is
cleared or programmed.
3.9.2 Special use case “Type Safe Copy” The above mentioned APIs will also be used if the feature “Type Safe Copy” is enabled. If
this is the case polling as well as DAQ/STIM measurement will use these functions to
read/write data. The template code for these functions performs read/write access in an
atomic way for basic data types (e.g. uint16 / uint32).
3.10 Event Codes The slave device may report events by sending asynchronous event packets (EV), which
contain event codes, to the master device. The transmission is not guaranteed due to the
fact that these event packets are not acknowledged.
The transmission of event codes is enabled with the configuration switch
/MICROSAR/Xcp/XcpCmdConfig/XcpAsynchMessage/XcpEventCodes. The transmission is done
by the service:
•
5.2.6 Xcp_SendEvent. The event codes can be found in the following table.
Event Code Description XCP_EVC_RESUME_MODE
0x00
The slave indicates that it is starting in RESUME
mode.
XCP_EVC_CLEAR_DAQ
0x01
The slave indicates that the DAQ configuration in non-
volatile memory has been cleared.
XCP_EVC_STORE_DAQ
0x02
The slave indicates that the DAQ configuration has
been stored into non-volatile memory.
XCP_EVC_STORE_CAL
0x03
The slave indicates that the calibration data has been
stored.
XCP_EVC_CMD_PENDING
0x05
The slave requests the master to restart the time-out
detection.
XCP_EVC_DAQ_OVERLOAD
0x06
The slave indicates an overload situation when
transferring DAQ lists.
XCP_EVC_SESSION_TERMINATED 0x07
The slave indicates to the master that it autonomously
decided to disconnect the current XCP session.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
19
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
XCP_EVC_TIME_SYNC
0x08
Transfer of externally triggered timestamp.
XCP_EVC_STIM_TIMEOUT
0x09
Indication of a STIM timeout.
XCP_EVC_SLEEP
0x0A
Slave entering SLEEP mode.
XCP_EVC_WAKE_UP
0x0B
Slave leaving SLEEP mode.
XCP_EVC_USER
0xFE
User-defined event.
XCP_EVC_TRANSPORT
0xFF
Transport layer specific event.
Table 3-6 Event codes
3.11 Service Request Messages The slave device may request some action to be performed by the master device. This is
done by the transmission of a Service Request Packet (SERV) that contains the service
request code. The transmission of service request packets is asynchronous and not
guaranteed because these packets are not acknowledged.
The service request messages can be sent by the following functions:
•
5.2.7 Xcp_PutChar
•
5.2.8 Xcp_Print 3.12 User Defined Command The XCP Protocol allows having a user defined command with an application specific
functionality.
The
user
defined
command
is
enabled
by
setting
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpUserDefinedCommand and upon reception of
the user command the following callback function is called by the XCP command
processor:
•
5.5.10 XcpAppl_UserService 3.13 Synchronous Data Transfer 3.13.1 Synchronous Data Acquisition (DAQ)
The
synchronous
data
transfer
can
be
enabled
with
the
container
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim. In this mode, the MCS configures tables of
memory addresses in the XCP Protocol Layer. These tables contain pointers to
measurement objects, which have been configured previously for the measurement in the
MCS. Each configured table is assigned to an event channel.
The function Xcp_Event(x) has to be called for each event channel with the corresponding
event channel number as parameter. The application has to ensure that Xcp_Event is
called with the correct cycle time. Note that the event channel numbers are given by the
GenTool by configuring /MICROSAR/Xcp/XcpConfig/XcpEventChannel. Symbolic name
values for each event channel are generated by the GenTool.
The ECU automatically transmits the current value of the measurement objects via
messages to the MCS, when the function Xcp_Event is executed in the ECU’s code with
the corresponding event channel number. This means that the data can be transmitted at
any particular point of the ECU code when the data values are valid.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
20
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
The data acquisition mode can be used in multiple configurations that are described within
the next chapters.
Note
Annotation for the usage of CANape:
It is recommended to enable both data acquisition plug & play mechanisms to detect
the DAQ settings.
3.13.2 DAQ Timestamp
There are two methods to generate timestamps for data acquisition signals.
1. By the MCS tool on reception of the message
2. By the ECU (XCP slave)
The time precision of the MCS tool is adequate for the most applications; however, some
applications like the monitoring of the OSEK operating system or measurement on
FlexRay with an event cycle time smaller than the FlexRay cycle time require higher
precision timestamps. In such cases, ECU generated timestamps are recommended.
The timestamp must be implemented in a call-back which returns the current value:
•
5.5.1 XcpAppl_GetTimestamp There are several possibilities to implement such a timestamp:
> 16bit Counter variable, incremented by software in a fast task (.e.g. 1ms task) for
applications where such a resolution is sufficient and returned in the above mentioned
call-back.
> 32bit General Purpose Timer of the used µC, configured to a certain repetition rate
(e.g. 1µs increment) for applications that require a high resolution of the timestamp
and returned in the above mentioned call-back.
The resolution and increment value of this timer must be configured in the configuration
tool accordingly.
3.13.3 Power-Up Data Transfer
Power-up data transfer (also called resume mode) allows automatic data transfer (DAQ) of
the slave directly after power-up. Automotive applications would e.g. be measurements
during cold start.
The slave and the master have to store all the necessary communication parameters for
the automatic data transfer after power-up. Therefore the following functions have to be
implemented in the slave.
•
5.5.19 XcpAppl_DaqResume
•
5.5.20 XcpAppl_DaqResumeStore
•
5.5.21 XcpAppl_DaqResumeClear © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
21
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
To
use
the
resume
mode
the
compiler
switch
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpResumeMode has to be enabled.
Keep also in mind that the Xcp_MainFunction has to be called cyclically in order for the
resume mode to work. If Resume Mode is enabled by the MCS tool the before mentioned
call-back XcpAppl_DaqResumeStore is called by the Xcp_MainFunction.
Note
Annotation for the use of CANape:
Start the resume mode with the menu command Measurement | Start and push the
button “Measure offline” on the dialog box.
3.13.4 Data Stimulation (STIM)
Synchronous Data Stimulation is the inverse mode of Synchronous Data Acquisition.
The STIM processor buffers incoming data stimulation packets. When an event occurs
(Xcp_Event is called), which triggers a DAQ list in data stimulation mode, the buffered
data is transferred to the slave device’s memory.
To
use
data
stimulation
(STIM)
the
configuration
switch
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpSynchronousDataStimulation has to be
enabled.
With the AP
I Xcp_SetStimMode the mode of the write operation can be selected.
3.13.5 Bypassing
Bypassing can be realized by making use of Synchronous Data Acquisition (DAQ) and
Synchronous Data Stimulation (STIM) simultaneously.
State-of-the-art Bypassing also requires the administration of the bypassed functions. This
administration has to be performed in a MCS like e.g. CANape.
Also the slave should perform plausibility checks on the data it receives through data
stimulation. The borders and actions of these checks are set by standard calibration
methods. No special XCP commands are needed for this.
3.13.6 Data Acquisition Plug & Play Mechanisms
The XCP Protocol Layer comprises two plug & play mechanisms for data acquisition:
> General information on the DAQ processor
> General information on DAQ processing resolution
The general information on the DAQ processor contains:
> General properties of DAQ lists
> Total number of available DAQ lists and event channels
The general information on the DAQ processing resolution contains:
> Granularity and maximum size of ODT entries for both directions
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
22
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
> Information on the time stamp mode
3.13.7 Event Channel Plug & Play Mechanism
The XCP Protocol Layer supports a plug & play mechanism that allows the MCS to
automatically detect the available event channels in the slave. The associated service is
enabled by /MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpGetDAQEventInfo.
If this option is enabled the MCS can read the configured Event Channels from the XCP
Slave.
3.13.8 Send Queue
The Send Queue is used to store measurement values until they can be transmitted on the
bus. The Send Queue size can be configured in the configuration tool. It is defined by the
parameter /MICROSAR/Xcp/XcpConfig/XcpCoreDefinition/XcpSendQueueSize. Please be
aware that in a Multi Core system multiple Send Queues may be configured. Each Core
the Xcp_Event function is called on requires its own Send Queue. The sizes may vary,
depending on the number of measurement values on each Core. See chapte
r 3.16 Multi
Core Support. 3.13.9 Data consistency
The XCP supports a data consistency on ODT level. If a consistency on DAQ level is
required, interrupts must be disabled prior calling Xcp_Event and enabled again after the
function returns. The following example demonstrates the integrity on ODT level by
showing the XCP ODT frames as sent on the bus. Two Events (x, y) are configured with
DAQ list DAQ1 assigned to Event(x) and DAQ list DAQ2 assigned to Event(y). A call of the
Xcp_Event function with the respective event channel number will then trigger the
transmission of the associated DAQ list.
Example1: a call of Xcp_Event(x) is interrupted by a call of Xcp_Event(y). This is allowed
as long as the interrupt locks are provided by the Schedule Manager (default with
MICROSAR stack).
Example2: a call of Xcp_Event(x) is interrupted by a call of Xcp_Event(x). As a result a
DAQ list is interrupted by itself. This is not allowed and must be prevented by data
consistency on DAQ level. For this use a interrupt lock when calling Xcp_Event()
DAQ1
DAQ2
ODT0
ODT3
ODT1
ODT4
ODT2
Example1
ODT0 ODT1 ODT3 ODT4 ODT2
Example2
ODT0 ODT1 ODT0 ODT1 ODT2 ODT2
Figure 3-2 Data consistency
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
23
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Note on Multi Core systems: It is in the responsibility of the user to assign only
measurement values relevant for the Core to the corresponding Event Channel called on
the specific Core.
3.14 The Online Data Calibration Model 3.14.1 Page Switching
The MCS can switch between a flash page and a RAM page. The XCP command
SET_CAL_PAGE is used to activate the required page. The page switching is enabled with
the /MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching definition.
The following application callback functions have to be implemented:
•
5.5.23 XcpAppl_GetCalPage
•
5.5.24 XcpAppl_SetCalPage
Note
Annotation for the use of CANape:
Open the dialog XCP Device Setup with the menu command Tools|Driver
Configuration. Go to the tab “FLASH”. Activate page switching. Enter a flash selector
value e.g. 1 and a Ram selector e.g. 0.
3.14.2 Page Switching Plug & Play Mechanism
The MCS can be automatically configured if the page switching plug & play mechanism is
used. This mechanism comprises
> General information about the paging processor
The page switching plug & play mechanism is enabled with the switch
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpGeneralPagingInfo.
3.14.3 Calibration Data Page Copying
Calibration data page copying is performed by the XCP command COPY_CAL_PAGE. To
enable
this
feature
the
compiler
switch
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpCopyPage has to be enabled.
For calibration data page copying the following application callback function has to be
provided by the application:
•
5.5.25 XcpAppl_CopyCalPage 3.14.4 Freeze Mode Handling
Freeze mode handling is performed by the XCP commands SET_SEGMENT_MODE and
GET_SEGMENT_MODE.
To
enable
this
feature
the
parameter
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpFreezeMode has to be enabled.
For freeze mode handling the following application callback functions have to be provided
by the application:
•
5.5.26 XcpAppl_SetFreezeMode © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
24
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
•
5.5.27 XcpAppl_GetFreezeMode
•
5.5.22 XcpAppl_CalResumeStore 3.15 Flash Programming There are two methods available for the programming of flash memory.
> Flash programming by the ECU’s application
> Flash programming with a flash kernel
Depending on the hardware it might not be possible to reprogram an internal flash sector,
while a program is running from another sector. In this case the usage of a special flash
kernel is necessary.
3.15.1 Flash Programming by the ECU’s Application
If the internal flash has to be reprogrammed and the microcontroller allows to
simultaneously reprogram and execute code from the flash the programming can be
performed with the ECU’s application that contains the XCP. This method is also used for
the programming of external flash.
The flash programming is done with the following XCP commands PROGRAM_START,
PROGRAM_RESET, PROGRAM_CLEAR, PROGRAM, PROGRAM_NEXT, PROGRAM_MAX, PROGRAM_RESET,
PROGRAM_FORMAT1, PROGRAM_VERIFY1.
The flash prepare, flash program and the clear routines are platform dependent and
therefore have to be implemented by the application.
•
5.5.15 XcpAppl_Reset
•
5.5.16 XcpAppl_ProgramStart
•
5.5.17 XcpAppl_FlashClear
•
5.5.18 XcpAppl_FlashProgram The
flash
programming
is
enabled
with
the
switch
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming.
Note
Annotation for the usage of CANape:
Open the dialog XCP Device Setup with the menu command Tools|Driver
Configuration. Go to the tab “FLASH” and select the entry “Direct” in the flash kernel
drop down list.
3.15.2 Flash Programming Plug & Play Mechanism
The MCS (like e.g. CANape) can get information about the Flash and the Flash
programming process from the ECU. The following information is provided by the ECU:
1 Command not supported
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
25
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
> Number of sectors, start address or length of each sector
> The program sequence number, clear sequence number and programming method
> Additional information about compression, encryption
The flash programming plug & play mechanism is enabled with the switch
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming/XcpSector.
3.15.3 Flash Programming with a Flash Kernel
A flash kernel has to be used for the flash programming if it is not possible to
simultaneously reprogram and execute code from the flash. Even though the
reprogrammed sector and the sector the code is executed from are different sectors.
The application callback function
•
5.5.13 XcpAppl_DisableNormalOperation
•
5.5.14 XcpAppl_StartBootLoader is called prior to the flash kernel download in the RAM. Within this function the normal
operation of the ECU has to be stopped and the flash kernel download can be prepared.
Due to the flash kernel is downloaded in the RAM typically data gets lost and no more
normal operation of the ECU is possible.
The flash programming with a flash kernel is enabled with the switch
/MICROSAR/Xcp/XcpGeneral/XcpBootloaderDownload.
Note
Annotation for the usage of CANape:
The flash kernel is loaded by CANape into the microcontroller’s RAM via XCP
whenever the flash memory has to be reprogrammed. The flash kernel contains the
necessary flash routines, its own CAN-Driver and XCP Protocol implementation to
communicate via the CAN interface with CANape.
Every flash kernel must be customized to the microcontroller and the flash type being
used. CANape already includes some flash kernels for several microcontrollers. There
is also an application note available by Vector Informatik GmbH that describes the
development of a proprietary flash kernel.
Open the dialog XCP Device Setup with the menu command Tools|Driver
Configuration. Go to the tab “FLASH”, and select in the ‘flash kernel’ drop down list, the
corresponding
fkl file for the microcontroller being used.
3.16 Multi Core Support 3.16.1 Type Safe Copy
The XCP Protocol Layer supports a feature called “Type Safe Copy” which provides
atomic access to aligned uint16 and uint32 measurement values. This is important on multi
core platforms where one core is accessing a measurement value while the XCP is trying
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
26
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
to do the same running from another core. The Type Safe Copy is used for polling while
DAQ/STIM usually use direct memory access and copy byte wise.
With this option disabled, all access to measurement values is performed byte wise which
is not an atomic operation.
The following points must be taken into consideration when enabling this option:
> This option allows the XCP to only read/write basic data types used on another core; it
cannot provide data consistency on ODT level.
> This option has a slightly higher runtime.
> Some MCS tools perform an optimization by grouping measurement values. This
option must be disabled; otherwise they do not represent unique data types anymore.
3.16.2 DAQ/STIM with Multi Core
It is possible to execute the Xcp_Event function on a different Core. This must be
configured in the configuration tool accordingly. For each Core the XCP is used on the
following Container must be created: /MICROSAR/Xcp/XcpConfig/XcpCoreDefinition. The
correct Core Definition must be referenced for each configured Event Channel:
/MICROSAR/Xcp/XcpConfig/XcpEventChannel/XcpEventChannelCoreRef. An Event Channel
can only be called on the Core it is configured for; otherwise a DET error is thrown.
The following picture shows the architecture behind the Multi Core support and the way
the Xcp_Event function is called on each Core:
act Activ ityOsTask
OsTask BSW
Application
OsTask
Core
Core
Utility Core
Calculation of Application DataCalculation of Utility DataCollecting Data «datastore»
Xcp_Ev ent(5ms_ApplicationCore)Lock free Core
Specific QueueXcp_MainFunction (Trigger Sequential Transmission)ActivityFinal
Collecting Data «datastore»
Xcp_Ev ent(5ms_UtilityCore)Lock free Core
Specific QueueActivityFinal
ActivityFinal
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
27
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Figure 3-3 Application of Xcp_Event function on Multi Core systems
3.17 En- / Disabling the XCP module The macro XCP_ACTIVATE/XCP_DEACTIVATE can be used to en- or disable the XCP module
during run time. Thus the XCP functionality can be controlled by the application. These
macros control the protocol and transport layer together, i.e. enabling or disabling them as
a whole. It is recommended to perform a Xcp_Disconnect() API call to bring the XCP in a
save state before it is disabled.
3.18 XCP measurement during the post event time In use cases where there is no further communication request except XCP measurement
the session state of the XCP can be determined to prevent an early shutdown of the ECU.
For this purpose the following API exist:
•
5.2.13 Xcp_GetSessionStatus An example implementation that is called cyclically could look like the following example:
Example
{
uint16 sessionState;
sessionState = Xcp_GetSessionStatus();
if( 0 != (sessionState & XCP_SESSION_CONNECTED) )
{
/* Is the xcp actively used? */
if( 0 != (sessionState & (XCP_SESSION_DAQ | XCP_SESSION_POLLING)) )
{
/* Yes, reload timer */
swTimer = XCPAPPL_TIMEOUT_TIMER_RELOAD;
}
}
if( swTimer > 0 )
{
/* No timeout so far */
swTimer--;
}
else
{
/* Timer timeout happened, release xcp communication request */
}
}
Please note that polling requests may happen erratically. Therefore it is important not to
choose the timeout value XCP_TIMEOUT_TIMER_RELOAD too small.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
28
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
3.19 Error Handling 3.19.1 Development Error Reporting
By default, development errors are reported to the DET using the service
Det_ReportError() as specified in [2], if development error reporting is enabled:
/MICROSAR/Xcp/XcpGeneral/XcpDevErrorDetect.
If another module is used for development error reporting, the function prototype for
reporting the error can be configured by the integrator, but must have the same signature
as the service Det_ReportError().
The reported XCP ID is 212.
The reported service IDs identify the services which are described
in 5.2. The following
table presents the service IDs and the related services:
Service ID Service 0x00
Xcp_Init
0x03
Xcp_SendEvent
0x04
Xcp_PutChar
0x05
Xcp_Print
0x06
Xcp_Disconnect
0x07
Xcp_SendCrm
0x08
Xcp_GetXcpDataPointer
0x0A
Xcp_GetVersionInfo
0x0B
Xcp_TlRxIndication
0x0C
Xcp_TlTxConfirmation
0x0E
Xcp_GetSessionStatus
0x0F
Xcp_SetActiveTl
0x10
Xcp_GetActiveTl
0x11
Xcp_SetStimMode
0x14
Xcp_ModifyProtectionStatus
0xC8
Xcp_MainFunction
0xC9
Xcp_Event
0xFD
Xcp_StimEventStatus
Table 3-7 Service IDs
The errors reported to DET are described in the following table:
Error Code Description 0x0A
API service Xcp_Init() called with wrong parameter.
0x0B
API service used with an invalid channel identifier or channel was not configured
for the functionality of the calling API.
0x0C
API service used with an invalid event channel identifier or event channel was
not configured for the functionality of the calling API.
0x0D
API service used with invalid pointer parameter (NULL).
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
29
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Error Code Description 0x0E
API service used with an invalid channel identifier or channel was not configured
for the functionality of the calling API.
0x10
API service used without module initialization.
0x11
The service Xcp_Init() is called while the module is already initialized.
0x12
The service Xcp_Event() is called with a wrong channel id on a wrong core.
Table 3-8 Errors reported to DET
3.19.2 Production Code Error Reporting
The errors reported to DEM are described in the following table:
Error Code Description -
No production errors are reported by the XCP.
Table 3-9 Errors reported to DEM
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
30
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
4 Integration This chapter gives necessary information for the integration of the MICROSAR XCP into
an application environment of an ECU.
4.1 Scope of Delivery The delivery of the XCP contains the files which are described in the chapters
4.1.1 and
4.1.3: 4.1.1 Static Files File Name Description Xcp.c
This is the source file of the XCP. It contains the XCP protocol layer.
Xcp.h
This is the header file. It contains global declarations.
Xcp_Priv.h
This is the private header file. It contains declarations only relevant for the XCP
itself.
Xcp_Types.h This is the type definition header file. It contains type definitions used by the XCP.
Table 4-1 Static files
4.1.2 Templates – user modifiable File Name Description XcpAppl.c
This is the source file of the application call-back. This file usually must be
modified by the user to his needs.
XcpAppl.h
This is the header file of the application call-backs. It contains global declarations.
Table 4-2 Templates
4.1.3 Dynamic Files The dynamic files are generated by the configuration tool.
File Name Description Xcp_Cfg.h
XCP Protocol Layer configuration file.
Xcp_Lcfg.c
Parameter definition for the XCP Protocol Layer.
Xcp_Lcfg.h
External declarations for the parameters.
Table 4-3 Generated files
4.1.4 Generated a2l files The GenTool also generates multiple a2l files which can be used in the MCS tool for easier
integration. The following files are generated:
• XCP.a2l (general protocol layer settings)
• XCP_daq.a2l (DAQ specific settings)
• XCP_events.a2l (DAQ event info)
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
31
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
• XCP_Checksum.a2l (Checksum information)
Example Master.a2l:
...
/begin IF_DATA XCP
/include XCP.a2l
/begin DAQ
/include XCP_daq.a2l
/include XCP_events.a2l
/include XCP_checksum.a2l
...
/end DAQ
/include CanXCPAsr.a2l
/end IF_DATA
...
/include bsw.a2l
...
4.2 Critical Sections The XCP protocol layer makes use of three critical sections in order to protect functions
that are not re-entrant. The following sections are used:
• XCP_EXCLUSIVE_AREA_0
• XCP_EXCLUSIVE_AREA_1
• XCP_EXCLUSIVE_AREA_2
The individual exclusive areas must not be allowed to interrupt each other. The areas are
used for the following cases:
4.2.1 XCP_EXCLUSIVE_AREA_0 This exclusive area is used to protect non-reentrant functions. This critical section covers
calls to several sub-functions and can have a long run-time.
4.2.2 XCP_EXCLUSIVE_AREA_1 This exclusive area is used by Xcp_Event during DAQ measurement. It is used to provide
data integrity on ODT level and its duration is dependent on the MAX_DTO parameter, i.e.
can be short on CAN and long on Ethernet.
4.2.3 XCP_EXCLUSIVE_AREA_2 This exclusive area is used by Xcp_Event during STIM measurement. It is used to provide
data integrity on ODT level and its duration is dependent on the MAX_DTO parameter, i.e.
can be short on CAN and long on Ethernet.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
32
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
4.3 Memory Mapping The XCP has requirements regarding memory mapping to avoid misaligned memory
access. The following section: XCP_START_SEC_VAR_NOCACHE_NOINIT_32BIT must be mapped to a
32Bit section in order to guarantee correct alignment.
Caution
If this section is not mapped accordingly, a trap will happen on architectures that do not
support misaligned access, e.g. TriCore.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
33
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5 API Description For an interfaces overview please see
Figure 2-2. 5.1 Type Definitions The types defined by the XCP are described in this chapter.
Type Name C-Type Description Xcp_TimestampType
c-type
This is a type used for timestamp values. Its size is depending
on the configuration in the tool and can be uint8, uint16 or
uint32.
Table 5-1 Type definitions
Xcp_ChannelStruct Struct Element Name C-Type Description Xcp_ChannelStruct
c-type
This is a complex structure containing all the configuration
data of the XCP. This structure needs to be stored in NVM for
resume mode.
Table 5-2 Xcp_ChannelStruct
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
34
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.2 Services provided by XCP 5.2.1 Xcp_InitMemory Prototype void
Xcp_InitMemory ( void )
Parameter -
-
Return code -
-
Functional Description This service initializes the XCP Protocol Layer memory. It must be called from the application program
before any other XCP function is called. This is only required if the Startup Code does not initialize the
memory with zero.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is reentrant.
> The global interrupts have to be disabled while this service function is executed. This function should be
called during initialization of the ECU before the interrupts have been enabled.
Expected Caller Context
> Task and interrupt level
Table 5-3 Xcp_InitMemory
5.2.2 Xcp_Init Prototype void
Xcp_Init ( void )
Parameter -
-
Return code -
-
Functional Description
This service initializes the XCP Protocol Layer and its internal variables. It must be called from the
application program before any other XCP function is called (except of Xcp_InitMemory).
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
Expected Caller Context
> Task level
4 Xcp_Init
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
35
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.2.3 Xcp_Event Prototype uint8
Xcp_Event ( uint16 EventChannel )
Parameter EventChannel
Number of event channels to process.
The event channel numbers have to start at 0 and have to be continuous. The
range is: 0..x
Return code uint8
XCP_EVENT_NOP : Inactive (DAQ not running, Event not configured)
XCP_EVENT_DAQ : DAQ active */
XCP_EVENT_DAQ_OVERRUN : DAQ queue overflow, data lost
XCP_EVENT_STIM : STIM active
XCP_EVENT_STIM_OVERRUN : STIM data not available
Functional Description
Calling Xcp_Event with a particular event channel number triggers the sampling and transmission of all
DAQ lists that are assigned to this event channel.
The event channels are defined by the ECU developer in the application program. An MCS (e.g. CANape)
must know about the meaning of the event channel numbers. These are usually described in the tool
configuration files or in the interface specific part of the ASAM MC2 (ASAP2) database.
Example:
A motor control unit may have a 10ms, a 100ms and a crank synchronous event channel. In this case, the
three Xcp_Event calls have to be placed at the appropriate locations in the ECU’s program:
Xcp_Event (XcpConf_XcpEventChannel_10ms); /* 10ms cycle */
xcp_Event (XcpConf_XcpEventChannel_100ms); /* 100ms cycle */
xcp_Event (XcpConf_XcpEventChannel_Crank); /* Crank synchronous cycle */
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is reentrant (for different Event Channel).
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
> Data acquisition has to be enabled
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim
Expected Caller Context
> Task and interrupt level
Table 5-5 Xcp_Event
5.2.4 Xcp_StimEventStatus Prototype uint8
Xcp_StimEventStatus ( uint16 EventChannel, uint8 Action )
Parameter EventChannel
Event channel number.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
36
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Action
STIM_CHECK_ODT_BUFFER : check ODT buffer
STIM_RESET_ODT_BUFFER : reset ODT buffer
Return code uint8
XCP_NO_STIM_DATA_AVAILABLE : stimulation data not available
XCP_STIM_DATA_AVAILABLE : new stimulation data is available
Functional Description
Check if data stimulation (STIM) event can perform or delete the buffers.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is reentrant.
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
> Data acquisition has to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpSynchronousDataStimulation
Expected Caller Context
> Task and interrupt level
Table 5-6 Xcp_StimEventStatus
5.2.5 Xcp_MainFunction Prototype void
Xcp_MainFunction ( void )
Parameter -
-
Return code -
-
Functional Description
If the XCP command for the calculation of the memory checksum has to be used for large memory areas, it
might not be appropriate to block the processor for a long period of time. Therefore, the checksum
calculation is divided into smaller sections that are handled in the Xcp_MainFunction.
Additionally, the main function handles persisting requests.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has been initialized correctly
Expected Caller Context
> Task level
Table 5-7 Xcp_MainFunction
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
37
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.2.6 Xcp_SendEvent Prototype void
Xcp_SendEvent ( Xcp_ChannelType XcpChannel, uint8 EventCode, uint8
*EventData, uint8 Length )
Parameter XcpChannel
The channel number in multi client mode.
EventCode
The event code of the message to send.
EventData
A pointer to the string of the event to send.
Length
The length of the event data.
Return code -
-
Functional Description
Transmission of event codes via event packets (EV).
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
> Event Codes has to be enabled: /MICROSAR/Xcp/XcpCmdConfig/XcpAsynchMessage/XcpEventCodes
Expected Caller Context
> Task level
Table 5-8 Xcp_SendEvent
5.2.7 Xcp_PutChar Prototype void
Xcp_PutChar ( Xcp_ChannelType XcpChannel, uint8 *Character )
Parameter XcpChannel
The channel number in multi client mode.
Character
The char to send.
Return code -
-
Functional Description
Put a char into a service request packet (SERV).
The service request packet is transmitted if either the maximum packet length is reached (the service
request message packet is full) or the character 0x00 is in the service request packet.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
38
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
> Service Request Message has to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpAsynchMessage/XcpServiceRequestMessage
Expected Caller Context
> Task level
Table 5-9 Xcp_PutChar
5.2.8 Xcp_Print Prototype void
Xcp_Print ( Xcp_ChannelType XcpChannel, uint8 *Str )
Parameter XcpChannel
The channel number in multi client mode.
Str
The 0 terminated string to send.
Return code -
-
Functional Description
Transmission of a service request packet (SERV).
The string str is sent via service request packets. The string has to be terminated by 0x00.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
> Service Request Message has to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpAsynchMessage/XcpServiceRequestMessage
Expected Caller Context
> Task level
Table 5-10 Xcp_Print
5.2.9 Xcp_Disconnect Prototype void
Xcp_Disconnect ( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
39
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code -
-
Functional Description
If the XCP slave is connected to a XCP master a call of this function discontinues the connection (transition
to disconnected state). If the XCP slave is not connected this function performs no action.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is reentrant.
> The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
Expected Caller Context
> Task level
Table 5-11 Xcp_Disconnect
5.2.10 Xcp_SendCrm Prototype void
Xcp_SendCrm ( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code -
-
Functional Description
Transmission of a command response packet (RES), or error packet (ERR) if no other packet is pending.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has been initialized correctly, XCP is in connected state and a command
packet (CMD) has been received.
Expected Caller Context
> Task level
Table 5-12 Xcp_SendCrm
5.2.11 Xcp_GetVersionInfo Prototype void
Xcp_GetVersionInfo ( Std_VersionInfoType *versionInfo )
Parameter versionInfo
Pointer to the location where the Version information shall be stored.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
40
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code -
-
Functional Description
Xcp_GetVersionInfo() returns version information, vendor ID and AUTOSAR module ID of the component.
The versions are BCD-coded.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is reentrant.
> The version info API has to be enabled: /MICROSAR/Xcp/XcpGeneral/XcpVersionInfoApi
Expected Caller Context
> Task level
Table 5-13 Xcp_GetVersionInfo
5.2.12 Xcp_ModifyProtectionStatus Prototype void
Xcp_ModifyProtectionStatus ( Xcp_ChannelType XcpChannel, uint8 AndState,
uint8 OrState )
Parameter XcpChannel
The channel number in multi client mode.
AndState
The following flags: XCP_RM_CAL_PAG, XCP_RM_DAQ, XCP_RM_STIM
and XCP_RM_PGM can be used to clear the protection state of the respective
resource. The modified state is persistent until Xcp_Init.
OrState
The following flags: XCP_RM_CAL_PAG, XCP_RM_DAQ, XCP_RM_STIM
and XCP_RM_PGM can be used to set the protection state of the respective
resource. The modified state is persistent until Xcp_Init.
Return code -
-
Functional Description
This method can be used to enable or disable the protection state of an individual resource during runtime.
The newly set protection state is persistent until the next call of the Xcp_Init function where all flags are set
again.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> Seed&Key has to be enabled: /MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpSeedKey
Expected Caller Context
> Task level
Table 5-14 Xcp_ModifyProtectionStatus
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
41
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.2.13 Xcp_GetSessionStatus Prototype uint16
Xcp_GetSessionStatus ( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code uint16
The function returns a bit mask with the following flags:
XCP_SESSION_CONNECTED: The XCP is in state connected.
XCP_SESSION_POLLING: A polling measurement is ongoing.
XCP_SESSION_DAQ: A DAQ measurement is active.
Functional Description
This service can be used to get the session state of the XCP Protocol Layer. The session state is returned
as a bit mask where the individual bits can be tested.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> Session Status API has to be enabled: /MICROSAR/Xcp/XcpGeneral/XcpSessionStatusAPI
Expected Caller Context
> Task level
Table 5-15 Xcp_GetSessionStatus
5.2.14 Xcp_GetXcpDataPointer Prototype
uint16
Xcp_GetXcpDataPointer ( Xcp_ChannelStructPtr * pXcpData )
Parameter pXcpData
Pointer to XCP channel information.
Return code -
-
Functional Description
This service can be used to get the complete XCP data. This is required for flash programming with a flash
kernel.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> Bootloader Download has to be enabled: /MICROSAR/Xcp/XcpGeneral/XcpBootloaderDownload
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
42
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Expected Caller Context
> Task level
Table 5-16 Xcp_GetXcpDataPointer
5.2.15 Xcp_SetStimMode Prototype
void
Xcp_SetStimMode ( uint8 mode )
Parameter Mode
The STIM mode to select. This can either be
XCP_STIM_SINGLE_SHOT_MODE: Valid STIM data is written a single time
(default).
XCP_STIM_CONTINUOUS_MODE: Valid STIM data is written continuously.
Return code -
-
Functional Description
This service is used to change the behavior of the Xcp_Event function when new STIM data is written.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> Data acquisition and STIM has to be enabled
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpSynchronousDataStim
Expected Caller Context
> Task level
Table 5-17 Xcp_SetStimMode
5.3 Services provided by the XCP Protocol Layer and called by the XCP Transport
Layer 5.3.1 Xcp_TlRxIndication Prototype void
Xcp_TlRxIndication ( Xcp_ChannelType XcpChannel, unt8 *CmdPtr )
Parameter XcpChannel
The channel number in multi client mode.
CmdPtr
Pointer to the XCP protocol message, which must be extracted from the XCP
protocol packet.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
43
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code -
-
Functional Description
Every time the XCP Transport Layer receives a XCP CTO Packet this function has to be called.
The parameter is a pointer to the XCP protocol message, which must be extracted from the XCP protocol
packet.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-18 Xcp_TlRxIndication
5.3.2 Xcp_TlTxConfirmation Prototype void
Xcp_TlTxConfirmation ( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code -
-
Functional Description
The XCP Protocol Layer does not call <Bus>Xcp_Send again, until Xcp_TlTxConfirmation has
confirmed the successful transmission of the previous message. Xcp_TlTxConfirmation transmits
pending data acquisition messages by calling <Bus>Xcp_Send again.
Note that if Xcp_TlTxConfirmation is called from inside <Bus>Xcp_Send a recursion occurs, which
assumes enough space on the call stack.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-19 Xcp_TlTxConfirmation
5.3.3 Xcp_SetActiveTl Prototype © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
44
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
void
Xcp_SetActiveTl ( Xcp_ChannelType XcpChannel, uint8 MaxCto, uint16 MaxDto,
uint8 ActiveTl )
Parameter XcpChannel
The channel number in multi client mode.
MaxCto
Max CTO used by the respective XCP Transport Layer
MaxDto
Max DTO used by the respective XCP Transport Layer
ActiveTl
XCP_TRANSPORT_LAYER_CAN: XCP on CAN Transport Layer
XCP_TRANSPORT_LAYER_FR: XCP on Fr Transport Layer
XCP_TRANSPORT_LAYER_ETH: XCP on Ethernet Transport Layer
Return code -
-
Functional Description
This service is used by the XCP Transport Layers to set the Transport Layer to be used by the XCP
Protocol Layer
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-20 Xcp_SetActiveTl
5.3.4 Xcp_GetActiveTl Prototype uint8
Xcp_GetActiveTl ( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code uint8
XCP_TRANSPORT_LAYER_CAN: XCP on CAN Transport Layer
XCP_TRANSPORT_LAYER_FR: XCP on Fr Transport Layer
XCP_TRANSPORT_LAYER_ETH: XCP on Ethernet Transport Layer
Functional Description
This service is used by the XCP Transport Layers to get the currently active Transport Layer used by the
XCP Protocol Layer
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
45
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-21 Xcp_GetActiveTl
5.4 XCP Transport Layer Services called by the XCP Protocol Layer 5.4.1 <Bus>Xcp_Send Prototype void <Bus>Xcp_Send ( Xcp_ChannelType XcpChannel, uint8 len, uint8 *msg )
Parameter XcpChannel
The channel number in multi client mode.
len
Length of message data
msg
Pointer to message
Return code -
-
Functional Description
Requests for the transmission of a command transfer object (CTO) or data transfer object (DTO).
Xcp_TlTxConfirmation must be called after the successful transmission of any XCP message. The
XCP Protocol Layer will not request further transmissions otherwise.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-22 <Bus>Xcp_Send
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
46
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.4.2 <Bus>Xcp_SendFlush Prototype void <Bus>Xcp_SendFlush( Xcp_ChannelType XcpChannel, uint8 FlushType )
Parameter XcpChannel
The channel number in multi client mode.
FlushType
This is one of the following:
XCP_FLUSH_CTO: To flush CTO messages.
XCP_FLUSH_DTO: To flush DTO message.
XCP_FLUSH_ALL: To flush either message.
Return code -
-
Functional Description
Flush the transmit buffer.
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-23 <Bus>Xcp_SendFlush
5.4.3 <Bus>Xcp_TlService Prototype uint8 <Bus>Xcp_TlService( Xcp_ChannelType XcpChannel, uint8 *pCmd )
Parameter XcpChannel
The channel number in multi client mode.
pCmd
Pointer to transport layer command string
Return code uint8
XCP_CMD_OK : Done
XCP_CMD_PENDING : Call Xcp_SendCrm() when done
XCP_CMD_SYNTAX : Error
XCP_CMD_BUSY : not executed
XCP_CMD_UNKNOWN : not implemented optional command
XCP_CMD_OUT_OF_RANGE : command parameters out of range
Functional Description
Transport Layer specific commands are processed within the XCP Transport Layer.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
47
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > Service ID: see tabl
e 'Service IDs' > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-24 <Bus>Xcp_TlService
5.5 Application Services called by the XCP Protocol Layer The prototypes of the functions that are required by the XCP Protocol Layer can be found
in the XcpAppl header.
The XCP Protocol Layer provides application callback functions in order to perform
application and hardware specific tasks.
Note: All services within this chapter are called from task or interrupt level. All services are
not reentrant.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
48
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.5.1 XcpAppl_GetTimestamp Prototype Xcp_TimestampType XcpAppl_GetTimestamp( void )
Parameter -
-
Return code Xcp_TimestampType
The timestamp which is either uint8, uint16 or uint32, depending on
configuration.
Functional Description
Returns the current timestamp.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> DAQ and timestamp feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim
/MICROSAR/Xcp/XcpGeneral/XcpTimestampType
Expected Caller Context
> Task level
Table 5-25 XcpAppl_GetTimestamp
5.5.2 XcpAppl_GetPointer Prototype Xcp_AddressPtrType
XcpAppl_GetPointer( Xcp_ChannelType XcpChannel, uint8
AddrExt, const Xcp_AddressPtrType Addr )
Parameter XcpChannel
The channel number in multi client mode.
AddrExt
8 bit address extension
Addr
32 bit address
Return code Xcp_AddressPtrType
Pointer to the address specified by the parameters
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
49
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Functional Description
This function converts a memory address from XCP format (32-bit address plus 8-bit address extension) to
a C style pointer. An MCS like CANape usually reads this memory addresses from the ASAP2 database or
from a linker map file.
The address extension may be used to distinguish different address spaces or memory types. In most
cases, the address extension is not used and may be ignored.
This function is used to convert an address from the MCS tool.
Example:
The following code shows an example of a typical implementation of XcpAppl_GetPointer:
Xcp_AddressPtrType XcpAppl_GetPointer( Xcp_ChannelType XcpChannel, uint8 AddrExt, uint32 Addr )
{
return (Xcp_AddressPtrType)Addr;
}
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> DAQ and timestamp feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim
/MICROSAR/Xcp/XcpGeneral/XcpTimestampType
Expected Caller Context
> Task level
Table 5-26 XcpAppl_GetPointer
5.5.3 XcpAppl_GetIdData Prototype uint32
XcpAppl_GetIdData( uint8 **Data, uint8 Id )
Parameter Data
Pointer to location where address pointer to Id data is stored.
Id
Identification of the requested information/identification
Return code uint32
Length of the MAP file names
Functional Description
Returns a pointer to identification information as requested by the Xcp Master.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Get ID feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpGetIdGeneric
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
50
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Expected Caller Context
> Task level
Table 5-27 XcpAppl_GetIdData
5.5.4 XcpAppl_GetSeed Prototype uint8
XcpAppl_GetSeed( const uint8 Resource, uint8 *Seed )
Parameter Resource
Resource for which the seed has to be generated
XCP_RM_CAL_PAG : to unlock the resource calibration/paging
XCP_RM_DAQ : to unlock the resource data acquisition
XCP_RM_STIM : to unlock the resource stimulation
XCP_RM_PGM : to unlock the resource programming
Seed
Pointer to RAM where the seed has to be generated to.
Return code uint8
The length of the generated seed that is returned by seed.
Functional Description
Generate a seed for the appropriate resource.
The seed has a maximum length of MAX_CTO-2 bytes.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Seed&Key feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpSeedKey
Expected Caller Context
> Task level
Table 5-28 XcpAppl_GetSeed
5.5.5 XcpAppl_Unlock Prototype uint8
XcpAppl_Unlock( const uint8 *Key, const uint8 Length )
Parameter Key
Pointer to key.
Length
Length of the key.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
51
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code uint8
0 : if the key is not valid
XCP_RM_CAL_PAG : to unlock the resource calibration/paging
XCP_RM_DAQ : to unlock the resource data acquisition
XCP_RM_STIM : to unlock the resource stimulation
XCP_RM_PGM : to unlock the resource programming
Functional Description Functional Description Check the key and return the resource that has to be unlocked.
Only one resource may be unlocked at one time.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Seed&Key feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpSeedKey
Expected Caller Context
> Task level
Table 5-29 XcpAppl_Unlock
5.5.6 XcpAppl_CalibrationWrite Prototype uint8
XcpAppl_CalibrationWrite( Xcp_AddressPtrType Dst, uint8 *Src, uint8 Size
)
Parameter Dst
Destination address as integer.
Src
Pointer to source of data.
Size
Size of data to copy from Src to Dst.
Return code uint8
XCP_CMD_DENIED : if access is denied
XCP_CMD_PENDING : access is performed asynchronously (e.g. EEPROM)
XCP_CMD_OK : if access is granted
Functional Description Functional Description Check addresses for valid write access and copy data from source to destination.
Particularities and Limitations > This function can be synchronous and asynchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-30 XcpAppl_CalibrationWrite
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
52
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.5.7 XcpAppl_MeasurementRead Prototype uint8
XcpAppl_MeasurementRead( uint8 *Dst, Xcp_AddressPtrType Src, uint8 Size )
Parameter Dst
Pointer to destination address
Src
Source address of data as integer
Size
Size of data to copy from Src to Dst.
Return code uint8
XCP_CMD_DENIED : if access is denied
XCP_CMD_PENDING : access is performed asynchronously (e.g. EEPROM)
XCP_CMD_OK : if access is granted
Functional Description Functional Description Check addresses for valid read access and copy data from source to destination.
Particularities and Limitations > This function can be synchronous and asynchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-31 XcpAppl_MeasurementRead
5.5.8 XcpAppl_CheckReadAccess Prototype uint8
XcpAppl_CheckReadAccess( Xcp_ChannelType XcpChannel, Xcp_AddressPtrType
Address, uint32 Size )
Parameter XcpChannel
The channel number in multi client mode.
Address
Destination address to check.
Size
Size of data to check.
Return code uint8
XCP_CMD_DENIED : if access is denied
XCP_CMD_OK : if access is granted
Functional Description Functional Description Check addresses for valid read access.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
53
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Read Protection feature need to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpMemoryReadProtection
Expected Caller Context
> Task level
Table 5-32 XcpAppl_CheckReadAccess
5.5.9 XcpAppl_CheckProgramAccess Prototype uint8
XcpAppl_CheckProgramAccess( Xcp_AddressPtrType Address, uint32 Size )
Parameter Address
Destination address to check.
Size
Size of data to check.
Return code uint8
XCP_CMD_DENIED : if access is denied
XCP_CMD_OK : if access is granted
Functional Description Functional Description Check addresses for valid write flash access.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task level
Table 5-33 XcpAppl_CheckProgramAccess
5.5.10 XcpAppl_UserService Prototype uint8
XcpAppl_UserService( uint8 *Cmd )
Parameter Cmd
Pointer to command string
Return code uint8
XCP_CMD_OK : if command is accepted.
XCP_CMD_PENDING : if command is performed asynchronously.
XCP_CMD_SYNTAX : if command is not accepted.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
54
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Functional Description Functional Description Application specific user command.
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> User command feature need to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpUserDefinedCommand
Expected Caller Context
> Task level
Table 5-34 XcpAppl_UserService
5.5.11 XcpAppl_OpenCmdIf Prototype uint8
XcpAppl_OpenCmdIf( Xcp_ChannelType XcpChannel, uint8 *Cmd, uint8
*Response, uint8 *Length )
Parameter XcpChannel
The channel number in multi client mode.
Cmd
Pointer to command string
Response
Pointer to response string
Length
Pointer to response length
Return code uint8
XCP_CMD_OK : if command is accepted.
XCP_CMD_PENDING : if command is performed asynchronously.
XCP_CMD_UNKNOWN : if command is not accepted.
Functional Description Functional Description Call back that can be used to extend the XCP commands of the XCP protocol layer.
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> User command feature need to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpOpenCommandInterface
Expected Caller Context
> Task level
Table 5-35 XcpAppl_OpenCmdIf
5.5.12 XcpAppl_SendStall Prototype © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
55
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
uint8
XcpAppl_SendStall( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code uint8
0 : Reject sending of new message.
1 : continue processing.
Functional Description Functional Description Resolve a transmit stall condition in Xcp_Putchar or Xcp_SendEvent.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Service request Messages feature need to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpAsynchMessage/XcpServiceRequestMessage
Expected Caller Context
> Task level
Table 5-36 XcpAppl_SendStall
5.5.13 XcpAppl_DisableNormalOperation Prototype uint8
XcpAppl_DisableNormalOperation( Xcp_AddressPtrType Address, uint16 Size )
Parameter Address
Address (where the flash kernel is downloaded to)
Size
Size (of the flash kernel)
Return code uint8
XCP_CMD_OK:
download of flash kernel confirmed
XCP_CMD_DENIED: download of flash kernel refused
Functional Description Functional Description Prior to the flash kernel download has the ECU’s normal operation to be stopped in order to avoid
misbehavior due to data inconsistencies.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Bootloader download feature need to be enabled:
/MICROSAR/Xcp/XcpGeneral/XcpBootloaderDownload
Expected Caller Context
> Task level
Table 5-37 XcpAppl_DisableNormalOperation
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
56
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.5.14 XcpAppl_StartBootLoader Prototype uint8
XcpAppl_StartBootLoader( void )
Parameter -
-
Return code uint8
This function should not return.
XCP_CMD_OK :
positive response
XCP_CMD_BUSY :
negative response
Functional Description Functional Description Start of the boot loader.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Bootloader download feature need to be enabled:
/MICROSAR/Xcp/XcpGeneral/XcpBootloaderDownload
Expected Caller Context
> Task level
Table 5-38 XcpAppl_StartBootLoader
5.5.15 XcpAppl_Reset Prototype void
XcpAppl_Reset( void )
Parameter -
-
Return code -
-
Functional Description
Perform an ECU reset after reprogramming of the application.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Programming feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
57
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Expected Caller Context
> Task level
Table 5-39 XcpAppl_Reset
5.5.16 XcpAppl_ProgramStart Prototype uint8
XcpAppl_ProgramStart( void )
Parameter -
-
Return code uint8
XCP_CMD_OK : Preparation done
XCP_CMD_PENDING : Call Xcp_SendCrm() when done
XCP_CMD_ERROR : Flash programming not possible
Functional Description
Prepare the ECU for flash programming.
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Programming feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming
Expected Caller Context
> Task level
Table 5-40 XcpAppl_ProgramStart
5.5.17 XcpAppl_FlashClear Prototype uint8
XcpAppl_FlashClear( uint8 *Address, uint32 Size )
Parameter Address
Address of memory area to clear
Size
Size of memory area to clear
Return code uint8
XCP_CMD_OK : Flash memory erase done
XCP_CMD_PENDING : Call Xcp_SendCrm() when done
XCP_CMD_ERROR : Flash memory erase error
Functional Description
Clear the flash memory, before the flash memory will be reprogrammed.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
58
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Programming feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming
Expected Caller Context
> Task level
Table 5-41 XcpAppl_FlashClear
5.5.18 XcpAppl_FlashProgram Prototype uint8
XcpAppl_FlashProgram( const uint8 *Data, uint8 *Address, uint8 Size )
Parameter Data
Pointer to data.
Address
Address of memory to store data at.
Size
Size of data.
Return code uint8
XCP_CMD_OK : Flash memory programming finished
XCP_CMD_PENDING : Flash memory programming in progress.
Xcp_SendCrm has to be called when done.
Functional Description
Program the cleared flash memory.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Programming feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpProgramming
Expected Caller Context
> Task level
Table 5-42 XcpAppl_FlashProgram
5.5.19 XcpAppl_DaqResume Prototype uint8
XcpAppl_DaqResume( Xcp_ChannelType XcpChannel, Xcp_ChannelStruct *Channel
)
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
59
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Parameter XcpChannel
The channel number in multi client mode.
Channel
Pointer to dynamic DAQ list structure
Return code uint8
Boolean flag whether valid DAQ list was restored.
Functional Description
Resume the automatic data transfer.
The whole dynamic DAQ list structure that had been stored in non-volatile memory within the service
XcpAppl_DaqResumeStore(..) has to be restored to RAM.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpResumeMode
Expected Caller Context
> Task level
Table 5-43 XcpAppl_DaqResume
5.5.20 XcpAppl_DaqResumeStore Prototype void
XcpAppl_DaqResumeStore( Xcp_ChannelType XcpChannel, const
Xcp_ChannelStruct *Channel, uint8 MeasurementStart )
Parameter XcpChannel
The channel number in multi client mode.
Channel
Pointer to dynamic DAQ list structure
MeasurementStart
If > 0 then set flag to start measurement during next init
Return code -
-
Functional Description
This application callback service has to store the whole dynamic DAQ list structure in non-volatile
memory for the DAQ resume mode. Any old DAQ list configuration that might have been stored in non-
volatile memory before this command, must not be applicable anymore.
After a cold start or reset the dynamic DAQ list structure has to be restored by the application callback
service XcpAppl_DaqResume(..)when the flag MeasurementStart is > 0.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
60
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpResumeMode
Expected Caller Context
> Task level
Table 5-44 XcpAppl_DaqResumeStore
5.5.21 XcpAppl_DaqResumeClear Prototype void
XcpAppl_DaqResumeClear( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code -
-
Functional Description
The whole dynamic DAQ list structure that had been stored in non-volatile memory within the service
XcpAppl_DaqResumeStore(..) has to be cleared.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpDaqAndStim/XcpResumeMode
Expected Caller Context
> Task level
Table 5-45 XcpAppl_DaqResumeClear
5.5.22 XcpAppl_CalResumeStore Prototype boolean
XcpAppl_CalResumeStore( Xcp_ChannelType XcpChannel )
Parameter XcpChannel
The channel number in multi client mode.
Return code boolean
If true the calibration page was stored.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
61
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Functional Description
This application callback service has to store the current calibration data in non-volatile memory for the
resume mode.
After a cold start or reset the calibration data has to be restored by the application.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpFreezeMode
Expected Caller Context
> Task level
Table 5-46 XcpAppl_CalResumeStore
5.5.23 XcpAppl_GetCalPage Prototype uint8
XcpAppl_GetCalPage( uint8 Segment, uint8 Mode )
Parameter Segment
Logical data segment number
Mode
Access mode
The access mode can be one of the following values:
1 : ECU access
2 : XCP access
Return code uint8
Logical data page number
Functional Description
This function returns the logical number of the calibration data page that is currently activated for the
specified access mode and data segment.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching
Expected Caller Context
> Task level
Table 5-47 XcpAppl_GetCalPage
5.5.24 XcpAppl_SetCalPage Prototype © 2017 Vector Informatik GmbH
Version 2.0.02.0.0
62
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
uint8
XcpAppl_SetCalPage( uint8 Segment, uint8 Page, uint8 Mode )
Parameter Segment
Logical data segment number
Page
Logical data page number
Mode
Access mode
The access mode can be one of the following values:
1 : ECU access the given page will be used by the slave device application
2 : XCP access the slave device XCP driver will access the given page
Both flags may be set simultaneously or separately.
Return code uint8
XCP_CMD_OK : Operation completed successfully
XCP_CMD_PENDING : Call Xcp_SendCrm() when done
XCP_CRC_OUT_OF_RANGE : segment out of range (only one segment
supported)
XCP_CRC_PAGE_NOT_VALID : Selected page not available
XCP_CRC_PAGE_MODE_NOT_VALID : Selected page mode not available
Functional Description Switch pages, e.g. from reference page to working page.
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
/MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching
Expected Caller Context
> Task level
Table 5-48 XcpAppl_SetCalPage
5.5.25 XcpAppl_CopyCalPage Prototype uint8
XcpAppl_CopyCalPage( uint8 SrcSeg, uint8 SrcPage, uint8 DestSeg, uint8
DestPage )
Parameter SrcSeg
Source segment.
SrcPage
Source page.
DestSeg
Destination segment.
DestPage
Destination page.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
63
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code uint8
XCP_CMD_OK : Operation completed successfully
XCP_CMD_PENDING : Call XcpSendCrm() when done
XCP_CRC_PAGE_NOT_VALID : Page not available
XCP_CRC_SEGMENT_NOT_VALID : Segment not available
XCP_CRC_WRITE_PROTECTED : Destination page is write protected.
Functional Description
Copying of calibration data pages.
The pages are copied from source to destination.
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
> /MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpCopyPage
Expected Caller Context
> Task level
Table 5-49 XcpAppl_CopyCalPage
5.5.26 XcpAppl_SetFreezeMode Prototype void
XcpAppl_SetFreezeMode( uint8 Segment, uint8 Mode )
Parameter Segment
Segment to set freeze mode
Mode
New freeze mode
Return code -
-
Functional Description
Setting the freeze mode of a certain segment. Application must store the current freeze mode of each
segment.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
> /MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpFreezeMode
Expected Caller Context
> Task level
Table 5-50 XcpAppl_SetFreezeMode
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
64
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
5.5.27 XcpAppl_GetFreezeMode Prototype uint8
XcpAppl_GetFreezeMode( uint8 Segment )
Parameter Segment
Segment to read freeze mode
Return code uint8
Return the current freeze mode, set by XcpAppl_SetFreezeMode().
Functional Description
Reading the freeze mode of a certain segment. Application must store the current freeze mode of each
segment and report it by the return value of this function.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
> /MICROSAR/Xcp/XcpCmdConfig/XcpPageSwitching/XcpFreezeMode
Expected Caller Context
> Task level
Table 5-51 XcpAppl_GetFreezeMode
5.5.28 XcpAppl_CalculateChecksum Prototype uint8
XcpAppl_CalculateChecksum( uint8 *MemArea, uint8 *Result, uint32 Length )
Parameter MemArea
Address pointer to memory area
Result
Pointer to response string
Length
Length of mem area, used for checksum calculation
Return code uint8
XCP_CMD_OK : CRC calculation performed successfully
XCP_CMD_PENDING : Pending response, triggered by call of
Xcp_SendCrm
XCP_CMD_DENIED : CRC calculation not possible
Functional Description
Normally the XCP uses internal checksum calculation functions. If the internal checksum calculation
does not fit the user requirements this call-back can be used to calculate the checksum by the
application.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
65
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Particularities and Limitations > This function is asynchronous if it returns XCP_CMD_PENDING.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
> Resume Mode feature needs to be enabled:
> /MICROSAR/Xcp/XcpCmdConfig/XcpStandard/XcpCRC/XcpCustomCRC
Expected Caller Context
> Task level
Table 5-52 XcpAppl_CalculateChecksum
5.5.29 XcpAppl_ConStateNotification Prototype uint8
XcpAppl_ConStateNotification( Xcp_ChannelType XcpChannel, uint8
ConnectionState )
Parameter XcpChannel
The channel number in multi client mode.
ConnectionState
The new connection state (XCP_CON_STATE_RESUME,
XCP_CON_STATE_DISCONNECTED, XCP_CON_STATE_CONNECTED).
Return code -
-
Functional Description
Notifies the application that the connection state has changed and which the new state is.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task and interrupt level
Table 5-53 XcpAppl_ConStateNotification
5.5.30 XcpAppl_MemCpy Prototype uint8
XcpAppl_MemCpy( uint8 * Dst, const uint8 * Src, uint16 Size )
Parameter Dst
The destination where the data is copied to.
Src
The source where the data is copied from.
Size
The number of byte to be copied.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
66
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
Return code -
-
Functional Description
Copies data from source to destination.
Particularities and Limitations > This function is synchronous.
> This function is non-reentrant.
> The XCP Protocol Layer has to be initialized correctly.
Expected Caller Context
> Task and interrupt level
Table 5-54 XcpAppl_MemCpy
5.6 Services used by XCP In the following table services provided by other components, which are used by the XCP
are listed. For details about prototype and functionality refer to the documentation of the
providing component.
Component API DET
Det_ReportError
OS
GetCoreID
Table 5-55 Services used by the XCP
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
67
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
6 Configuration 6.1 Configuration Variants The XCP supports the configuration variants
> VARIANT-PRE-COMPILE
The configuration classes of the XCP parameters depend on the supported configuration
variants. For their definitions please see the Xcp_bswmd.arxml file.
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
68
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
7 Glossary and Abbreviations 7.1 Abbreviations Abbreviation Description A2L File Extension for an
ASAM
2MC
Language File
AML ASAM 2
Meta
Language
API Application
Programming
Interface
ASAM Association for
Standardization of
Automation and
Measuring Systems
BYP BYPassing
CAN Controller
Area
Network
CAL CALibration
CANape Calibration and Measurement Data Acquisition for Electronic Control
Systems
CMD Co
mman
d CTO Command
Transfer
Object
DAQ Synchronous
Data
Ac
quistion
DLC Data
Length
Code ( Number of data bytes of a CAN message )
DLL Data
link
layer
DTO Data
Transfer
Object
ECU Electronic
Control
Unit
ERR Error Packet
EV Event packet
ID Identifier (of a CAN message)
Identifier Identifies a CAN message
ISR Interrupt
Service
Routine
MCS Master
Calibration
System
Message One or more signals are assigned to each message.
ODT Object
Descriptor
Table
OEM Original
equipment
manufacturer (vehicle manufacturer)
PAG PAGing
PID Packet
Identifier
PGM Pro
gra
mming
RAM Random
Access
Memory
RES Command
Response Packet
ROM Read
Only
Memory
SERV Service Request Packet
STIM Stimulation
TCP/IP Transfer
Control
Protocol /
Internet
Protocol
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
69
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
UDP/IP Unified
Data
Protocol /
Internet
Protocol
USB Universal
Serial
Bus
XCP Universal Measurement and
Calibration
Protocol
VI Vector
Informatik GmbH
Table 7-1 Abbreviations
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
70
based on template version 6.0.1
Technical ReferenceTechnical Reference MICROSAR XCPMICROSAR XCP
8 Contact Visit our website for more information on
> News
> Products
> Demo software
> Support
> Training data
> Addresses
www.vector.com
© 2017 Vector Informatik GmbH
Version 2.0.02.0.0
71
based on template version 6.0.1
Document Outline
6 - UserManual_AUTOSAR_Calibrations
User Manual AUTOSAR Calibration Measuring and Calibrating of AUTOSAR
Applications with XCP and CANape
Version 1.0 English
Imprint
Vector Informatik GmbH
Ingersheimer Straße 24
D-70499 Stuttgart
Vector reserves the right to modify any information and/or data in this user documentation without notice. This documentation nor any of
its parts may be reproduced in any form or by any means without the prior written consent of Vector. To the maximum extent permitted
under law, all technical data, texts, graphics, images and their design are protected by copyright law, various international treaties and
other applicable law. Any unauthorized use may violate copyright and other applicable laws or regulations.
Copyright 2013, Vector Informatik GmbH. Printed in Germany.
All rights reserved.
User Manual AUTOSAR Calibration
Contents
Contents
1 Introduction 3 1.1 Purpose of the AUTOSAR Calibration User Manual 4 1.2 About This User Manual 5 1.2.1 Certification 6 1.2.2 Warranty 6 1.2.3 Support 6 1.2.4 Trademarks 6 2 Introduction to AUTOSAR 7 2.1 Background 8 2.2 Approach 9 2.3 Basic Concept 10 2.4 Architecture 11 3 Measuring and Calibrating of ECU Software 13 3.1 Basics 14 3.2 XCP Driver 15 3.2.1 Measurement Modes 17 3.2.2 Autoselection and Software Version Check of the A2L File 18 3.2.3 Online Calibration 19 3.2.4 Page Switching 19 3.2.5 Bypassing 20 3.2.6 Resume Mode 21 3.3 A2L File 22 3.3.1 Structure 23 3.3.2 Mode of Functioning 32 4 OEM 33 4.1 Objective 34 4.2 Content of the Performance Specifications 34 4.3 Measurement Task 34 4.4 Calibration Task 35 4.5 XCP Features 35 5 Supplier 36 5.1 Preface 37 5.2 Requirements 37 5.3 Definition of Measurement and Calibration Parameters 37 5.3.1 Measuring and Calibrating of AUTOSAR Software Components 38 5.3.2 Measuring of Ports and Variables 38 5.3.3 XCP Events 39 5.3.4 Software Component with Calibration Parameters 40 5.3.5 Calibration Parameters for Multiple Software Components 40 5.3.6 Configuration of the RTE (Runtime Environment) 41 5.3.7 Measuring and Calibrating Without the Support of the RTE 41 5.3.8 Debugging of the BSW (Basic Software) 42 © Vector Informatik GmbH
Version 1.0
- I -
User Manual AUTOSAR Calibration
Contents
5.4 Configuration of the XCP Module 42 5.4.1 DAQ List Configuration 43 5.4.2 Tool-Driven DAQ Timestamp Option 44 5.4.3 XCP Event Information 44 5.4.4 Software Version Check 44 5.4.5 Use of the XCP Component in the Implementation 46 5.4.6 Recommendations for the Configuration of the XCP Module 46 5.5 Configuration of the Driver Modules 48 5.5.1 CAN Module MICROSAR XCP 48 5.6 Configuration of the Memory Management 48 5.6.1 Configuration for Resume Mode 48 5.7 Creating an A2L File 49 5.7.1 Creation of a Master A2L File 49 5.7.2 Expansion of the Master A2L File 51 5.7.3 Working with ASAP2 Tool-Set 52 5.7.4 Working with CANape and the ASAP2 Editor 54 5.8 Fast Access to the ECU Via the VX Module 55 5.9 Additional Topics 56 6 Delivery Test/Quick Start 57 7 CANape Introduction 58 7.1 Creation of a Project 59 7.2 Device Configuration 60 7.2.1 Devices 61 7.2.2 Networks 62 7.2.3 Vector Hardware 62 7.2.4 XCP Features in CANape 63 7.3 Online Measurement Configuration 64 7.3.1 Measurement Options 64 7.3.2 Measurement Signals 65 7.3.3 Recorder List 67 7.3.4 Event List 69 7.4 Working with Parameter Set Files 69 7.5 Dataset Management 70 7.5.1 Tool-Based in CANape 11.0 and Higher 70 7.6 Offline Evaluation 72 7.7 Flashing 74 8 Addresses 75 9 Abbreviations 76 © Vector Informatik GmbH
Version 1.0
- II -
User Manual AUTOSAR Calibration
Introduction
1 Introduction In this chapter you will find the following information: 1.1
Purpose of the AUTOSAR Calibration User Manual page 4
1.2
About This User Manual page 5
Certification Warranty Support Trademarks © Vector Informatik GmbH
Version 1.0
- 3 -
User Manual AUTOSAR Calibration
Introduction
1.1 Purpose of the AUTOSAR Calibration User Manual AUTOSAR Standard The AUTOSAR Standard describes methods that enable standardized development
of reusable and replaceable software components within vehicles. This approach
minimizes the development effort for electronic control unit (ECU) software. The
software is then optimized using CANape.
Calibration and
Since the software developer cannot yet optimize the parameters for a control
measurement
algorithm of the ECU at the time of implementation, these parameters are defined in
parameters
the software as calibration parameters. The calibration parameters are ultimately
variables in the source code that reside in RAM memory and remain unchanged by
the algorithm itself. They can then be calibrated using CANape. To record the effects
of the calibration process, additional measurement parameters are defined in the
software. These parameters are also variables in the source code and reside in RAM
memory. In contrast to calibration parameters, however, measurement parameters
are continually changed by the ECU algorithm and reflect the current value. This
makes the effects of the calibration process visible and allows the behavior of the
ECU to be optimized. For example, the wheel speed (calibration parameter) of a
driving dynamics control system is changed and the measuring equipment measures
the corresponding sensor values (measurement parameters) in order to acquire the
change in behavior of the algorithm.
CCP/XCP protocols
In order to access the ECU-internal measurement and calibration parameters during
with A2L file
runtime, the CCP and XCP protocols are used. A fundamental component of these
address-oriented protocols is an A2L file. This file facilitates data handling, since it
enables the symbolic selection of data objects independent from their memory
addresses in the ECU. Thus, it is possible to access ECU-internal parameters using
symbolic names. The measurement, calibration, and diagnostics system (CANape)
maintains the link between the ECU-internal addresses and the associated symbolic
names. For this, a separate A2L file is required for each ECU
. Figure 1-1 shows the
integration of the A2L file in the MCD system.
Figure 1-1: Integration
of the A2L file in the
MCD system ECU-independent
An ECU-independent concept for measuring and calibrating AUTOSAR applications
concept
is needed for the development of ECUs based on the AUTOSAR Standard. The
AUTOSAR Calibration user manual describes a standardized procedure for
implementing and calibrating an ECU according to AUTOSAR.
Structure of this
The document begins with a brief introduction of the AUTOSAR Standard. Aspects of
document
Measuring and Calibrating of ECU Software are then explained.
The
OEM chapter serves as a checklist for OEMs when creating performance
specifications. It briefly explains the details that must be communicated to the supplier
in order to realize the desired measurement task.
© Vector Informatik GmbH
Version 1.0
- 4 -
User Manual AUTOSAR Calibration
Introduction
The
Supplier chapter describes the procedure on the part of the supplier. It describes
details for configuring MICROSAR XCP and the software components of AUTOSAR.
It also explains the process of generating the A2L file.
The
Delivery Test/Quick Start chapter then explains how CANape can be used to
perform a simple delivery test of the A2L file. This can additionally be used as a
CANape Quick Start for the OEM.
The final
CANape Introduction chapter describes the path from project creation to
flashing of optimized parameters in CANape.
1.2 About This User Manual To Find information
This user manual provides you with the following access help:
quickly
> At the beginning of each chapter you will find a summary of the contents.
> The header shows in which chapter of the manual you are.
> The footer shows the version of the manual.
> At the end of the user manual you will find a list of abbreviations to look-up used
abbreviations.
Conventions
In the two tables below you will find the notation and icon conventions used
throughout the manual.
Style Utilization bold Fields/blocks, user/surface interface elements, window- and
dialog names of the software, special emphasis of terms.
[OK] Push buttons in square brackets
File|
Save Notation for menus and menu entries
MICROSAR
Legally protected proper names and marginal notes.
Source Code File and directory names, source code, class and object
names, object attributes and values
Hyperlink
Hyperlinks and references.
<Ctrl>+<S>
Notation for shortcuts.
© Vector Informatik GmbH
Version 1.0
- 5 -
User Manual AUTOSAR Calibration
Introduction
Symbol Utilization This icon indicates notes and tips that facilitate your work.
This icon warns of dangers that could lead to damage.
This icon indicates more detailed information.
This icon indicates examples.
This icon indicates step-by-step instructions.
1.2.1 Certification Quality
Vector Informatik GmbH has ISO 9001:2008 certification. The ISO standard is a
management system globally recognized standard.
1.2.2 Warranty Restriction of
We reserve the right to modify the contents of the documentation or the software
warranty
without notice. Vector disclaims all liabilities for the completeness or correctness of
the contents and for damages which may result from the use of this documentation.
1.2.3 Support Need support?
You can get through to our hotline by calling
+49 (0)711 80670-200
or you can send a problem report to canape-support@vector.com.
1.2.4 Trademarks Protected
All brand names in this documentation are either registered or non-registered
trademarks
trademarks of their respective owners.
© Vector Informatik GmbH
Version 1.0
- 6 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
2 Introduction to AUTOSAR In This Chapter You Will Find the Following Information: 2.1
Background page 8
2.2
Approach page 9
2.3
Basic Concept page 10
2.4
Architecture page 11
© Vector Informatik GmbH
Version 1.0
- 7 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
2.1 Background AUTOSAR
AUTOSAR (
AUTomotive
Open
System
ARchitecture) is a working group of
automobile manufacturers and suppliers whose objective is to establish a joint
industry standard for automotive E/E (electrics/electronics) architectures.
Main objectives
The main objectives of this effort are:
> Management of the increasing E/E complexity
> Improved flexibility for updates and modifications
> Scalability to different vehicle and platform variants
> Improved reliability and quality of E/E systems
> Ability to identify errors in early phases of development
> Reusability of functions irrespective of the supplier
> Standardized model tools and code generators
© Vector Informatik GmbH
Version 1.0
- 8 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
2.2 Approach AUTOSAR elements
Figure 2-1 shows the AUTOSAR approach. The individual elements are explained in
more detail below.
Figure 2-1: Concept of
AUTOSAR1 AUTOSAR SW-C The AUTOSAR software components form the framework of an application that runs
on the AUTOSAR infrastructure.
Reference: The interfaces of the AUTOSAR software components are described in
more detail on
http://www.autosar.org/index.php?p=1&up=2&uup=1&uuup=0. SW-C Description The software component description is provided by AUTOSAR, for example, for
defining interfaces.
Virtual Functional The VFB describes all communication mechanisms of AUTOSAR at an abstract level.
Bus (VFB) 1 Source of figure: AUTOSAR Technical Overview V2.2.2 R3.2 Rev 1
© Vector Informatik GmbH
Version 1.0
- 9 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
System Constraint In order to integrate software components into a network of an ECU, AUTOSAR
and ECU provides descriptions for entire systems or for configurations and signals of individual
Descriptions ECUs.
Runtime The RTE implements the functionality of the VFB of a particular ECU. However, it can
Environment (RTE) delegate a portion to the basic software.
Basic Software The basic software provides the infrastructural functionality of the ECU.
(BSW)
2.3 Basic Concept Communication via
The communication between the individual components takes place via the Virtual
VFB
Functional Bus (VFB). At this stage, there is not yet any memory management of the
ECUs. The VFB is used both within the ECU and across ECUs and has no
knowledge of the bus technology used. This enables replacement of the application
software, regardless of the bus technology use
d. Figure 2-2 shows the
communication flow of the Virtual Functional Bus.
Figure 2-2: Communication flow of the VFB
Running of the
As soon as all relevant objects have been defined, they are mapped to the ECU. The
components
VFB is implemented using an ECU-specific Runtime Environment (RTE) and,
together with the operating system, takes over the running of the components.
Consistence of
Software components, here e.g.,
Left Door and
Right Door, consist of:
software components
> Ports: These serve as the interface for communication with other software
components. They can act either as sender/receiver or client/server. The ports
are interconnected using
connectors.
> Runnables: Each atomic SW-C contains one or more runnables. These
represent the runnable portion of the software component and reference functions
and procedures.
© Vector Informatik GmbH
Version 1.0
- 10 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
2.4 Architecture Layers
The AUTOSAR architecture essentially has seven different layers (see
Figure 2-3).
The top and bottom layers are not explained in detail here as they do not belong to
the basic software.
Figure 2-3: Overview of
AUTOSAR layers Microcontroller The Microcontroller Abstraction Layer is the lowest software layer of the basic
Abstraction Layer software architecture and provides the upper layers their independence from the
actual microcontroller.
ECU Abstraction The purpose of the ECU Abstraction Layer is to ensure the independence of higher
Layer layers from the actual ECU.
Service Layer The Service Layer is the highest layer of the basic software. It contains the operating
system and assumes functions such as the network and NVRAM management and
diagnostic services.
Complex Device The device driver layer controls special sensors and actuators via direct access to the
Drivers microcontroller. This involves sensors with special time conditions, for example, that
supply fuel injection to paths.
Runtime As middleware, the Runtime Environment (RTE) integrates different applications with
Environment the basic software. It organizes the communication and data exchange between the
two layers and manages the running of the runnables. Because all layers are
described exactly, the application software can be implemented independent of the
hardware and without knowledge of how the other layers behave. The communication
between the layers takes place via ports defined beforehand.
The following Figure 2-4 shows the complete AUTOSAR ECU software architecture.
© Vector Informatik GmbH
Version 1.0
- 11 -
User Manual AUTOSAR Calibration
Introduction to AUTOSAR
Figure 2-4: AUTOSAR software architecture2 2 Source of figure: AUTOSAR Technical Overview V2.2.2 R3.2 Rev 1
© Vector Informatik GmbH
Version 1.0
- 12 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3 Measuring and Calibrating of ECU Software In This Chapter You Will Find the Following Information: 3.1
Basics page 14
3.2
XCP Driver page 15
Measurement Modes Autoselection and Software Version Check of the A2L File Online Calibration Page Switching Bypassing Resume Mode 3.3
A2L File page 22
Structure Mode of Functioning © Vector Informatik GmbH
Version 1.0
- 13 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3.1 Basics Challenge
Variables in the source code are implemented as measurement and calibration
parameters in the ECU software. The task of the calibration engineer is to measure
and calibrate these parameters so that the behavior of the ECU is optimized. To
make the calibration process convenient, calibration tools such as the MCD tool
(
Measurement,
Calibration,
Diagnostics) CANape are used. This type of tool requires
an XCP driver and an A2L file for communicating with the ECU. The XCP driver
enables the access to ECU-internal parameters during runtime. The A2L file, in turn,
links the symbolic name of a measurement or calibration parameter with its memory
address. In this way, the calibration engineer can calibrate individual calibration
parameters with CANape without having to know the memory address of the
parameter.
Figure 3-1: Measurement and calibration process
© Vector Informatik GmbH
Version 1.0
- 14 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3.2 XCP Driver Protocol
The XCP driver – such as MICROSAR XCP – is a further development of the CCP
driver and can be used universally for different bus systems. It involves a protocol
based on the single master/multi-slave principle. An XCP master, such as CANape, is
able to communicate simultaneously with various XCP slaves. These include, for
example, the ECU or HIL/SIL systems
. Figure 3-2 shows the slave connection via
XCP.
Figure 3-2: Communication possibilities of an XCP master such as CANape
Communication via
CANape communicates with the ECU via the XCP driver. The A2L file is an important
A2L file
component of this communication. From this file, the XCP master reads all
information that is important for the communication setup and sequence.
© Vector Informatik GmbH
Version 1.0
- 15 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-3: Single master/multi-slave concept Transfer objects
In the XCP protocol, a distinction is made between "Command Transfer Objects
(CTO)" and "Data Transfer Objects (DTO)" (see Figure 3-3). The Object Description
Table (ODT) describes the mapping of the DTOs and memory of the slave. The
reception of a CTO signals the slave to run a certain service. The transmission of a
DTO is used for event-triggered reading and writing of objects from the memory of the
XCP slave. For this, DAQ (Data Acquisition) lists are created from multiple ODTs in
order to send the measurement values to the master at the same time that an event
occurs. The events are defined using event channels and take over, with the help of
defined time bases, the timing for task-synchronous transmission of measurement
data.
Dynamic
With XCP it is possible to configure the DAQ lists both statically as well as
configuration of DAQ dynamically. In the case of static configuration, the maximum number of DAQ lists,
lists
ODT tables, and ODT entries per DAQ list is fixed at compile time. With dynamic
DAQ lists, on the other hand, only the maximum memory size is specified at compile
time. This enables more efficient memory utilization since the size of the DAQ lists is
defined individually. If necessary, it also allows more measurement signals to be
measured compared to the static configuration. In addition, implementation in the
XCP driver is significantly easier because specifications such as the maximum
number of ODTs is eliminated. The dynamic configuration is therefore the only mode
supported.
XCP features
The XCP protocol also enables use of some optional XCP features. These must be
explicitly implemented and therefore be known to the supplier. The rest of this section
presents the following XCP features in more detail: Measurement Modes,
Autoselection and Software Version Check of the A2L File, Online Calibration, Page
Switching, Bypassing and Resume Mode.
© Vector Informatik GmbH
Version 1.0
- 16 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3.2.1 Measurement Modes Measurement modes The XCP protocol enables two different measurement modes:
Polling and
DAQ measurement. Both variants are briefly explained here.
Polling Polling is the simplest measurement mode of the XCP protocol. In this mode, the
XCP master uses an XCP command (SHORT_UPLOAD) to poll the measurement
values in a uniform time base. The measurement data are not equidistant in this
mode. If there is a high bus load, the measurement parameter may be transferred
with a time lag. Figure 3-4 shows the communication sequence for the polling
measurement mode.
Figure 3-4: Communication sequence for the polling measurement mode DAQ The
DAQ measurement mode uses an optimized method in order to access ECU-
internal values. In
DAQ measurement mode, the XCP master groups the
measurement and calibration parameters to be measured in ODTs and assigns these
to the corresponding DAQ events before the start of the measurement. During the
measurement, the XCP slave transmits the measurement values when the cyclic
DAQ event or asynchronous DAQ event occurs without further requests to the master
(see also the XCP Driver section).
In the
DAQ measurement mode, a distinction is also made between the
Consistency
ODT and
Consistency DAQ modes. In the first case, the measurement data of an
ODT are consistent. In the second case, the DAQ list as a whole is consistent, but not
every ODT as a single entity. The measurement data can therefore be split between
two ODTs. Figure 3-5 presents the communication sequence of the
DAQ measurement mode in a trace.
Note: Only the
Consistency ODT is currently supported by MICROSAR.
© Vector Informatik GmbH
Version 1.0
- 17 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-5: Communication sequence for the DAQ measurement mode
Timestamps
If there are stringent requirements for time accuracy of the measurement values,
generation of the timestamp directly in the ECU is recommended. In the DAQ
measurement mode, the XCP driver also transfers the timestamp for each occurring
event so that the measurement is not falsified by the running time of the transfer to
the MCD tool. However, the throughput of measurement values is meanwhile
reduced. Because the timestamps represent an additional load on the bus, their
generation can also be controlled via the MCD tool.
With a CAN bus, for example, it should be possible to disable the timestamp. With
Ethernet, the timestamp is of little importance.
Timestamps are mandatory on FlexRay when a cycle time is used that is faster than
the FlexRay bus cycle.
3.2.2 Autoselection and Software Version Check of the A2L File Software version
CANape provides the option of checking the software version. This means that a
check
check is made based on certain information to determine whether die A2L file
integrated in CANape corresponds to the current software version of the connected
ECU. The option also exists to select the A2L file automatically using an XCP protocol
command.
CANape can use the following information for the software version check:
> XCP Station Identifier (protocol command GET_ID)
> EPK check
> Checksum of code segments in the ECU (CANape 11.0 and higher)
XCP station identifier The "XCP Station Identifier" (GET_ID) represents the name of the A2L file during the
software version check. This describes the software version in a meaningful way
(e.g., EcuName_V1-2-0.a2l). CANape can use this identifier to check whether the
correct A2L file is loaded or load the appropriate A2L file automatically.
EPK check
The EPK identifier (EPROM identifier) is a character string that is present in the ECU
© Vector Informatik GmbH
Version 1.0
- 18 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
as well as in the database. The address in the ECU where this identifier can be found
is specified in the database. This character string can, in turn, designate the software
version based on the project name and its version.
Checksum
The checksum of code segments (memory segments with ECU code) can be
calculated for the HEX file and the ECU. On the basis of the checksum it can be
determined if the HEX file, the A2L file, and the software on the ECU are compatible
with respect to version. This approach assumes that the HEX file and the A2L file are
viewed as a unit.
Application of the
The described procedures can be applied independently of one another. Each
procedures
individual procedure increases the assurance that you are working with correct data.
For example, it is possible to have the A2L file selected automatically based on the
"XCP Station Identifier" and to additionally use the check based on EPK identifier.
3.2.3 Online Calibration Prerequisite
This section introduces the most important terms regarding online calibration. Online
calibration enables optimization of the calibration parameters of the ECU algorithm
during runtime so that the effects of the change can be directly measured. A
prerequisite for this is availability of sufficient RAM memory.
Calibration concepts
Two different calibration concepts are available for calibrating with XCP and
AUTOSAR:
> InitRAM
> AUTOSAR Single Pointered
Reference: Additional information on the topic of calibration concepts can be found in
the respective AUTOSAR specification
AUTOSAR_SWS_RTE, chapter "Calibration".
3.2.4 Page Switching Switchover of
Calibration parameters normally reside in FLASH memory and are copied to RAM
memory segment
memory, if required. Depending on the implementation, some ECUs provide the
pages between RAM option of page switching, i.e., the XCP switchover of memory segment pages
and FLASH
between RAM and FLASH. With the help of this feature, calibration parameters can
be calibrated and the possibility exists to quickly switch back to the values stored in
FLASH memory. This XCP mechanism is independent of the calibration concept
used.
Logical structure of
In principle, the memory is logically structured in segments. These specify where the
the memory in
calibration parameters reside. Each segment can, in turn, have multiple pages. A
segments
page describes the same data at the same address, but with different properties or
values (see
Figure 3-6). © Vector Informatik GmbH
Version 1.0
- 19 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-6: Physical
layout of the memory Assignment
The assignment of the algorithm to a page within a segment must be unambiguous at
all times. In addition, only one page at a time may be active in a segment. This page
is the so-called "active page for the ECU in this segment".
Access
The page that the ECU or the XCP driver accesses can be controlled individually. The
active page for the XCP access is called the “active page for the XCP access in this
segment”.
Commands
In order to use page switching, the ECU must support the XCP commands
GET_CAL_PAGE and SET_CAL_PAGE.
With the GET_CAL_PAGE command, the master asks the slave which page of a
segment is currently active. With the SET_CAL_PAGE command, on the other hand,
the master can define which page the master itself or the ECU algorithm accesses.
3.2.5 Bypassing Changes to the ECU With the help of the bypassing feature, changes to the ECU algorithm can be made
algorithm
without calibration and subsequent flashing of the software.
Implementation
To implement bypassing, at least 2 XCP events as well as writable access to the ECU
RAM via XCP are required. The events must differ in their direction (STIM, DAQ).
Figure 3-7 shows the use of bypassing.
© Vector Informatik GmbH
Version 1.0
- 20 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-7: Use of bypassing
Signal path:
1. Reception of signals of the ECU (DAQ)
2. Transmission of signals as input of the model
3. Transmission of events back to the XCP master
4. Transmission of events back to the ECU (STIM)
Calibration path:
5. Calibration of the ECU (XCP)
6. Calibration of the model with XCP
Reference: The
ASAM XCP Version 1.1 Part 1 - Overview specification, section 1.3
BYPASSING (BYP), explains in detail all other functions and implementations on the
topic of bypassing.
3.2.6 Resume Mode Automatic data
Resume mode enables automatic data transfer to take place directly after switching
transfer
on the ECU. This mode is commonly used to start recording and evaluating data as
soon as the ECU starts. Resume mode supports both the STIM and DAQ directions.
The RESUME_SUPPORTED flag in the DAQ properties must be set appropriately in the
A2L file.
Commands
With the START_STOP_DAQ_LIST command (select), the master can select a DAQ
list as part of a DAQ list configuration that the slave stores in non-volatile memory.
The master then sends to the slave the configuration ID that the master has itself
calculated and stored. The slave then knows that it will store the DAQ lists in non-
volatile memory as soon as the STORE_DAQ_REQ_RESUME command is transmitted
to it. The configuration ID is also stored in non-volatile memory so that the slave can
return it upon the GET_STATUS command. Via the GET_STATUS command, the
master finds out whether a slave is in resume mode. Prior to storing, the slave deletes
the previous content of the non-volatile memory.
© Vector Informatik GmbH
Version 1.0
- 21 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
After each start of the slave, it sends the EV_RESUME_MODE command to the master.
This command contains the following data:
Figure 3-8: Data of the
EV_RESUME_MODE
command Communication
The communication sequence between the master and slave can be tracked i
n Figure sequence
3-9. Figure 3-9:
Communication
sequence between
master and slave Reference: Additional XCP commands and information regarding resume mode can
be found in the
ASAM XCP Version 1.1 Part 1 - Overview specification.
3.3 A2L File Goal
The A2L file has been specified by the Association for Standardization of Automation
and Measuring Systems (ASAM) with the goal of defining compatible and replaceable
modules for electronics development in the automotive industry.
© Vector Informatik GmbH
Version 1.0
- 22 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-10: ASAM
interfaces ECU description file
The description file of the ECU for configuring the models and the layout of the
calibratable and measurable objects supplies the ASAP2 (ASAM MCD 2MC) interface
in the form of the A2L file. Finally, the data exchange between the MCD system and
the ECU is specified via the ASAM MCD 1MC (ASAP1b) interface.
3.3.1 Structure Modular structure
The A2L file has a modular structure, which enables the replacement of individual
modules without having to adapt the entire A2L file.
Figure 3-11 shows this modular
structure.
© Vector Informatik GmbH
Version 1.0
- 23 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Figure 3-11: Structure
of the A2L file 4 major parts
The project-relevant data at the start of the A2L file are defined using the PROJECT
keyword and form the framework of the A2L file. These also include the ECU
description that can be described with the MODULE keyword and divided into 4 major
parts:
> AML
> General ECU Implementation
> IF_DATA
> A2L Objects
These parts are explained in more detail below.
3.3.1.1 AML Interface-specific
The first part defines the interface-specific parameters. It yields the framework of the
parameters
IF_DATA area that is defined using the A2ML metalanguage with the AML keyword.
The AML is generally configured once since the specification of a driver and the
corresponding features is also performed once.
Reference: Detailed information regarding the metalanguage can be found in the
ASAP2 specification
ASAM MCD-2 MC, chapter 5.
© Vector Informatik GmbH
Version 1.0
- 24 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3.3.1.2 General ECU Implementation ECU description
This part of the A2L file specifies the ECU description. Here, standardized structures
of the ECU and the general description are defined using the MOD_COMMON and
MOD_PAR keywords. This part of the A2L file also generally remains unchanged since
the structures of the ECU are set. The keywords are now briefly presented:
MOD_COMMON The MOD_COMMON keyword describes the internal structures of the ECU. The
possibility exists to define certain parameters for the complete ECU. For example, if a
standard byte order exists, this can be specified for the complete device in this area.
Example: /begin MOD_COMMON ""
BYTE_ORDER MSB_LAST
…
/end MOD_COMMON
MOD_PAR The MOD_PAR keyword describes the ECU-specific description data such as the
EPROM identifier or the memory segments.
Example: /begin MOD_PAR "Comment"
ADDR_EPK 0x12345
EPK "EPROM identifier test"
/begin MEMORY_SEGMENT Data0001 "Data segment" DATA
FLASH INTERN 0x30000 0x1000 -1 -1 -1 -1 -1
/end MEMORY_SEGMENT
SYSTEM_CONSTANT "CONTROLLERx CONSTANT1" "0.99"
/end MOD_PAR
© Vector Informatik GmbH
Version 1.0
- 25 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
3.3.1.3 IF_DATA Communication
Next, the communication interface is specified using the IF_DATA keyword. This is
interface
only adapted if, for example, certain XCP commands are also to be used afterwards.
IF_DATA The IF_DATA keyword describes the interface-specific data, such as protocol layer or
DAQ lists. These can also be defined directly as a subcategory for diverse A2L
objects.
Example: /begin IF_DATA XCP
/begin PROTOCOL_LAYER
…
/end PROTOCOL_LAYER
/begin DAQ
…
/end DAQ
/begin XCP_ON_CAN
…
/end XCP_ON_CAN
/end IF_DATA
DAQ configuration
The DAQ configuration is an essential component of the XCP protocol and will
therefore be presented again in more detail. The configuration is made under the DAQ
keyword in the IF_DATA section, and the individual events are defined under this
point.
Reference: More detailed information regarding the definition of events can be found
in the
ASAM XCP Version 1.1 Part 1 - Overview specification, section 1.1.1.5 Event
Channels.
Specification of DAQ
Table 3-1: Specification of DAQ lists in the IF_DATA section compares the static and
lists
dynamic DAQ configuration in the A2L file.
© Vector Informatik GmbH
Version 1.0
- 26 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
XCP (static) XCP (dynamic) Explanation /begin DAQ
/begin DAQ
STATIC
DYNAMIC
DAQ configuration
RESUME_SUPPORTED
RESUME_SUPPORTED
Resume mode is supported
/begin DAQ_LIST
0x0
DAQ list number
DAQ_LIST_TYPE DAQ
Direction (DAQ | STIM)
MAX_ODT 0xB
Maximum ODTs
MAX_ODT_ENTRIES 0x7
Maximum entries in an ODT
FIRST_PID 0x3
Packet designator
EVENT_FIXED 0x0
Event channel is permanently
specified
/end DAQ_LIST
/begin EVENT
/begin EVENT
"10 ms Liste 1"
"10 ms Liste 1" Name of the event channel
"10 ms Lis"
"10 ms Lis"
Brief name of the event channel
0x0000
0x0000
Number of the event channel
Direction (DAQ | STIM)
DAQ
DAQ
Direction (DAQ | STIM)
0x01
0x01
Maximum of DAQ lists
0x0A
0x0A
Sampling period (0 corresponds to
non-cyclic)
0x06
0x06
Time base(0x06 corresponds to 1ms)
0x00
0x00
Priority
/end EVENT
/end EVENT
/end DAQ
/end DAQ
Table 3-1: Specification of DAQ lists in the IF_DATA section
Default event
It is recommended to assign at least one default event to each measurement and
calibration parameter in order to ensure that the objects will be measured at the
correct time in each case (example in next section under
A2L Objects | Measurement
parameters). With the help of this assignment, the drag & drop feature of the display
windows in CANape can be used optimally. If a default event is not defined, the
measurement mode must be changed manually by polling the appropriate event.
3.3.1.4 A2L Objects Specification of
The last part contains the A2L objects. The measurement and calibration parameters
parameters and
are specified here using various parameters and keywords. In this area, changes may
keywords
occur even after completion of the A2L file since, for example, measurement
parameters will also be added during the course of the project.
© Vector Informatik GmbH
Version 1.0
- 27 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Measurement
The measurement parameters are defined using the MEASUREMENT keyword. Some
parameters
parameter values are optional (labeled in []), while other values, such as the name,
are mandatory.
Prototype:
/begin MEASUREMENT
ident Name
string LongIdentifier
datatype Datatype
ident Conversion
uint Resolution
float Accuracy
float LowerLimit
float UpperLimit
[-> ANNOTATION]*
[-> ARRAY_SIZE]
[-> BIT_MASK]
[-> BIT_OPERATION]
[-> BYTE_ORDER]
[-> DISCRETE]
[-> DISPLAY_IDENTIFIER]
[-> ECU_ADDRESS]
[-> ECU_ADDRESS_EXTENSION]
[-> ERROR_MASK]
[-> FORMAT]
[-> FUNCTION_LIST]
[-> IF_DATA]*
[-> LAYOUT]
[-> MATRIX_DIM]
[-> MAX_REFRESH]
[-> PHYS_UNIT]
[-> READ_WRITE]
[-> REF_MEMORY_SEGMENT]
[-> SYMBOL_LINK]
[-> VIRTUAL]
/end MEASUREMENT
© Vector Informatik GmbH
Version 1.0
- 28 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Example: /begin MEASUREMENT
FP_LED
"Raw value target driving program"
UBYTE NonDim_2p0 0 0 0 10
ECU_ADDRESS 0xD000B47C
ECU_ADDRESS_EXTENSION 0x0
/begin IF_DATA XCP
/begin DAQ_EVENT VARIABLE
/begin DEFAULT_EVENT_LIST
EVENT 0001
/end DEFAULT_EVENT_LIST
/end DAQ_EVENT
/end IF_DATA
/end MEASUREMENT
Calibration
The calibration parameters are specified in the A2L file using the CHARACTERISTIC
parameters
keyword. In this case, as well, there are optional parameter values [] and mandatory
parameter values.
Prototype:
/begin CHARACTERISTIC ident Name
string LongIdentifier
enum Type
ulong Address
ident Deposit
float MaxDiff
ident Conversion
float LowerLimit
float UpperLimit
[-> ANNOTATION]*
[-> AXIS_DESCR]*
[-> BIT_MASK]
[-> BYTE_ORDER]
[-> CALIBRATION_ACCESS]
[-> COMPARISON_QUANTITY]
[-> DEPENDENT_CHARACTERISTIC]
[-> DISCRETE]
[-> DISPLAY_IDENTIFIER]
[-> ECU_ADDRESS_EXTENSION]
[-> EXTENDED_LIMITS]
[-> FORMAT]
[-> FUNCTION_LIST]
[-> GUARD_RAILS]
[-> IF_DATA]*
[-> MAP_LIST]
[-> MATRIX_DIM]
[-> MAX_REFRESH]
[-> NUMBER]
© Vector Informatik GmbH
Version 1.0
- 29 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
[-> PHYS_UNIT]
[-> READ_ONLY]
[-> REF_MEMORY_SEGMENT]
[-> STEP_SIZE]
[-> SYMBOL_LINK]
[-> VIRTUAL_CHARACTERISTIC]
/end CHARACTERISTIC
Example: /begin CHARACTERISTIC Pehp_IDATA.T_FP_delay
"Time for transition from target to actual driving program
HPP"
VALUE 0xA01350CC UWORD_COL_DIRECT 0 ms_f10 0 60000
ECU_ADDRESS_EXTENSION 0x0
EXTENDED_LIMITS 0 60000
BYTE_ORDER MSB_LAST
FORMAT "%6.0"
/end CHARACTERISTIC
Conversion rules
Frequently, conversion rules are additionally defined for measurement or calibration
parameters if, for example, an object is to be converted to a physical unit. The
COMPU_METHOD keyword is used for this.
Prototype:
/begin COMPU_METHOD ident Name
string LongIdentifier
enum ConversionType
string Format
string Unit
[-> COEFFS]
[-> COEFFS_LINEAR]
[-> COMPU_TAB_REF]
[-> FORMULA]
[-> REF_UNIT]
[-> STATUS_STRING_REF]
/end COMPU_METHOD
There are various conversion types for this:
IDENTICAL Raw value and physical value are identical, no conversion is necessary
FORM A formula is used for the conversion (to be specified with the FORMULA keyword)
LINEAR Conversion is made linearly according to f(x)=ax+b
(a and b are specified using the COEFFS_LINEAR keyword)
RAT_FUNC Conversion is made using a rational function:
f(x) = (axx+bx+c)/(dxx+ex+f)
a, b, c, d, e, f are specified using the COEFFS keyword.
TAB_INTP Conversion table with interpolation
TAB_NOINTP Conversion table without interpolation
TAB_VERB Verbal conversion table
© Vector Informatik GmbH
Version 1.0
- 30 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Example: /begin COMPU_METHOD NonDim_2p0_a ""
RAT_FUNC "%5.0" "-"
COEFFS 2 1 0 0 4 1
/end COMPU_METHOD
Groups
Hierarchy levels are realized in the A2L file using groups. In a project with many
measurement and calibration parameters, these can be subdivided and categorized.
The possibility also exists to define subgroups. This makes the A2L file easier to view
in CANape.
Prototype:
/begin GROUP ident GroupName
string GroupLongIdentifier
[-> ANNOTATION]*
[-> FUNCTION_LIST]
[-> IF_DATA]*
[-> REF_CHARACTERISTIC]
[-> REF_MEASUREMENT]
[-> ROOT]
[-> SUB_GROUP]
/end GROUP
Example: /begin GROUP Maps "Calibration Maps"
ROOT
/begin SUB_GROUP
WorkingPoint
/end SUB_GROUP
/begin REF_CHARACTERISTIC
KF1 KF2 KF3 KF4 KF5 KF6 KF7 KF8
TestKennfeld map1_8_8_uc map4_80_uc map5_82_uc
/end REF_CHARACTERISTIC
/end GROUP
Structures
The A2L Specification contains no keyword for structures. CANape identifies these
based on analysis of the object name.
The valid syntax for structures in the A2L has the following appearance:
"." for objects (e.g., "TestStructStruct1.TestStruct2.s1")
"[]" for arrays (e.g., "TestStructStruct1.TestStruct2.s1[0]")
© Vector Informatik GmbH
Version 1.0
- 31 -
User Manual AUTOSAR Calibration
Measuring and Calibrating of ECU Software
Example: /begin CHARACTERISTIC Test1.s0 ""
VALUE 0x2080D0 __ULONG_S 0 Test1.s0.CONVERSION 0 4294967295
ECU_ADDRESS_EXTENSION 0x0
EXTENDED_LIMITS 0 4294967295
FORMAT "%.15"
/end CHARACTERISTIC
Reference: Detailed information on the meaning of individual parameters can be
found in the ASAP2 specification
ASAM MCD-2 MC under the respective keyword.
3.3.2 Mode of Functioning Figure 3-12: Mode of functioning of the A2L
Engine speed as
Figure 3-12 illustrates the mode of functioning of an A2L file. The engine speed is
example
read out here as an example. Via the A2L file, the measurement and calibration
system (CANape) learns which memory address contains the engine speed and how
the ASAM MCD 1MC interface must be parameterized. The read-out raw value is
then converted to a physical value using a conversion rule described in the A2L file.
© Vector Informatik GmbH
Version 1.0
- 32 -
User Manual AUTOSAR Calibration
OEM
4 OEM In This Chapter You Will Find the Following Information: 4.1
Objective page 34
4.2
Content of the Performance Specifications page 34
4.3
Measurement Task page 34
4.4
Calibration Task page 35
4.5
XCP Features page 35
© Vector Informatik GmbH
Version 1.0
- 33 -
User Manual AUTOSAR Calibration
OEM
4.1 Objective Checklist for
This chapter serves as a checklist for creating performance specifications. The OEM
performance
must ensure that the indicated items are incorporated in the performance
specifications
specifications after careful consideration and as needed.
4.2 Content of the Performance Specifications The content of the performance specifications must define the desired requirements
for the supplier. These can be divided into mandatory and optional requirements.
Mandatory > Delivery of an A2L compatible with the software version
Requirements > Configured XCP driver
> Preconfigured CANape project
Optional > Build environment that can generate the A2L
Requirements > Delivery of a linker MAP file
The delivery of a linker MAP file has the advantage that new measurement and
calibration parameters can be incorporated directly into the A2L file. If a request to
measure additional objects arises during the course of a measurement task, the
memory addresses are known and these can be added.
4.3 Measurement Task Information to be
To realize the mandatory requirements relating to the measurement task, the supplier
communicated
requires some information, such as the category of the measurement parameters.
Various details about the DAQ configuration are also relevant both for the configured
XCP driver and for the A2L file.
Specifically, information on the following items must be communicated to the supplier:
> Category of the measurement parameters
> Software component
> Basic software
> BSW module (e.g., COM, CanNm)
> Runtime monitoring
> Event-triggered measuring via DAQ
> Static or dynamic DAQ lists
Vector recommends dynamic DAQ lists in order to make more efficient use of
the memory and, if necessary, to allow more signals to be measured.
> Definition of DAQ event time base
> Use of timestamps
> Use of DAQ default events
© Vector Informatik GmbH
Version 1.0
- 34 -
User Manual AUTOSAR Calibration
OEM
4.4 Calibration Task Items to be
The calibration task also affects the mandatory requirements (A2L file, XCP driver) for
considered
the supplier. The following items should be carefully considered here:
> Location of the calibration parameters
> Software component
> NVRAM
> Optimized "going online"
The accesses to the ECU are decreased when "going online" is optimized. An
upload operation is performed only if differences between the data in the memory
image and the ECU are identified. This procedure accelerates the "going online".
For optimized "going online", the use of a memory image is required. The
memory image is described on the basis of memory segments, which contain
only calibration parameters. In addition, the checksum calculation must be
implemented in the ECU.
Optimized "going online" is also a prerequisite for offline calibration and the use of
dataset management.
> Use of a flashable HEX file (with calibrated calibration parameters from CANape)
4.5 XCP Features Features to be
The XCP Driver section explained some aspects and features of the XCP protocol.
supported
Specifically, the following were explained: Measurement Modes, Autoselection and
Software Version Check of the A2L File, Online Calibration, Page Switching,
Bypassing, and Resume Mode. It is important here that the OEM communicates to
the supplier which of these features are to be supported by the XCP driver.
It is recommended to incorporate the following XCP features in the performance
specifications:
> Polling and DAQ measurement modes
> Autoselection of A2L and the software version check
> Online calibration
> Resume mode
© Vector Informatik GmbH
Version 1.0
- 35 -
User Manual AUTOSAR Calibration
Supplier
5 Supplier In This Chapter You Will Find the Following Information: 5.1
Preface page 37
5.2
Requirements page 37
5.3
Definition of Measurement and Calibration Parameters page 37
Measuring and Calibrating of AUTOSAR Software Components Measuring of Ports and Variables XCP Events Software Component with Calibration Parameters Calibration Parameters for Multiple Software Components Configuration of the RTE (Runtime Environment) Measuring and Calibrating Without the Support of the RTE Debugging of the BSW (Basic Software) 5.4
Configuration of the XCP Module page 42
DAQ List Configuration Tool-Driven DAQ Timestamp Option XCP Event Information Software Version Check Use of the XCP Component in the Implementation Recommendations for the Configuration of the XCP Module 5.5
Configuration of the Driver Modules page 48
CAN Module MICROSAR XCP 5.6
Configuration of the Memory Management page 48
Configuration for Resume Mode 5.7
Creating an A2L File page 49
Creation of a Master A2L File Expansion of the Master A2L File Working with ASAP2 Tool-Set Working with CANape and the ASAP2 Editor 5.8
Fast Access to the ECU Via the VX Module page 55
5.9
Additional Topics page 56
© Vector Informatik GmbH
Version 1.0
- 36 -
User Manual AUTOSAR Calibration
Supplier
5.1 Preface Certain functions and The measurement and calibration task assigned by the OEM is carried out in the
configurations for
implementation of the ECU software. When AUTOSAR-compliant software modules
AUTOSAR
are used, the modules must be configured appropriately and certain functions must
be implemented.
This chapter explains procedures for implementing the requirements for the ECU
software. The description refers to the MICROSAR product.
The first part describes the configuration of software components (SW-C), the
MICROSAR RTE, and the MICROSAR BSW module.
This is followed by a brief overview of the integration of the XCP slave. The XCP
slave is provided by the XCP module.
The final part describes the creation of the A2L description file, which will be a central
component of the CANape configuration.
5.2 Requirements Software
The following software components at least starting with the following versions are
components
required for the descriptions:
> Vector Informatik DaVinci Developer 3.0.110 (SP5)
> Vector Informatik DaVinci Configurator 4.1.1.2
> Vector Informatik ASAP2 Tool-Set 7.0
> Vector Informatik CANape 10.0 SP4
> Vector MICROSAR Basic Software starting with Release 14 including
MICROSAR XCP and MICROSAR RTE
5.3 Definition of Measurement and Calibration Parameters Via software
The measurement and calibration parameters for the measurement and calibration
components
task of the OEM are usually located in the software components (SW-C). These
parameters are defined with configuration tools, such as the DaVinci Developer.
Configuration of the RTE is also required for this.
Without RTE
Other measurement and calibration parameters can also be provided without the
support of AUTOSAR interfaces. A brief explanation is given in the Measuring and
Calibrating Without the Support of the RTE section.
Via A2L file
In addition, measurement parameters can also be added to the measurement
configuration within the AUTOSAR basic software. This is done by inserting known
measurement parameters from the basic software into the A2L file.
© Vector Informatik GmbH
Version 1.0
- 37 -
User Manual AUTOSAR Calibration
Supplier
5.3.1 Measuring and Calibrating of AUTOSAR Software Components Measurable objects
Measurable objects can be configured using a configuration tool, such as the DaVinci
Developer. Measurable objects include data elements (
data elements) of
application and service ports (
application port interfaces), variables for
communication between runnables (
inter-runnable variables), and calibration
parameters (
calibration parameters).
Figure 5-1: SW-C connected to ports Figure 5-2: SW-C with parameters for measuring/calibrating Calibration access
The objects indicated above can be made measurable by setting
Calibration Access to
ReadOnly in the DaVinci Developer. The
ReadWrite setting enables the writing of
objects with CANape. The writing of calibration parameters occurs in the common
"Calibration" use case of CANape. The writing of other data elements can be
configured but is not recommended. This is because the write access is not exclusive,
which means that information can be overwritten again.
Figure 5-3:
Measurement and
calibration option for an
object (e.g., data
element) Specifying calibration The AUTOSAR Standard provides the option of specifying calibration parameters.
parameters
Two variants are differentiated.
Calibration parameters can be defined within a software component. These are then
also available only for this software component.
The second variant is the use of a calibration software component that can provide
calibration parameters for multiple software components.
5.3.2 Measuring of Ports and Variables Configuration of the
Data elements to be measured must be configured appropriately with the help of the
data elements
Calibration & Measurement Support. For measuring,
Calibration Access must be
set to
ReadOnly.
The following data elements can be measured:
> Sender/Receiver Ports > Client/Server Ports (RTE not currently supported) > Inter-Runnable Variables > Calibration Parameters For
Sender and
Receiver Ports, the data elements can be easily configured for
calibrating via the
Properties.
© Vector Informatik GmbH
Version 1.0
- 38 -
User Manual AUTOSAR Calibration
Supplier
Figure 5-4:
Configuration of a
sender/receiver port Special case: Data
Sender/Receiver Ports for which a Data Mapping is defined represent a special
Mapping
case. For these ports, a direct (explicit) access and a buffered (implicit) access can
be configured as shown in Figure 5-5.
Figure 5-5: Access
definition of a port Ports that have explicit access configured can only be measured using the BSW
module COM. On the other hand, ports whose access was configured as buffered
can be measured using the RTE as well as the BSW module COM.
The measurement parameters are typically already preconfigured.
5.3.3 XCP Events RTE support
The RTE supports the generation of XCP events. For one thing, an event is created
for each task. These events are used to measure variables of the runnables that are
run within the task. The following should be noted in this regard:
> The RTE generates XCP events at the end of each task. An XCP event thus does
not have a direct relation to the running of a Runnable. It is therefore common
that a Runnable does not run continuously between XCP events.
> If XCP events are generated by the RTE, the DAQ measurement mode must also
be activated in the XCP module.
> It must thereby be anticipated that the XCP events of the RTE will be called very
often.
> The generated XCP events are not cyclic, so it is not possible to make a definitive
statement about the expected bus load.
© Vector Informatik GmbH
Version 1.0
- 39 -
User Manual AUTOSAR Calibration
Supplier
For another thing, the RTE also generates XCP events for the above-mentioned
access to buffered ports. By means of the description in the A2L file, it is ensured that
these ports are measured fixed with the generated event.
5.3.4 Software Component with Calibration Parameters External access
The definition of calibration parameters (
Calibration Parameter) makes it
possible to change a calibration parameter within the software component externally
via XCP.
Within the software component, access to this calibration parameter is read-only.
However, outside of the SW-C, the possibility exists to change this calibration
parameter.
Figure 5-6: Properties of a calibration parameter
A calibration parameter consists of a data type and an initial value. The scope
(
Scope) and the measurement and calibration access can be configured.
Note: For additional information about these parameters, refer to the online help for
the DaVinci Developer.
5.3.5 Calibration Parameters for Multiple Software Components Calibration-type
A calibration-type software component is used to provide calibration parameters for
software component
multiple software components.
This type of software component has only calibration ports (
Calibration Ports),
that provide calibration parameters for other SW-Cs and act as a sender port.
© Vector Informatik GmbH
Version 1.0
- 40 -
User Manual AUTOSAR Calibration
Supplier
Representation of a calibration software component in DaVinci Developer:
Figure 5-7: Graphic interface Figure 5-8: List with the configured ports Each calibration port, in turn, contains calibration parameters. These calibration
parameters are handled in just the same way as calibration parameters within a
software component.
5.3.6 Configuration of the RTE (Runtime Environment) RTE support
The support of the RTE is required in order to measure and calibrate software
necessary
components using the XCP protocol. The MICROSAR RTE Generator provides this
measurement and calibration support.
Reference: For an explanation of the activation of the measurement and calibration
support, refer to the technical referenc
e TechnicalReference_Asr_Rte, page 102ff.
Online calibration
CANape currently supports the following online calibration procedures:
procedures
> Initialized RAM
supported by
CANape
> Single Pointered
Initialized RAM
The standard calibration procedure with CANape is "Initialized RAM". This procedure
is suitable when the ECU has sufficient RAM memory for all calibration parameters to
be calibrated.
Single Pointered
The advantage of the "Single Pointered" calibration concept is that not all calibration
parameters constantly have a copy in the RAM memory. Therefore, this procedure
must be chosen when RAM memory capacity is limited.
When the ECU source code is generated by the DaVinci Developer, A2L fragments
are also generated. The integration of the created A2L fragments Rte.a2l and
Rte_XcpEvents.a2l is described in more detail in the Creating an A2L File section.
5.3.7 Measuring and Calibrating Without the Support of the RTE Points to be
The possibility exists to use measurement and calibration even without the support of
considered
the RTE.
The following points must be noted in this regard:
> Measurement via DAQ events requires that corresponding XCP events be
programmed and then described in the A2L file.
© Vector Informatik GmbH
Version 1.0
- 41 -
User Manual AUTOSAR Calibration
Supplier
Example: Integrating an XCP event within a runnable FUNC(void, RTE_CTAPMCU_APPL_CODE) RCtApMy_Algo(void)
{
// Perform algorithm within my runnable
...
// Trigger user defined XCP Event
XcpEvent(12);
}
> For online calibration, a separate implementation of the calibration method
("Initialized RAM" or AUTOSAR "Single Pointered") is required.
> Calibration and measurement requires one or more A2L files that are created
manually or with an external program (e.g., ASAP2 Creator or TargetLink). These
A2L files must be merged with the A2L files generated by the Vector tools. The
ASAP2 Merger program can be used for this (see description in th
e Creating an
A2L File section on page
49). 5.3.8 Debugging of the BSW (Basic Software) Modules which
MICROSAR AMD allows measuring BSW internal status information using XCP in
provide
order to ease debugging. For this purpose MICROSAR AMD provides measurement
measurement
parameters for by different MICROSAR modules such as COM, CANNM or CANTP.
parameters
Generating the A2L
For generating the A2L information GENy creates automatically the A2L fragments
information
bsw.a2l and bsw_xcp_events.a2l required for the A2L.
Reference: Information for configuration and detailed instructions are provided in the
User Manual AMD. 5.4 Configuration of the XCP Module Configuration tool
The XCP module is configured with the GENy software component configuration tool.
GENy
The source code for the XCP slave implementation is then generated based on this
configuration.
© Vector Informatik GmbH
Version 1.0
- 42 -
User Manual AUTOSAR Calibration
Supplier
Figure 5-9: Settings in GENy
Reference: Information and instructions on configuring the module can be found in
the TechnicalReference_XCP_Protocol_Layer document.
Preface
The most important configuration parameters are described below. In addition, the
optional XCP features
Measurement Modes and
Autoselection and Software Version
Check of the A2L File are described in the context of the XCP module.
5.4.1 DAQ List Configuration Implementation only
The XCP module currently has only the implementation for dynamic DAQ lists.
for dynamic DAQ
Predefined DAQ lists (static DAQ lists) are currently not supported by the XCP
lists
module. Static DAQ lists are not suitable for use of an XCP slave within an
AUTOSAR software stack. For one thing, these require an unnecessarily large
amount of memory. For another thing, when very many XCP events are implemented,
the maximum possible number of static lists may be exceeded if a fixed assignment is
used.
Amount of memory
The amount of memory provided for the DAQ configuration can be specified in the
space
XCP module.
The following formula can be used for the calculation:
Memory space f or D
AQ c
onfigurat ion [ bytes] 5max. n
umber of
m
easuremen s
t ignals per
m
easure
© Vector Informatik GmbH
Version 1.0
- 43 -
User Manual AUTOSAR Calibration
Supplier
5.4.2 Tool-Driven DAQ Timestamp Option Additional options for As described previously in the
Measurement Modes section, the possibility exists to
timestamps
use a timestamp of the ECU. To do so, this must be supported in the XCP driver. As
an additional option, the XCP driver can also supply the timestamp as a matter of
principle (timestamp fixed) or on request. The size of the timestamp (1, 2, 4 bytes per
event) should be chosen after careful consideration.
Example: The ECU uses a 1 µs counter for generating the DAQ timestamps. Only a 2-byte
timestamp is chosen.
As a result, the timestamp overflows every 65 ms. So that the MCD tool can
recognize an overflow,
at least one signal that supplies a measurement value and
thus also a timestamp at a more frequent interval than 65 ms must be measured in
the measurement setup.
5.4.3 XCP Event Information XCP slave to XCP
XCP event information can be provided in two ways by the XCP slave. Either by a
master
generated A2L file that contains the configured events or by the XCP command
GET_DAQ_EVENT_INFO which provides the event information directly from the ECU.
In both cases the event information has to be configured in the generation tool
accordingly.
Caution: If the GET_DAQ_EVENT_INFO feature is activated in the XCP module, the
automatically generated events of the RTE are not taken into consideration.
Recommendation: No RTE events are
If no RTE events are used, the functionality of the XCP event information can be
used:
used. However, attention must be paid that all events that are implemented are
described (including those of the BSW component).
RTE events are
Due to the fact that the GET_DAQ_EVENT_INFO feature overwrites all events defined
used:
in A2L files, deactivation of this feature is recommended if RTE events are used. In
this case the generated fragment XCP_events.a2l can be inserted into the master
A2L file (see the
Creating an A2L File section).
5.4.4 Software Version Check Aspects for
The possibilities for checking the software version were previously presented in the
implementation
Autoselection and Software Version Check of the A2L File section. Aspects for the
implementation are explained here.
XCP Station The Station Identifier should be centrally defined in an appropriate way and
Identifier (protocol afterwards only integrated. This can be achieved as follows:
command GET_ID) > Do not perform a manual configuration of the XCP identifier in GENy.
> Create a "User Defined" configuration containing, for example:
© Vector Informatik GmbH
Version 1.0
- 44 -
User Manual AUTOSAR Calibration
Supplier
Example: user_cfg.h: /* Standard commands */
#define kXcpStationIdLength 7u
extern CONST(XcpCharType, XCP_CONST) kXcpStationId[];
user_cfg.c:
CONST(XcpCharType, XCP_CONST) kXcpStationId[] = "EcuName_V1-2-
0";
If this information is integrated in the build process, the Station Identifier
EcuName_V1-2-0 is used.
EPK check It is recommended that the EPK identifier be generated automatically and consistently
with every compilation both in the source code and in the A2L file.
Ideally, the EPK is stored at a constant address in the ECU. This could look like this
in the source code:
Example: __attribute__((section("calflash_signature"))) const char
epk[26] = "EcuName V1.2.0 01.03.2012";
In the A2L file, the EPK identifier must also be implemented accordingly. For the
above example in the ECU software, the entry in the A2L file looks like:
Example: /begin MOD_PAR "EcuName"
ADDR_EPK 0x350002
EPK "EcuName V1.2.0 01.03.2012"
/end MOD_PAR
Checksum of code So that CANape can calculate the checksum of code segments, some information is
segments in the required. First, the code segments must be defined in the A2L file. Second, CANape
ECU (CANape 11.0 requires a HEX file that also contains the code segments.
and higher)
© Vector Informatik GmbH
Version 1.0
- 45 -
User Manual AUTOSAR Calibration
Supplier
5.4.5 Use of the XCP Component in the Implementation Figure 5-10: Interaction of the XCP module with AUTOSAR application
Interaction of XCP
1. For DAQ measurements, the basic software or the application calls the
module with
XcpEvent function.
AUTOSAR
application
2. The initialization routine of the application (within DriverInitTwo) calls
XcpInit.
3. The scheduler of the basic software calls XcpBackground periodically.
4. By means of the CanXcp functions, the application can be informed about CAN-
specific events.
Procedure for use
> All modules that require the XCP component must include the XcpProf.h
header file.
> The XCP component must be initialized in the initialization routine of the software
by calling the XcpInit function.
> A desired XCP service within the application can be used by calling a function, for
example XcpEvent (channel) with a corresponding channel/event number.
5.4.6 Recommendations for the Configuration of the XCP Module Check important
In general, every configuration parameter of the XCP module should be checked with
parameters
respect to its setting. Important parameters that should be assigned a different value
than the default value are described below. These can also be seen again directly in
GENy in
Figure 5-9. © Vector Informatik GmbH
Version 1.0
- 46 -
User Manual AUTOSAR Calibration
Supplier
General Settings
XCP Station Identifier
Manual specification of the file name of the
A2L file without the file name extension. Use
of the automatic name adaptation described
in the
Software Version Check section is
recommended.
Event Codes
Activate option.
Development Error Detection
Activate option during the development.
Table 5-1: Recommendations for the Configuration of the XCP Module: General Settings
Synchronous Data
Synchronous Data Acquisition (DAQ) Activate option (see the
DAQ List Acquisition (DAQ)
Configuration section)
Memory Size
A memory size of 2048 bytes has proven to
be adequate. The memory is reserved and
used exclusively for the DAQ configuration
and the Send Queue for the resume mode.
Prescaler
Activate option.
Write DAQ multiple
Activate option if CAN is not used as
Transport Layer.
Resume Mode
Activate option if the OEM requires this in the
performance specifications. If activated, the
memory size should be rechecked, since the
Send Queue should have appropriate
capacity.
General Info
Activate option.
STIM
Activate option if the OEM requires the
bypassing feature in the performance
specifications.
DAQ Timestamp
Activate option (see the
Tool-Driven DAQ
Timestamp Option section).
Fixed Timestamp
Activate option if CAN is not used as
Transport Layer.
Timestamp Size
Selection should be greater than or equal to
WORD (2 bytes).
Timestamp Unit + Ticks per Unit
The time unit for the timestamp should be less
than the smallest event cycle time.
Table 5-2: Recommendations for the Configuration of the XCP Module: DAQ
Block Transfer
Block Upload
Activate option.
Block Download
Activate option.
MIN_ST for Block Download
Check whether the ECU can process the
blocks on time without a loss of data.
Otherwise, a wait time should be configured
here.
Table 5-3: Recommendations for the Configuration of the XCP Module: Block Transfer
Checksum
Checksum
Activate option.
AUTOSAR CRC Module Support
Recommended if the AUTOSAR module is
present.
Table 5-4: Recommendations for the Configuration of the XCP Module: Checksum
© Vector Informatik GmbH
Version 1.0
- 47 -
User Manual AUTOSAR Calibration
Supplier
5.5 Configuration of the Driver Modules 5.5.1 CAN Module MICROSAR XCP Configuration
The CAN module MICROSAR XCP is configured with the GENy Software Component
Configuration tool.
The CAN messages for the XCP communication can be specified for MICROSAR
XCP.
The module is also responsible for creating the CanXCPAsr.a2l file.
Reference: Additional information is provided in the
Technical Reference XCP
Protocol Layer document.
5.6 Configuration of the Memory Management NVM module
The AUTOSAR Standard provides an NVM module for the memory management.
Measuring and calibrating generally have no direct points of contact with the memory
management.
The sole use case for configuring the NVM with regard to the XCP module is the use
of Resume Mode.
5.6.1 Configuration for Resume Mode Implementation
For implementation of Resume Mode, the XCP driver must store its DAQ
configuration in a non-volatile memory. Two pieces of information must be stored for
resume mode: first, the fact that the mode is active and, second, the DAQ
configuration itself.
For this a memory block large enough for the configuration is configured in the NVM
module. Its size can be derived from the buffer size configured in the XCP module.
Buffer size
The following formula can be used to calculate the buffer size:
Event
1
Signal
Buffer s
ize Buffer t ime
(Measureme
s
nt ignal
,j) Size of
t he t imestamp
cycle t ime
Eventi
i
i
j
API methods
The API methods provided by the NVM module can then be used in order to save and
load the configuration in the XCP module. This program part is not generated
automatically and must be programmed.
Reference: The methods to be implemented can be referenced in th
e Technical
Reference XCP Protocol Layer document.
© Vector Informatik GmbH
Version 1.0
- 48 -
User Manual AUTOSAR Calibration
Supplier
5.7 Creating an A2L File To complete the A2L The A2L description file contains all relevant information regarding the ECU. This
file, merge all
information is generated from various generators during the creation process.
relevant information
Information, such as the physical address, which is not available until the ECU
regarding the ECU
application has been created, is also needed.
All parts must be merged to ultimately obtain a complete A2L description file. The
addresses in the A2L file then still have to be updated.
Ideally, this process is incorporated into the automated creation process of the ECU
application.
5.7.1 Creation of a Master A2L File Note: MICROSAR XCP provides a _Master.a2l file as a template in the delivery
folder …\Misc\McData. All A2L files generated by Vector tools can be found in
…\GenData folder.
Goal
A master A2L file that merges all partial databases into one is required. This master
file can then be used as a template for the file to be created. The objective is to
ultimately obtain a single file containing all information.
Project-specific
This master A2L file is very project-specific. The information for an A2L file is created
master A2L file
by different generators. Some information is also added manually. For this reason,
the master A2L file is not created automatically.
Figure 5-11: Process for creating a master A2L file (example)
include commands The general structure of an A2L file is already described in
Figure 3-11: Structure of the A2L file. To merge the individual A2L fragments, include commands are used.
These are inserted accordingly to the modular structure (AML, General ECU
Implementation, IF_DATA and A2L Objects).
© Vector Informatik GmbH
Version 1.0
- 49 -
User Manual AUTOSAR Calibration
Supplier
To allow the merge of the individual memory segments running smoothly, project-
specific adaptions must be made in the master A2L file. These are marked
with // TODO:
Adaption of include For the below-named include commands the file paths may have to be adapted.
commands
Generally remove the appropriate includes if not required in the project.
Use of a text editor
The simplest procedure is to use a text editor to create and adapt the master A2L file.
Master A2L file
ASAP2_VERSION 1.60
/begin PROJECT ExampleProject ""
/begin MODULE MyModuleName ""
AML
/begin A2ML
...
block "IF_DATA" taggedunion if_data {
...
};
...
//TODO: Include AML Information if required.
/end A2ML
General ECU
/begin MOD_COMMON ""
implementation
// TODO: Set the Byte Order of the ECU as defined by the
ECUC module MSB_FIRST or MSB_LAST and configure the byte
alignment used in this project.
/end MOD_COMMON
/begin MOD_PAR ""
/include "GenData\Rte\
Rte_MemSeg.a2l"
// TODO: Add or include MEMORY_SEGMENT information here.
/end MOD_PAR
IF_DATA
/begin IF_DATA XCP
/include "GenData\
XCP.a2l"
/begin DAQ
// TODO: Add or include further a2l file splitter that
provide XCP Events.
/include "GenData\
XCP_daq.a2l"
/include "GenData\
XCP_events.a2l"
/include "Misc\McData\
Dlt_Events.a2l"
/include "GenData\Bsw\
bsw_xcp_events.a2l"
/include "GenData\Rte\
Rte_XcpEvents.a2l"
/end DAQ
/include "GenData\
CanXCPAsr.a2l"
/end IF_DATA
© Vector Informatik GmbH
Version 1.0
- 50 -
User Manual AUTOSAR Calibration
Supplier
A2L objects
// TODO: Add or include further a2l splitter that provide
measurement objects.
/include "Misc\McData\
Dlt.a2l /include "GenData\Bsw\
bsw.a2l"
/include "GenData\Rte\
Rte.a2l"
/include "GenData\
AmdRtm.a2l"
/end MODULE
/end PROJECT
5.7.2 Expansion of the Master A2L File Include commands A good approach for incorporating additional contents into the A2L file is the
expansion of the master A2L file using include commands. Copying additional
information directly and inserting it without include commands is not recommended.
Integrating of ECU
The A2L elements MOD_COMMON and MOD_PAR are best described in additional A2L
information (General files, which are manually integrated in the A2L file via an include command.
ECU
Implementation)
These include instructions are already inserted in the master file and accompany
the AUTOSAR Calibration user manual.
Integrating of
Some parts of the IF_DATA information are created by generators. These parts are
interface data
integrated via an include command. If additional manual information is to be added,
(Interface Data)
the creation of additional A2L files is recommended. These must be integrated in the
IF_DATA at the appropriate points. The merging of IF_DATA information from
various A2L files using the ASAP2 Merger is not supported.
The include instruction UserDefinedXcpEvents.a2l in the master file adds
manually defined XCP events to the IF_DATA section, for example.
Integrating of A2L
Partial databases containing measurement and calibration parameters are integrated
objects
most commonly. These files can be created, for example, by generators such as
(measurement and
Simulink, TargetLink, or the ASAP2 Creator.
calibration
Another example is the basic software, which also contains measurable objects.
parameters)
These files can be integrated manually using an additional include command, with
the help of the ASAP2 Tool-Set or the ASAP2 Editor.
Note: A file can only be added manually using an include command if the file
structure permits this. A complete A2L file cannot be added via include.
Example: A2L fragment – Inserting via include
command possible /CHARACTERISTIC
…
/MEASUREMENT
…
© Vector Informatik GmbH
Version 1.0
- 51 -
User Manual AUTOSAR Calibration
Supplier
Example: Complete A2L file – Inserting possible only via ASAP2 Merger /begin PROJECT ExampleProject ""
/begin MODULE MyModuleName ""
/CHARACTERISTIC
…
/MEASUREMENT
…
/end MODULE
/end PROJECT
5.7.3 Working with ASAP2 Tool-Set 5.7.3.1 Merging of Additional A2L Files Procedure for
A complete A2L file (as in the above example) cannot be embedded in the master
complete A2L files
A2L file using an include command. These types of A2L files can be merged using
the ASAP2 Merger program, which is part of the ASAP2 Tool-Set.
Figure 5-12: Integrating of A2L objects
Reference: The use of the ASAP2 Merger and its possible settings in the INI file are
described in the
ASAP2 Tool-Set user manual. Example: The generated Extern1.a2l and ExternN.a2l files are imported into the master A2L file
Master.a2l as a slave. The result of the merging is then written to the
ECU_merged.a2l file. Necessary settings are provided with the merger.ini file.
The merger.ini file must be present since the ASAP2 Merger adopts the setting
from this file at each command line call.
Command Line Call:
ASAP2Merger.exe -m Master.a2l -s Extern1.a2l -s ExternN.a2l -o
ECU_Merged.a2l -p "<INI_PATH>\merger.ini"
Merger.ini [OPTIONS]
MERGE_GROUP_CONTENTS = 1 // The contents of groups with the
same name will be merged
© Vector Informatik GmbH
Version 1.0
- 52 -
User Manual AUTOSAR Calibration
Supplier
DISABLE_SUFFIXES = 1 // Do not create suffixes for
imported objects
5.7.3.2 Update of the Addresses in the A2L File Necessity
It is necessary to update the measurement and calibration parameters in an A2L file
because the addresses of objects are not known until after the program code is
created (after compilation).
Further benefit
The update step can also be used to create, with the help of the master A2L file, a
complete A2L file that no longer has any Includes. The advantage of doing this is
that afterwards only one file has to be worked with and all partial databases do not
always have to be separately copied.
Figure 5-13: Update of
the addresses in the
A2L file Reference: The use of the ASAP2 Updater and its possible settings in the INI file are
described in the ASAP2 Tool-Set user manual.
Note: The _Updater.ini file can be found in the delivery folder …\Misc\McData.
It is supplied with the AUTOSAR Calibration user manual.
Template
The _Updater.ini file is provided as a template, which is indicated by the
_Updater.ini
underscore.
Necessary adaption
The _Updater.ini file needs to be adapted in any case, e.g. at least the
MAP_FORMAT must be specified. The array notation in [ ] is necessary because it is
used by MICROSAR that way.
Example: The Master.a2l file is read in and the addresses of the measurement and
calibration parameters are updated and written to the ECU.a2l file. The addresses
for the update are taken from the demo.elf file. Information of the update operation
is also written in the a2l.log file. Necessary settings are provided with the
updater.ini file. The ASAP2 Updater also always requires an updater.ini file.
Command Line Call:
ASAP2Updater.exe -I Master.a2l -O ECU.a2l -A demo.elf -L
a2l.log -T "<INI_PATH>\Updater.ini"
updater.ini:
[OPTIONS]
MAP_FORMAT=31 // Use ELF 32 Bit
© Vector Informatik GmbH
Version 1.0
- 53 -
User Manual AUTOSAR Calibration
Supplier
5.7.3.3 Step by Step Instructions with the ASAP2 Tool-Set Recommendation
The use of the ASAP2 Tool-Set is recommended because this can be integrated in an
automatic generation process. The address update and the export of the database
can be integrated as a post-build task.
STEP 1: A2L fragment generation So that A2L fragments are generated, the corresponding generators must be
configured. This is done by integrating these into the build process.
It must be ensured that the created A2L fragments are stored are a fixed location.
STEP 2: Manual creation of A2L fragments Information that the A2L file must subsequently contain but that is not automatically
generated must be manually created.
STEP 3: Adaptation of the master A2L file A master A2L file must be created. In the process, the paths of the include
commands must be adapted accordingly.
STEP 4: Merging of additional A2L files If complete A2L files must be integrated, the Merger of the ASAP2 Tool-Set must be
used. For this, the Merger must be called with appropriate parameters for each
additional complete A2L file.
STEP 5: Update of the addresses and export of the final file The final step is to configure the creation of the final A2L file. For this, the ASAP2
Updater is incorporated into the build process, which updates the addresses of the
measurement and calibration parameters. At the same time, a new final A2L
containing all included A2L fragments is created.
STEP 6: Use of the A2L file in CANape Following completion of these steps, a current A2L file should now be generated
automatically when the ECU software is created.
This final A2L file can then be used in CANape.
5.7.4 Working with CANape and the ASAP2 Editor Use exported
CANape and the ASAP2 Editor support an interactive procedure for carrying out the
databases without
actions described above. In this procedure, however, it must be ensured that the
include commands
master file with its include commands remains intact. The master A2L file should
therefore not be specified as a database for the ECU directly in CANape. Instead, an
exported database that contains no more include instructions must always be used.
Caution: When saving, the ASAP2 Editor overwrites the existing A2L file and
removes thereby the includes. For this reason always store only a copy.
INI-file
All project-specific settings of CANape are stored in the CANape.ini. Changes to
the configuration can be easily made via the user interface in CANape.
Note: The _CANape.ini file can be found in the delivery folder …\Misc\McData. It
is supplied with the AUTOSAR Calibration user manual.
© Vector Informatik GmbH
Version 1.0
- 54 -
User Manual AUTOSAR Calibration
Supplier
Template
The _CANape.ini file is provided as a template, which is indicated by the
underscore. The necessary presettings, such as for the export important notation [ ] of
arrays is already preconfigured to facilitate the implementation.
5.7.4.1 Step by Step Instruction STEP 1: A2L fragment generation So that A2L fragments are generated, the corresponding generators must be
configured. This is done by integrating these into the build process.
It must be ensured that the created A2L fragments are stored are a fixed location.
STEP 2: Manual creation of A2L fragments Information that the A2L file must subsequently contain but that is not automatically
generated must be manually created.
STEP 3: Insert INI file
Copy the definite CANape.ini file to the directory of the master A2L file.
STEP 4: Adaptation of the master A2L file A master A2L file must be created. In the process, the paths of the include
commands must be adapted accordingly.
STEP 5: Start the ASAP2 Editor Start the ASAP2 Editor and load the master A2L. The ASAP2 Editor will be used to
create the final A2L file.
STEP 6: Merging of additional A2L files The ASAP2 Editor can merge content from existing A2L databases. If complete, A2L
files must be integrated; the import functionality can be used. Either use
File | Import or
File | Add partial database from the application menu.
STEP 7: Update of the addresses The address update requires a configured MAP file. A MAP file can be added via the
database properties. After assigning a MAP file, the address can be updated via the
application menu
File | Update addresses.
STEP 8: Create final A2L file to use in CANape The master A2L file should not be altered with the ASAP2 Editor. A new A2L file
should be generated instead. This can be achieved by saving into a new database
using the application menu entry
File|Save as.
This final A2L file can then be used in CANape.
5.8 Fast Access to the ECU Via the VX Module Great measurement
An VX module is a scalable solution with maximum performance for measurement
bandwidth
and calibration tasks. The use of VX measurement hardware enables a greater
measurement bandwidth. The system forms the interface between the ECU and a
measurement and calibration tool such as CANape. For a high data throughput with
minimum runtime effects on the ECU, the data access occurs via microcontroller-
specific data trace and debug interfaces. The VX module is connected to the PC
using XCP on Ethernet. The VX measurement hardware is connected to the ECU via
a POD (Plug-On Device).
© Vector Informatik GmbH
Version 1.0
- 55 -
User Manual AUTOSAR Calibration
Supplier
Application notes
For information on general integration of a VX module (VX1000), refer to the following
application notes:
> AN-IMC-1-016 VX1000: Getting Started with Nexus JTAG and MPC5554
> AN-IMC-1-013 VX1000: Getting Started with Infineon XC2000
> AN-IMC-1-014 VX1000: Getting Started with Infineon TriCore
Note: These documents are available from the Vector Download Center.
5.9 Additional Topics Items to consider
The following items require additional consideration:
> Memory protection unit, ISO26262, Thread safety
> Limiting of runtime of a task or runnable
> MultiThreading
© Vector Informatik GmbH
Version 1.0
- 56 -
User Manual AUTOSAR Calibration
Delivery Test/Quick Start
6 Delivery Test/Quick Start Objectives
This chapter describes a delivery test for the A2L file created by the supplier.
However, it can also be used as a CANape Quick Start for the OEM.
Test of the A2L file
To ensure the completeness and the functionality of the delivered A2L file, a simple
delivery test can be performed with the help of CANape. If the A2L file is incomplete
or corrupt, an error appears when the file is inserted. If the insertion is successful, a
few measurement signals can be added to display windows for the test and a
measurement started. If no error appears, the A2L file is functional.
Perform delivery test (step by step instruction): 1. Copy the A2L file to an empty directory and connect the hardware.
2. Start CANape from this directory (right-click on
canape32.exe | Properties | Run in insert directory of the A2L file).
3. Use a drag & drop operation to move the A2L file to CANape.
If an error message appears, the A2L file is incomplete or corrupt. Otherwise, the
ECU is shown as online.
4. Open the Symbol Explorer
and expand the database under
Devices.
5. Select individual measurement and calibration parameters, use drag & drop to
move them onto the empty display page (see
Figure 6-1), and choose suitable
measurement and calibration windows.
Figure 6-1: Dragging measurement and calibration parameters onto display page 6. Start the measurement and calibrate the calibration parameters.
7. Check the required XCP features in the corresponding settings (for more detailed
information on each feature, refer to the CANape online help
or the XCP Features
in CANape section).
The delivery test is successful if no error message occurs, meaningful
measurement values are displayed in the display windows, calibration parameters
can be calibrated, and all desired XCP features can be found.
© Vector Informatik GmbH
Version 1.0
- 57 -
User Manual AUTOSAR Calibration
CANape Introduction
7 CANape Introduction In This Chapter You Will Find the Following Information: 7.1
Creation of a Project page 59
7.2
Device Configuration page 60
Devices Networks Vector Hardware XCP Features in CANape 7.3
Online Measurement Configuration page 64
Measurement Options Measurement Signals Recorder List Event List 7.4
Working with Parameter Set Files page 69
7.5
Dataset Management page 70
Tool-Based in CANape 11.0 and Higher 7.6
Offline Evaluation page 72
7.7
Flashing page 74
© Vector Informatik GmbH
Version 1.0
- 58 -
User Manual AUTOSAR Calibration
CANape Introduction
7.1 Creation of a Project First steps
A CANape project is created either using the selection dialog after starting CANape or
in CANape itself via
File | New project. Once a project name has been defined in the
first step, CANape suggests a project directory structure in the second step, in which
the project name is a subdirectory.
Figure 7-1: Creating the
project directory Working directory
This serves as a working directory for CANape and should be changed as required. It
typically contains the following:
> The CANape.ini initialization file, i.e., the global configuration of the project
> Several configuration files (*.cna), i.e., local configurations for individual
measurement and calibration tasks
> A subdirectory in which the measurement files are stored
> For each ECU:
> A subdirectory containing the A2L file
> A subdirectory in which its parameter set files are stored
> Other subdirectories, depending on the devices used (e.g., external
measurement equipment modules)
Definition of the
After the desired project directory structure has been specified, the new project is
devices
opened. The next step is to define the devices. An ECU description file in A2L format
or a diagnostic driver in ODX/CDD format is generally required for this. In the end, a
complete project has at least one configuration file (*.cna), the corresponding
initialization file (*.ini), and at least one ECU description file (*.a2l).
Figure 7-2 shows the recommended project directory structure.
© Vector Informatik GmbH
Version 1.0
- 59 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-2: Project
directory Prototype version
Folders for the project-relevant files are created for each prototype version release
release
X.Y of an ECU. The CANape configuration file (*.cna) and the canape.ini file are
located in folders in the
CANape 10 SP4 subdirectory. The Hex file, the databases
(*.a2l, *.cdd), and the network files (e.g., *.axml) are inserted as subfolders for
each prototype version release. In addition, the measurement, parameter set, and
script files are stored in their own folders.
7.2 Device Configuration Settings
The settings for
devices,
networks, and
channels can be modified and individual
devices and networks can be added in the device configuration. The device
configuration is accessed via the
icon or using
Device | Device configuration.
Graphic
The device configuration can also be represented graphically using the Device
representation
window. Double-clicking the individual icons opens the corresponding part of the
Device Configuration or the Database Editor.
© Vector Informatik GmbH
Version 1.0
- 60 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-3: Device window in CANape 11.0
7.2.1 Devices Creating new
The
Devices subitem of the Device Configuration displays all the created devices.
devices
Here, new ECUs can be created from a database or the MCD3 server, or completely
new ECUs can be created. In the latter case, CANape generates an A2L body that
the user must still configure and complete using the ASAP2 Editor. Besides the XCP
and CCP devices, diagnostic drivers or databases can also be used. An example of
integrating a diagnostic database and of using panels for this can found in the
installation directory of CANape under
Examples | ODX. A new device can be
created directly by dragging and dropping the database in CANape.
Bus monitoring
For the bus monitoring, the databases of the CAN bus (*.dbc), FlexRay bus
(*.fibex), and LIN bus (*.ldf) can be integrated in CANape. In the AUTOSAR
context, the possibility exists to use an AUTOSAR system description file (*.arxml)
in the case of the CAN or FlexRay bus.
Configuration
Corresponding dialog pages are available for configuring each created device.
Additional information regarding the configuration options can be found in the
CANape online help. Depending on the device status, the icon changes from green
(online) to yellow (offline) or red (inactive).
© Vector Informatik GmbH
Version 1.0
- 61 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-4: Device configuration
7.2.2 Networks Listing
The
Networks subitem lists all networks available in the current configuration.
Configuration
The following networks can be created in CANape: CAN, LIN, ETH, K-Line, FlexRay,
and MOST. The networks are configured on the corresponding dialog pages.
7.2.3 Vector Hardware Configuration of the
The configuration of the hardware is performed using the Vector Hardware. It can be
hardware
opened using
Device | Vector hardware configuration or in the
Channels | Vector section in the Device Configuration.
The appropriate hardware can be assigned to the respective channels using
Application | CANape. In so doing, the physical channel number does not have to
match the logical channel number. The possibility also exists to change the number of
channels for a particular bus system.
Figure 7-5: Vector Hardware Config
© Vector Informatik GmbH
Version 1.0
- 62 -
User Manual AUTOSAR Calibration
CANape Introduction
7.2.4 XCP Features in CANape Timestamp
The use of a timestamp can be specified in the Device Configuration in subitem
Protocol | Event List of the device. Depending on the implementation in the ECU,
the option also exists here to require a timestamp of the slave.
Figure 7-6: Timestamp in the device configuration
Resume mode
Whether or not resume mode is supported is indicated in the
Expert settings of the
DAQ Lists subitem.
Autoselection/
The autoselection and the software version check of the A2L file can also be set in
software version
the device configuration. This option can be found in the
Database subitem.
check
If the "Page Switching" or "Checksum calculation" options are used, these can be
found under Memory Segments of the device (se
e Figure 7-7). Online help
All XCP features are described in more detail in the CANape online help.
© Vector Informatik GmbH
Version 1.0
- 63 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-7: Page switching in the device window
7.3 Online Measurement Configuration Call
The complete measurement is configured in the online measurement configuration. It
is called via the
icon or using
Measurement | Measurement Configuration.
Display windows and Various display windows are available in order to display the measurement and
pages
calibration parameters. These windows are described in detail in the CANape online
help. In addition, several display pages can be created to enable a well-organized
complete configuration.
7.3.1 Measurement Options Behavior of the
The behavior of the measurement can be configured in the measurement options of
measurement
the measurement configuration. For example, the handling with polling signals during
the measurement or the size of the measurement buffer can be adapted. In addition,
a comment template for newly created measurement files can be specified here.
© Vector Informatik GmbH
Version 1.0
- 64 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-8: MDF
measurement comment
template 7.3.2 Measurement Signals Measureable signals All signals of the measurement configuration are listed on this page. Signals of the
database can be selected using
Edit | Insert Signal. Only the signals that are
contained in the measurement signal list or in the display windows of CANape are
measured. The option also exists to deactivate signals for individual measurements
instead of deleting and adding them again. For the case that a signal is to be
measured but not recorded, i.e., for performance and memory space reasons, the
Recorder option can be deactivated.
Measurement modes The measurement mode of the measurement signals leaves some of the
configuration options up to the user. The most commonly used measurement modes
are:
> Event: In event mode, the ECU sends the current measurement value of a signal
autonomously. The possible events and DAQ lists are defined in the ECU and
described in the A2L file.
> Polling: In polling mode, the measurement values of a signal are returned
asynchronously on request and according to the polling rate of the ECU. This
process is well suited for slower measurements when there are no requirements
for synchronous polling.
> Cyclic: In XCP and CCP, the cyclic measurement mode corresponds to the event
measurement mode. A data reduction can be achieved based on its cycle time.
> On key: When a key (combination) is entered, the signal is requested (polling).
> On trigger: When a trigger event occurs (StartTrigger, StopTrigger,
LastTriggerFinished), CANape measures the desired signal (polling).
> On event: When a particular system event occurs (e.g., measurement start), the
signal is measured (polling).
Measurement rate
The measurement rate is displayed to the right of the displayed measurement mode
in the measurement configuration of the measurement signals. It indicates the
recording rate in polling or cyclic mode. The rate is specified as a time interval
between two measurement values, in milliseconds.
© Vector Informatik GmbH
Version 1.0
- 65 -
User Manual AUTOSAR Calibration
CANape Introduction
Bus utilization
The bus utilization and the measurement events for the selected device are listed at
the bottom of the measurement configuration. Here the bar indicates the percentage
utilization of the individual event time bases and the bus.
Online help
In addition to the signals of the individual databases, additional measurement signals
such as global variables can also be incorporated into the measurement
configuration. For more detailed information on this, refer to the CANape online help.
Figure 7-9: Measurement configuration: Measurement signals list
Inserting signals
With the help of the Symbol Explorer
, individual measurement signals can be
inserted directly in a display window using a drag & drop operation. These are
automatically added to the measurement signal list.
Shortening rule
To improve the readability of long measurement signal names in the Symbol Explorer,
a shortening rule can be specified using
Tools | Options, section
Display | Object
Names.
© Vector Informatik GmbH
Version 1.0
- 66 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-10: Setting of
a name shortening rule This indicates the start of the signal name only and is limited in the display to the last
part after the specified separator.
Figure 7-11: Example
for use of a name
shortening rule 7.3.3 Recorder List Definitions/Settings
The recorder list in the measurement configuration provides an overview of the
defined recorders. The option exists to deactivate individual recorders in order to
realize different measurement tasks. The setting of the file name of the MDF file can
be made individually for each recorder. Here, it is possible to use different macros in
order, for example, to record the time of day in the file name. Under the
Options area, various settings can be made for each recorder. A detailed explanation of these
settings can be found in the CANape online help.
© Vector Informatik GmbH
Version 1.0
- 67 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-12: Measurement configuration: Recorder list
Trigger of recordings In addition to the most straightforward measurement in which all signals are recorded
over the entire measurement period, the possibility also exists to trigger the recording
of individual signals by certain events. These are defined in more detail in the
Trigger area.
Figure 7-13: Trigger condition
Start events
The selection menu of the
[New] button can be used to select various start events.
The following categories are available for selection here:
> System events (messages from the PC or the ECU)
> Signal events (values from active measurement)
> Keyboard events (operator inputs)
Stop event
These events are also available again as a stop event. However, a time limitation can
also be chosen as a stop event.
© Vector Informatik GmbH
Version 1.0
- 68 -
User Manual AUTOSAR Calibration
CANape Introduction
Assign signals to
The measurement signals that are recorded by this recorder are indicated under
All recorders
recorder signals. Signals can be assigned to individual recorders so that these are
recorded only when the trigger condition occurs.
7.3.4 Event List Overall event list
The
Event list section of the Measurement Configuration lists all events with their
properties. Here it can be seen whether the event is an ECU event or a general
system event. The defined trigger events are also displayed here.
Definition of new
New events are defined using the context menu. These are then available in the
events
measurement signal list as a measurement mode so that, for example, a signal is
measured only after a particular key has been pressed.
Figure 7-14: Measurement configuration - Event list
7.4 Working with Parameter Set Files Purposes for saving
CANape offers the option to perform online calibration of calibration parameters and
parameter set files
to save these as a parameter set file. These files are then used mainly for two
purposes:
> For saving the current version and for documenting and/or exchanging parameter
values
Different options are available for selection for saving the calibration parameters.
First, the parameters of a single calibration window can be saved by selecting
Save in the popup menu of the Calibration window. Second, all the parameters of
all Calibration windows can also be saved. This can be done using
Calibration |
Save all calibration windows. In addition, the possibility exists to select
© Vector Informatik GmbH
Version 1.0
- 69 -
User Manual AUTOSAR Calibration
CANape Introduction
particular parameters via a filter (
Calibration | Save parameter set as).
> In order to bring the system to a defined state
Several functions are also available for loading a parameter set file. Calibration
parameters in a particular calibration window can also be opened here by
selecting
Load in the popup menu of the Calibration window. Particular
calibration parameters can also be selected using
Calibration | Load parameter
set from.
7.5 Dataset Management Definition of dataset
A dataset is a set of various parameters at a particular point in time within the edit
history. It normally contains all parameters that belong to an ECU and is represented
via the following files:
> Database file (A2L file)
> Memory image content (HEX file)
> Parameter set file (only for datasets from the eCDM system)
The dataset is the central object for the versioning and configuring of parameters.
7.5.1 Tool-Based in CANape 11.0 and Higher Dataset
In CANape 11.0, a convenient dataset management tool has been introduced. The
management
[Dataset Management] can be called via the device configuration. Here, various
datasets of an ECU can be added. New datasets (A2L+HEX, HEX or uncoded) can
be added on the Datasets tab using the
icon. Additional settings are available in
the context menu. The
Timestamps tab shows the snapshots of the calibration
history and indicates their timestamp.
© Vector Informatik GmbH
Version 1.0
- 70 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-15: Dataset
management in
CANape 11.0 Working with multiple The datasets are then displayed and can be activated in the Symbol Explorer. This
datasets
provides a convenient means for working with multiple datasets within a project.
© Vector Informatik GmbH
Version 1.0
- 71 -
User Manual AUTOSAR Calibration
CANape Introduction
Figure 7-16: Dataset
management in the
Symbol Explorer Demo project
The
Examples folder of the CANape installation directory contains a demo project
named Datasets_Thesaurus, which illustrates the use of the dataset management
using an example.
7.6 Offline Evaluation Read in
For purposes of offline evaluation, measurement data can be read in using
Analysis | measurement data
Show values from measurement file.
Measurement File
The
Measurement File Manager (can also be opened via the
Analysis menu item)
Manager
shows all loaded MDF files as well as the virtual MDF channels. Several possible
settings are available in the toolbar of the Measurement File Manager. These are
described in detail in the CANape online help.
Data Mining
An automatic procedure for offline evaluation of loaded MDF files is available under
Analysis | Data Mining. The option exists, for example, to find the times at which the
speed exceed 3000 rpm. In so doing, it is possible to evaluate multiple measurement
files with measurement signal names as identical as possible in a single search.
These are specified in the
File filter list section. The option of using wildcards
(*.mdf) is also available.
© Vector Informatik GmbH
Version 1.0
- 72 -
User Manual AUTOSAR Calibration
CANape Introduction
Calculation methods
The calculation methods are configured in the
Methods section. The following are
available for selection here:
> Function (based on user-defined functions that are created in the function editor
or from the global function library)
> MATLAB/Simulink model (based on MATLAB/Simulink models that are available
as DLL)
> Arithmetic condition (based on user-defined criteria)
> Script (defined in the Functions Editor)
Definition of
Figure 7-17 shows the definition of an algebraic condition. The time range to be
algebraic conditions
evaluated can be set under
Extended.
Figure 7-17: Data Mining: Creating an algebraic condition
Naming analysis files The desired file name of the analysis file can be entered in the
Options section. The
name can contain various macros that can be inserted using the corresponding
button.
Further settings
In addition, it is possible to limit the number of hits per file. It is useful to specify a
creation date of the file to be searched if only the measurement data starting from a
certain date are to be evaluated.
Output in CSV format The results can also be output in CSV format for further analysis. The desired
separator for the measurement data should be indicated in the selection menu in this
section.
© Vector Informatik GmbH
Version 1.0
- 73 -
User Manual AUTOSAR Calibration
CANape Introduction
Executing scripts
Scripts that are executed before starting the analysis, before the analysis of each file,
after the analysis of each file, or after finishing the complete analysis can also be
specified.
Example of Data
A detailed example of Data Mining can be found in the installation directory of
Mining
CANape under
Examples | DataMining.
7.7 Flashing Flash tools
Other Flash tools, such as vFlash can be opened from CANape.
Online help
Additional information on the topic of flashing with CANape can be found in the
CANape online help.
© Vector Informatik GmbH
Version 1.0
- 74 -
User Manual AUTOSAR Calibration
Addresses
8 Addresses Addresses on Vector Please find the contacts of Vector Informatik GmbH and all subsidiaries worldwide
homepage
via:
http://www.vector.com/vi_addresses_en.html
© Vector Informatik GmbH
Version 1.0
- 75 -
User Manual AUTOSAR Calibration
Abbreviations
9 Abbreviations Abbreviation Description ASAM
Association for
Standardization of
Automation and
Measuring Systems
AUTOSAR
AUTomotive
Open
System
ARchitecture
BSW
Basic
soft
ware
CSA
Common
Software
Architecture
CTO
Command
Transfer
Object
DAQ
Data
Acquisition
DTO
Command
Transfer
Object
E/E Architecture
Electrical/electronic architecture
EPK
EPROM-
Kennung (EPROM identifier)
EPROM
Erasable
Programmable
Read
Only
Memory
MCD System
Measurement
Calibration, and
Diagnostics System
ODT
Object
Description
Table
RTE
Runtime
Environment
SW-C
Soft
ware
Component
VFB
Virtual
Function
Bus
© Vector Informatik GmbH
Version 1.0
- 76 -
Get more Information! Visit our Website for: > News
> Products
> Demo Software
> Support
> Training Classes
> Addresses
www.vector.com
Document Outline
10 - XCP_ReferenceBook_V3.0_ENs
XCP – The Standard Protocolfor ECU Development
Fundamentals and Application AreasAndreas Patzer | Rainer Zaiser
Andreas Patzer | Rainer ZaiserXCP – The Standard Protocol for ECU Development
Date December 2016
Reproduction only with expressed permission from
Vector Informatik GmbH, Ingersheimer Str. 24, 70499 Stuttgart, Germany
© 2016 by Vector Informatik GmbH. All rights reserved. This book is only intended for personal use, but not
for technical or commercial use. It may not be used as a basis for contracts of any kind. All information in this
book was compiled with the greatest possible care, but Vector Informatik does not assume any guarantee or
warranty whatsoever for the correctness of the information it contains. The liability of Vector Informatik is
excluded, except for malicious intent or gross negligence, to the extent that laws do not make it legally liable.
Information contained in this book may be protected by copyright and / or patent rights. Product names of
software, hardware and other product names that are used in this book may be registered brands or otherwise
protected by branding laws, regardless of whether or not they are identified as registered brands.
XCPThe Standard Protocolfor ECU DevelopmentFundamentals and Application AreasAndreas Patzer, Rainer Zaiser
Vector Informatik GmbH
Table of ContentsIntroduction ...........................................................................................................................................
71 Fundamentals of the XCP Protocol ...........................................................................................
131.1 XCP Protocol Layer ................................................................................................................
19
1.1.1 Identification Field ........................................................................................................21
1.1.2 Timestamp .....................................................................................................................21
1.1.3 Data Field ...................................................................................................................... 22
1.2 Exchange of CTOs ..................................................................................................................
22
1.2.1 XCP Command Structure .......................................................................................... 22
1.2.2 CMD ................................................................................................................................ 25
1.2.3 RES .................................................................................................................................. 28
1.2.4 ERR .................................................................................................................................. 28
1.2.5 EV .................................................................................................................................... 29
1.2.6 SERV ............................................................................................................................... 29
1.2.7 Calibrating Parameters in the Slave ....................................................................... 29
1.3 Exchanging DTOs – Synchronous Data Exchange .........................................................
32
1.3.1 Measurement Methods: Polling versus DAQ ......................................................... 33
1.3.2 DAQ Measurement Method ...................................................................................... 34
1.3.3 STIM Calibration Method ........................................................................................... 42
1.3.4 XCP Packet Addressing for DAQ and STIM ........................................................... 43
1.3.5 Bypassing = DAQ + STIM ........................................................................................... 45
1.3.6 Time Correlation and Synchronization ................................................................... 45
1.4 XCP Transport Layers ...........................................................................................................
49
1.4.1 CAN ................................................................................................................................. 49
1.4.2 CAN FD .......................................................................................................................... 52
1.4.3 FlexRay ........................................................................................................................... 54
1.4.4 Ethernet ......................................................................................................................... 57
1.4.5 SxI .................................................................................................................................... 59
1.4.6 USB ................................................................................................................................ 60
1.4.7 LIN .................................................................................................................................. 60
1.5 XCP Services ............................................................................................................................
61
1.5.1 Memory Page Swapping .............................................................................................61
1.5.2 Saving Memory Pages – Data Page Freezing ....................................................... 63
1.5.3 Flash Programming ..................................................................................................... 63
1.5.4 Automatic Detection of the Slave ........................................................................... 65
1.5.5 Block Transfer Mode for Upload, Download and Flashing .................................66
1.5.6 Cold Start Measurement ........................................................................................... 67
1.5.7 Security Mechanisms with XCP ................................................................................68
2 ECU Description File A2L .............................................................................................................
712.1 Setting Up an A2L File for an XCP Slave .........................................................................
74
2.2 Manually Creating an A2L File ............................................................................................
75
2.3 A2L Contents versus ECU Implementation .....................................................................
763 Calibration Concepts ...................................................................................................................
793.1 Parameters in Flash ..............................................................................................................
80
3.2 Parameters in RAM ................................................................................................................
82
3.3 Flash Overlay ...........................................................................................................................
84
3.4 Dynamic Flash Overlay Allocation .....................................................................................
85
3.5 RAM Pointer Based Calibration Concept per AUTOSAR .............................................
86
3.5.1 Single Pointer Concept ...............................................................................................86
3.5.2 Double Pointer Concept .............................................................................................88
3.6 Flash Pointer Based Calibration Concept .......................................................................
894 Application Areas of XCP ............................................................................................................
91
4.1 Model in the Loop (MIL) .......................................................................................................
93
4.2 Software in the Loop (SIL) ..................................................................................................
94
4.3 Hardware in the Loop (HIL) .................................................................................................
95
4.4 Rapid Control Prototyping (RCP) ......................................................................................
97
4.5 Bypassing ..................................................................................................................................
98
4.6 Shortening Iteration Cycles with Virtual ECUs ...........................................................
1015 Example of an XCP Implementation ......................................................................................
105
5.1 Description of Functions ....................................................................................................
108
5.2 Parameterization of the Driver ........................................................................................
1106 Protocol Development Overview ..............................................................................................
111
6.1 XCP Version 1.1 (2008) .........................................................................................................
112
6.2 XCP Version 1.2 (2013) ..........................................................................................................
112
6.3 XCP Version 1.3 (2015)..........................................................................................................
113The Authors.....................................................................................................................................
114
Table of Abbreviations and Acronyms .....................................................................................
116
Literature ........................................................................................................................................
117
Web Addresses...............................................................................................................................
117
Table of Figures .............................................................................................................................
118
Appendix – XCP Solutions at Vector ......................................................................................
120
Index .................................................................................................................................................
122
Introduction
7
IntroductionIn optimal parameterization (calibration) of electronic ECUs, you calibrate parameter values
during the system runtime and simultaneously acquire measured signals. The physical con
nection between the development tool and the ECU is via a measurement and calibration
protocol. XCP has become established as a standard here.
First, the fundamentals and mechanisms of XCP will be explained briefly and then the appli
cation areas and added value for ECU calibration will be discussed.
First, some facts about XCP:
> XCP signifies “Universal Measurement and Calibration Protocol”. The “X” stands for the
variable and interchangeable transport layer.
> It was standardized by an ASAM working committee (Association for Standardisation of
Automation and Measuring Systems). ASAM is an organization of automotive OEMs, sup
pliers and tool producers.
> XCP is the protocol that succeeds CCP (CAN Calibration Protocol).
> The conceptual idea of the CAN Calibration Protocol was to permit read and write access
to internal ECU data over CAN. XCP was developed to implement this capability via dif
ferent transmission media. Then one speaks of XCP on CAN, XCP on FlexRay or XCP on
Ethernet.
> The primary applications of XCP are measurement and calibration of internal ECU para
meters. Here, the protocol offers the ability to acquire measured values “event synchro
nous” to processes in ECUs. This ensures consistency of the data between one another.
To visualize the underlying idea, we initially view the ECU and the software running in it as a
black box. In a black box, only the inputs into the ECU (e.g. CAN messages and sensor values)
and the output from the ECU (e.g. CAN messages and actuator drives) are acquired. Details
about the internal processing of algorithms are not immediately apparent and can only be
determined from an analysis of the input and output data.
Now imagine that you had a look into the behavior of your ECU with every computation
cycle. At any time, you could acquire detailed information on how the algorithm is running.
You would no longer have a black box, but a white box instead with a full view of internal
processes. That is precisely what you get with XCP!
What contribution can XCP make for the overall development process? To check the func
tionality of the attained development status, the developer can execute the code repeatedly.
In this way, the developer finds out how the algorithm behaves and what might be opti
mized. It does not matter here whether a compiled code runs on a specific hardware or
whether it is developed in a modelbased way and the application runs in the form of a
model.
A central focus is on the evaluation of the algorithm process. For example, if the algorithm
is running as a model in a development environment, such as Simulink from The MathWorks,
it is helpful to developers if they can also acquire intermediate results to their applications,
in order to obtain findings about other changes. In the final analysis, this method enables
nothing other than read access to parameters so that they can be visualized and analyzed –
8
Introduction
and all of this at model runtime or retrospectively after a timelimited test run has been
completed. A write access is needed if parameterizations are changed, e.g. if the propor
tional component of a PID controller is modified to adapt the algorithm behavior to the
system under control. Regardless of where your application runs – focal points are always
the detailed analysis of algorithm processes and optimization by changes to the
parameterization.
This generalization can be made: The algorithms may exist in any type of executable form
(code or model description). Different systems may be used as the runtime environment
(Simulink, as DLL on the PC, on a rapid prototyping platform, in the ECU etc.). Process flows
are analyzed by read access to data and acquisition of its timebased flow. Parameter sets
are modified iteratively to optimize algorithms. To simplify the representation, the acquisi
tion of data can be externalized to an external PCbased tool, although it is understood here
that runtime environments themselves can even offer analysis capabilities.
Runtime Environment
Application
Communication
PC Tool
Figure 1: Operating System
Fundamental
communication with a runtime environmentThe type of runtime environment and the form of communication generally differ from one
another considerably. The reason is that the runtime environments are developed by differ
ent producers and are based on different solution approaches. Different types of protocols,
configurations, measurement data formats, etc. make it a futile effort to try to exchange
parameter sets and results in all development steps. In the end, however, all of these solu
tions can be reduced to read and write access at runtime. And there is a standard for this:
XCP.
XCP is an ASAM standard whose Version 1.0 was released in 2003. The acronym ASAM
stands for “Association for Standardisation of Automation and Measuring Systems.” Sup
pliers, vehicle OEMs and tool manufacturers are all represented in the ASAM working group.
The purpose of the XCP working group is to define a generalized measurement and calibra
tion protocol that can be used independent of the specific transport medium. Experience
gained from working with CCP (CAN Calibration Protocol) flowed into the development as
well.
XCP was defined based on the ASAM interfaces model. The following figure shows a mea
surement and calibration tool’s interfaces to the XCP Slave, to the description file and the
connection to a higherlevel automation system.
Introduction
9
Upper Level
Automation System
ASAM MCD-3 MC
Measurement and
ASAM
Calibration System
MCD-2 MC
*.A2L
XCP DriverECU Description File
ASAM MCD-1 MC
XCP DriverECU
Figure 2: The Interface Model
of ASAMInterface 1: “ASAM MCD-1 MC” between ECU and measurement & calibration system
This interface describes the physical and the protocolspecific parts. Strictly speaking, a dis
tinction was made between interfaces ASAP1a and ASAP1b here. The ASAP1b interface,
however, never received general acceptance and for all practical purposes it has no relevance
today. The XCP protocol is so flexible that it can practically assume the role of a general
manufacturerindependent interface. For example, today all measurement and calibration
hardware manufacturers offer systems (xETK, VX1000, etc.) which can be connected via
the XCP on Ethernet standard. An ASAP1b interface – as it was still described for CCP – is
no longer necessary.
Interface 2: “ASAM MCD-2 MC” A2L ECU description file
As already mentioned, XCP works in an addressoriented way. Read or write accesses to
objects are always based on an address entry. Ultimately, however, this would mean that
the user would have to search for his ECU objects in the Master based on the address. That
would be extremely inconvenient. To let users work with symbolic object names, for example,
a file is needed that describes the relationship between the object name and the object
address. The next chapter is devoted to this A2L description file.
Interface 3: “ASAM MCD-3 MC” automation interface
This interface is used to connect another system to the measurement and calibration tool,
e.g. for test bench automation. The interface is not further explained in this document,
because it is irrelevant to understanding XCP.
10
Introduction
XCP is based on the MasterSlave principle. The ECU is the Slave and the measurement and
calibration tool is the Master. A Slave may only communicate with one Master at any given
time; on the other hand, the Master can simultaneous communicate with many Slaves.
Master
Bus
Figure 3:
An XCP Master can
simultaneously Slave
Slave
Slave
Slave
communicate with multiple SlavesTo be able to access data and configurations over the entire development process, XCP
must be used in every runtime environment. Fewer tools would need to be purchased, oper
ated and maintained. This would also eliminate the need for manual copying of configura
tions from one tool to another, a process that is susceptible to errors. This would simplify
iterative loops, in which results from later work steps are transferred back to prior work
steps.
But let us turn our attention away from what might be feasible to what is possible today:
everything! XCP solutions are already used in a wide variety of work environments. It is the
intention of this book to describe the main properties of the measurement and calibration
protocol and introduce its use in the various runtime environments. What you will not find in
this book: neither the entire XCP specification in detailed form, nor precise instructions for
integrating XCP drivers in a specific runtime environment. It explains the relationships, but
not the individual protocol and implementation details. Internet links in the appendix refer
to openly available XCP driver source code and sample implementations, which let you
understand and see how the implementation is made.
Screenshots of the PC tool used in this book were prepared using the CANape measurement
and calibration tool from Vector. Other process flows are also explained based on CANape, in
cluding how to create an A2L file and even more. With a costfree demo version, which is avail
able to you in the Download Center of the Vector website at www.vector.com/canape_demo,
you can see for yourself
1 Fundamentals of the XCP Protocol
13
1 Fundamentals of the XCP Protocol
14
1 Fundamentals of the XCP Protocol
Interface 1 of the ASAM interfaces model describes sending and receiving commands and
data between the Slave and the Master. To achieve independence from a specific physical
transport layer, XCP was subdivided into a protocol layer and a transport layer.
CAN
Ethernet FlexRay
SxI
USB
...
Figure 4: Subdivision of the XCP protocol into protocol layer and transport layerDepending on the transport layer, one refers to XCP on CAN, XCP on Ethernet, etc. The
extendibility to new transport layers was proven as early as 2005 when XCP on FlexRay
made its debut. The current version of the XCP protocol is Version 1.3, which was approved
in 2015.
Adherence to the following principles was given high priority in designing the protocol:
> Minimal resource usage in the ECU
> Efficient communication
> Simple Slave implementation
> Plugandplay configuration with just a small number of parameters
> Scalability
1 Fundamentals of the XCP Protocol
15
A key functionality of XCP is that it enables read and write access to the memory of the
Slave.
Read access lets users measure the time response of an internal ECU parameter. ECUs are
systems with discrete time behavior, whose parameters only change at specific time inter
vals: only when the processor recalculates the value and updates it in RAM. One of the great
strengths of XCP lies in acquiring measured values from RAM which change synchronously
to process flows or events in the ECU. This lets users evaluate direct relationships between
timebased process flows in the ECU and the changing values. These are referred to as
eventsynchronous measurements. The related mechanisms will be explained later in detail.
Write access lets the user optimize parameters of algorithms in the Slave. The accesses are
addressoriented, i.e. the communication between Master and Slave references addresses in
memory. So, the measurement of a parameter is essentially implemented as a request of
the Master to the Slave: “Give me the value of memory location 0x1234”. Calibration of a
parameter – the write access – to the Slave means: “Set the value at address 0x9876 to 5”.
An XCP Slave does not absolutely need to be used in ECUs. It may be implemented in differ
ent environments: from a modelbased development environment to hardwareintheloop
and softwareintheloop environments to hardware interfaces that are used to access ECU
memory via debug interfaces such as JTAG, NEXUS and DAP.
Simulink
Slave
Prototype or
ECU Hardware
Slave
Measurement/
XCPCalibration
Master
Slave
PC
Hardware*
EXE/DLL
Slave
HIL/SIL Systems
Figure 5:
XCP Slaves can be Slave
used in many
different runtime * Debug Interfaces, Memory Emulator ...
environments
16
1 Fundamentals of the XCP Protocol
How can algorithms be optimized using read and write access to the ECU and what bene
fits does this offer? To be able to modify individual parameters at runtime in the ECU, there
must be access to them. Not every type of memory permits this process. It is only possible
to perform a read and write access to memory addresses in RAM (intentionally excluding
the EEPROM here). The following is a brief summary of the differences between individual
memory technologies: knowledge of them is very important to understanding over the fur
ther course of this book.
Memory FundamentalsToday, flash memories are usually integrated in the microcontroller chips for ECUs and are
used for longterm storage of code and data, even without power supply. The special aspect
of a flash memory is that read and write access to individual bytes is indeed possible at any
time, but writing of new contents can only be done blockwise, usually in rather large blocks.
Flash memories have a limited life, which is specified in terms of a maximum number of era
sure cycles (depending on the specific technology the maximum may be up to one million
cycles). This is also the maximum number of write cycles, because the memory must always
be erased as a block before it can be written again. The reason for this lies in the memory
structure: electrons are “pumped” via tunnel diodes. A bit is stored at a memory location as
follows: electrons must be transported into the memory location over an electrically insulating
layer. Once the electrons are then behind the insulating layer, they form an electric field with
their charge, which is interpreted as a 1 when reading the memory location. If there are no
electrons behind the layer, the cell information is interpreted as a 0. A 1 can indeed be set in
this way, but not a 0. Setting to 0 (= erasing the 1) is performed in a separate erasing routine,
in which electrons existing behind the insulating layer are discharged. However, for architec
tural reasons, such an erasing routine does not just act on single bytes, rather only on the
group or block level. Depending on the architecture, blocks of 128 or 256 bytes are usually used.
If one wishes to overwrite a byte within such a block, the entire block must first be erased.
Then the entire contents of the block can be written back.
When this erasing routine is repeated multiple times, the insulating layer (“Tunnel Oxide Film”)
can be damaged. This means that the electrons could slowly leak away, changing some of the
information from 1 to 0 over the course of time. Therefore, the number of allowable flash
cycles is severely limited in an ECU. In the production ECU, it is often only on the order of single
digit numbers. This restriction is monitored by the Flash Boot Loader, which uses a counter to
keep track of how many flash operations have already been executed. When the specified
number is exceeded, the Flash Boot Loader rejects another flash request.
A RAM (Random Access Memory) requires a permanent power supply; otherwise it loses its
contents. While flash memory serves the purpose of longterm storage of the application,
the RAM is used to buffer computed data and other temporary information. Shutting off
the power supply causes the RAM contents to be lost. In contrast to flash memory, it is easy
to read and write to RAM.
1 Fundamentals of the XCP Protocol
17
This fact is clear: if parameters need to be changed at runtime, it must be assured that they
are located in RAM. It is really very important to understand this circumstance. That is why
we will look at the execution of an application in the ECU based on the following example:
In the application, the y parameters are computed from the sensor values x.
// Pseudocode representation
a = 5;
b = 2;
y = a * x + b;
If the application is flashed in the ECU, the controller handles this code as follows after
booting: the values of the x parameters correspond to a sensor value. At some time point,
the application must therefore poll the sensor value and the value is then stored in a mem
ory location assigned to the x parameters. Since this value always needs to be rewritten at
runtime, the memory location can only lie in RAM.
The parameter y is computed. The values a and b, as factor and offset, are included as infor
mation in flash memory. They are stored as constants there. The value of y must also be
stored in RAM, because once again that is the only place where write access is pos sible. At
precisely which location in RAM the parameters x and y are located, or where a and b lie in
flash, is set in the compiler/linker run. This is where objects are allocated to unique addresses.
The relationship between object name, data type and address is documented in the linker
map file. The linkermap file is generated by the Linker run and can exist in different formats.
Common to all formats, however, is that they contain the object name and address at a
minimum.
In the example, if the offset b and factor a depend on the specific vehicle, the values of a and
b must be individually adapted to the specific conditions of the vehicle. This means that the
algorithm remains as it is, but the parameter values change from vehicle to vehicle.
In the normal operating mode of an ECU, the application runs from the flash memory. It
does not permit any write accesses to individual objects. This means that parameter values
which are located in the flash area cannot be modified at runtime. If a change to parameter
values should be possible during runtime, the parameters to be modified must lie in RAM
and not in flash. Now, how do the parameters and their initial values make their way into
RAM? How does one solve the problem of needing to modify more parameters than can be
simultaneously stored in RAM? These issues lead us to the topic of calibration concepts (see
chapter 3).
18
1 Fundamentals of the XCP Protocol
Summary of XCP fundamentalsRead and write accesses to memory contents are available with the mechanisms of the XCP
protocol. The accesses are made in an addressoriented way. Read access enables measure
ment of parameters from RAM, and write access enables calibration of the parameters in
RAM. XCP permits execution of the measurement synchronous to events in the ECU. This
ensures that the measured values correlate with one another. With every restart of a
measurement, the signals to be measured can be freely selected. For write access, the
parameters to be calibrated must be stored in RAM. This requires a calibration concept
This leads to two important questions:
> How does the user of the XCP protocol know the correct addresses of the measurement
and calibration parameters in RAM?
> What does the calibration concept look like?
The first question is answered in chapter 2 “ECUs description file A2L”. The topic of the cali
bration concept is addressed in chapter 3.
1.1 XCP Protocol Layer
19
1.1 XCP Protocol LayerXCP data is exchanged between the Master and Slave in a messagebased way. The entire
“XCP message frame” is embedded in a frame of the transport layer (in the case of XCP on
Ethernet with UDP in a UDP packet). The frame consists of three parts: the XCP header, the
XCP packet and the XCP tail.
In the following figure, part of a message is shown in red. It is used to send the current XCP
frame. The XCP header and XCP tail depend on the transport protocol.
XCP Message (Frame)
XCP Header
XCP PacketXCP Tail
PID FILLDAQTIMESTAMPDATAIdentificationTimestampData Figure 6: FieldFieldFieldXCP packetThe XCP packet itself is independent of the transport protocol used. It always contains three
components: “Identification Field”, “Timestamp Field” and the current data field “Data
Field”. Each Identification Field begins with the Packet Identifier (PID), which identifies the
packet.
The following overview shows which PIDs have been defined:
PID for frames
PID for frames
from Master to Slave
from Slave to Master
0xFF
0xFF
RES
0xFE
ERR
CMD
....
0xFD
EV
0xC0
0xFC
SERV
0xBF
0xFB
absolute or
absolute or
relative
....
relative
ODT number
....
ODT number
for STIM
for DAQ
0x00
0x00
Figure 7: Overview of XCP Packet Identifier (PID)
20
1 Fundamentals of the XCP Protocol
Communication via the XCP packet is subdivided into one area for commands (CTO) and
one area for sending synchronous data (DTO).
XCP MasterXCP Driver
CTODTOCMD
RES
ERR
EV
SERV
DAQ
STIM
Command / Response / Error /
DAQ
STIM
Event / Service Request Processor
Processor
Processor
Bypass
XCP Handler
PGM
CAL
DAQ
STIM
Resources
Figure 8: XCP SlaveXCP communication
model with CTO/DTOThe acronyms used here stand for
CMD
Command Packet
sends commands
RES
Command Response Packet
positive response
ERR
Error
negative response
EV
Event Packet
asynchronous event
SERV
Service Request Packet
service request
DAQ
Data AcQuisition
send periodic measured values
STIM
Stimulation
periodic stimulation of the Slave
Commands are exchanged via CTOs (Command Transfer Objects). The Master initiates con
tact in this way, for example. The Slave must always respond to a CMD with RES or ERR.
The other CTO messages are sent asynchronously. The Data Transfer Objects (DTO) are
used to exchange synchronous measurement and stimulation data.
1.1 XCP Protocol Layer
21
1.1.1 Identification FieldXCP Packet
PID FILLDAQTIMESTAMP
DATA
Identification FieldFigure 9:
Message identificationWhen messages are exchanged, both the Master and Slave must be able to determine which
message was sent by the other. This is accomplished in the identification field. That is why
each message begins with the Packet Identifier (PID).
In transmitting CTOs, the PID field is fully sufficient to identify a CMD, RES or other CTO
packet. In Figure 7, it can be seen that commands from the Master to the Slave utilize a PID
from 0xC0 to 0xFF. The XCP Slave responds or informs the Master with PIDs from 0xFC to
0xFF. This results in a unique allocation of the PIDs to the individually sent CTOs.
When DTOs are transmitted, other elements of the identification field are used (see chap
ter 1.3.4 “XCP Packet Addressing for DAQ and STIM”).
1.1.2 TimestampXCP Packet
PID FILL
DAQ
TIMESTAMPDATA
Figure 10:
TimestampDTO packets use timestamps, but this is not possible in transmission of a CTO message. The
Slave uses the timestamp to supply time information with measured values. That is, the
Master not only has the measured value, but also the time point at which the measured
value was acquired. The amount of time it takes for the measured value to arrive at the
Master is no longer important, because the relationship between the measured value and
the time point comes directly from the Slave.
Transmission of a timestamp from the Slave is optional. This topic is discussed further in
ASAM XCP Part 2 Protocol Layer Specification.
22
1 Fundamentals of the XCP Protocol
1.1.3 Data Field XCP Packet
PID FILL
DAQ
TIMESTAMP
DATAFigure 11: Data FieldData field in the
XCP packetFinally, the XCP packet also contains the data stored in the data field. In the case of CTO
packets, the data field consists of specific parameters for the different commands. DTO
packets contain the measured values from the Slave and when STIM data is sent the values
from the Master.
1.2 Exchange of CTOs CTOs are used to transmit both commands from the Master to the Slave and responses
from the Slave to the Master.
1.2.1 XCP Command StructureThe Slave receives a command from the Master and must react to it with a positive or neg
ative response. The communication structure is always the same here:
Command (CMD):
Position Type Description0
BYTE
Command Packet Code CMD
1..MAX_CTO1
BYTE
Command specific Parameters
A unique number is assigned to each command. In addition, other specific parameters may
be sent with the command. The maximum number of parameters is defined as MAX_CTO1
here. MAX_CTO indicates the maximum length of the CTO packets in bytes.
Positive response:
Position Type Description0
BYTE
Command Positive Response Packet Code = RES 0xFF
1..MAX_CTO1
BYTE
Command specific Parameters
1.2 Exchange of CTOs
23
Negative response:
Position Type Description0
BYTE
Error Packet Code = 0xFE
1
BYTE
Error code
2..MAX_CTO1 BYTE
Command specific Parameters
Specific parameters can be transmitted as supplemental information with negative
responses as well and not just with positive responses. One example is when the connection
is made between Master and Slave. At the start of a communication between Master and
Slave, the Master sends a connect request to the Slave, which in turn must respond posi
tively to produce a continuous pointtopoint connection.
Master à Slave: Connect
Slave à Master: Positive Response
Connect command:
Position Type Description0
BYTE
Command Code = 0xFF
1
BYTE Mode
00 = Normal
01 = user defined
Mode 00 means that the Master wishes XCP communication with the Slave. If the Master
uses 0xFF 0x01 when making the connection, the Master is requesting XCP communication
with the Slave. Simultaneously, it informs the Slave that it should switch to a specific – user
defined – mode.
Positive response of the Slave:
Position Type Description0
BYTE
Packet ID: 0xFF
1
BYTE RESOURCE
2
BYTE COMM_MODE_BASIC
3
BYTE
MAX_CTO, Maximum CTO size [BYTE]
4
WORD
MAX_DTO, Maximum DTO size [BYTE]
6 BYTE
XCP Protocol Layer Version Number (most significant byte only)
7 BYTE
XCP Transport Layer Version Number (most significant byte only)
The positive response of the Slave can assume a somewhat more extensive form. The Slave
already sends communicationspecific information to the Master when making the connec
tion. RESOURCE, for example, is information that the Slave gives on whether it supports
such features as page switching or whether flashing over XCP is possible. With MAX_DTO,
the Slave informs the Master of the maximum packet length it supports for transfer of the
measured values, etc. You will find details on the parameters in ASAM XCP Part 2 Protocol
Layer Specification.
24
1 Fundamentals of the XCP Protocol
XCP permits three different modes for exchanging commands and reactions between
Master and Slave: Standard, Block and Interleaved mode.
Standard ModeBlock ModeInterleaved ModeMaster
Slave
Master
Slave
Master
Slave
Request k
Request k
Request k
Part1
Part2
MIN_ST
Request k+1
Part3
MAX_BS
Response k
Response k
Request k+1
Response k
Request k+1
Response k+1
Response k+1
Part1
Response k+1
Part2
Part3
Time
Time
Time
Figure 12: The three modes of the XCP protocol: Standard, Block and Interleaved modeIn the standard communication model, each request to a Slave is followed by a single
response. Except with XCP on CAN, it is not permitted for multiple Slaves to react to a com
mand from the Master. Therefore, each XCP message can always be traced back to a unique
Slave. This mode is the standard case in communication.
The block transfer mode is optional and saves time in large data transfers (e.g. upload or
download operations). Nonetheless, performance issues must be considered in this mode in
the direction of the Slave. Therefore, minimum times between two commands (MIN_ST)
must be maintained and the total number of commands must be limited to an upper limit
MAX_BS. Optionally, the Master can read out these communication settings from the Slave
with GET_COMM_MODE_INFO. The aforementioned limitations do not need to be observed
in block transfer mode in the direction of the Master, because performance of the PC nearly
always suffices to accept the data from a microcontroller.
The interleaved mode is also provided for performance reasons. But this method is also
optional and – in contrast to block transfer mode – it has no relevance in practice.
1.2 Exchange of CTOs
25
1.2.2 CMD XCP CTO PacketPID
DATA
Data Field
Identification Field
Timestamp Field
empty for CTO
Figure 13: Overview of the CTO packet structureThe Master sends a general request to the Slave over CMD. The PID (Packet Identifier) field
contains the identification number of the command. The additional specific parameters are
transported in the data field. Then the Master waits for a reaction of the Slave in the form
of a RESponse or an ERRor.
XCP is also very scalable in its implementation, so it is not necessary to implement every
command. In the A2L file, the available CMDs are listed in what is known as the XCP
IF_DATA. If there is a discrepancy between the definition in the A2L file and the implemen
tation in the Slave, the Master can determine, based on the Slave’s reaction, that the Slave
does not even support the command. If the Master sends a command that is not imple
mented in the Slave, the Slave must acknowledge with ERR_CMD_UNKNOWN and no fur
ther activities are initiated in the Slave. This lets the Master know quickly that an optional
command has not been implemented in the Slave.
Some other parameters are included in the commands as well. Please take the precise
details from the protocol layer specification in document ASAM XCP Part 2.
The commands are organized in groups: Standard, Calibration, Page, Programming and
DAQ measurement commands. If a group is not needed at all, its commands do not need to
be implemented. If the group is necessary, certain commands must always be available in
the Slave, while others from the group are optional.
The following overview serves as an example. The SET_CAL_PAGE and GET_CAL_PAGE
commands in the page switching group are identified as not optional. This means that in an
XCP Slave that supports page switching at least these two commands must be imple
mented. If page switching support is unnecessary in the Slave, these commands do not need
to be implemented. The same applies to other commands.
26
1 Fundamentals of the XCP Protocol
Standard commands:
Command PID OptionalCONNECT
0xFF No
DISCONNECT
0xFE No
GET_STATUS
0xFD No
SYNCH
0xFC No
GET_COMM_MODE_INFO 0xFB Yes
GET_ID
0xFA Yes
SET_REQUEST
0xF9 Yes
GET_SEED
0xF8 Yes
UNLOCK
0xF7 Yes
SET_MTA
0xF6 Yes
UPLOAD
0xF5 Yes
SHORT_UPLOAD
0xF4 Yes
BUILD_CHECKSUM
0xF3 Yes
TRANSPORT_LAYER_CMD 0xF2 Yes
USER_CMD
0xF1 Yes
Calibration commands:
Command PID OptionalDOWNLOAD
0xF0 No
DOWNLOAD_NEXT
0xEF Yes
DOWNLOAD_MAX
0xEE Yes
SHORT_DOWNLOAD
0xED Yes
MODIFY_BITS
0xEC Yes
Standard commands:
Command PID OptionalSET_CAL_PAGE
0xEB No
GET_CAL_PAGE
0xEA No
GET_PAG_PROCESSOR_INFO 0xE9 Yes
GET_SEGMENT_INFO
0xE8 Yes
GET_PAGE_INFO
0xE7 Yes
SET_SEGMENT_MODE
0xE6 Yes
GET_SEGMENT_MODE
0xE5 Yes
COPY_CAL_PAGE
0xE4 Yes
1.2 Exchange of CTOs
27
Periodic data exchange – basics:
Command PID OptionalSET_DAQ_PTR
0xE2 No
WRITE_DAQ
0xE1 No
SET_DAQ_LIST_MODE
0xE0 No
START_STOP_DAQ_LIST
0xDE No
START_STOP_SYNCH
0xDD No
WRITE_DAQ_MULTIPLE
0xC7 Yes
READ_DAQ
0xDB Yes
GET_DAQ_CLOCK
0xDC Yes
GET_DAQ_PROCESSOR_INFO 0xDA Yes
GET_DAQ_RESOLUTION_INFO 0xD9
Yes
GET_DAQ_LIST_INFO
0xD8 Yes
GET_DAQ_EVENT_INFO
0xD7 Yes
Periodic data exchange – static configuration:
Command PID OptionalCLEAR_DAQ_LIST
0xE3 No
GET_DAQ_LIST_INFO
0xD8 Yes
Periodic data exchange – dynamic configuration:
Command PID OptionalFREE_DAQ
0xD6 Yes
ALLOC_DAQ
0xD5 Yes
ALLOC_ODT
0xD4 Yes
ALLOC_ODT_ENTRY
0xD3 Yes
28
1 Fundamentals of the XCP Protocol
Flash programming:
Command PID OptionalPROGRAM_START
0xD2 No
PROGRAM_CLEAR
0xD1 No
PROGRAM
0xD0 No
PROGRAM_RESET
0xCF No
GET_PGM_PROCESSOR_INFO 0xCE
Yes
GET_SECTOR_INFO
0xCD Yes
PROGRAM_PREPARE
0xCC Yes
PROGRAM_FORMAT
0xCB Yes
PROGRAM_NEXT
0xCA Yes
PROGRAM_MAX
0xC9 Yes
PROGRAM_VERIFY
0xC8 Yes
1.2.3 RES If the Slave is able to successfully comply with a Master’s request, it gives a positive acknowl
edge with RES.
Position Type Description0
BYTE
Packet Identifier = RES 0xFF
1..MAX_CTO1
BYTE
Command response data
You will find more detailed information on the parameters in ASAM XCP Part 2 Protocol
Layer Specification.
1.2.4 ERR If the request from the Master is unusable, it responds with the error message ERR and an
error code.
Position Type Description0
BYTE
Packet Identifier = ERR 0xFE
1
BYTE
Error code
2..MAX_CTO1 BYTE
Optional error information data
You will find a list of possible error codes in ASAM XCP Part 2 Protocol Layer Specification.
1.2 Exchange of CTOs
29
1.2.5 EV If the Slave wishes to inform the Master of an asynchronous event, an EV can be sent to do
this. Its implementation is optional.
Position Type Description0
BYTE
Packet Identifier = EV 0xFD
1
BYTE
Event code
2..MAX_CTO1 BYTE
Optional event information data
You will find more detailed information on the parameters in ASAM XCP Part 2 Protocol
Layer Specification.
Events will be discussed much more in relation to measurements and stimulation. This has
nothing to do with the action of the XCP Slave that initiates sending of an EVENT. Rather it
involves the Slave reporting a disturbance such as the failure of a specific functionality.
1.2.6 SERV The Slave can use this mechanism to request that the Master execute a service.
Position Type Description0
BYTE
Packet Identifier = SERV 0xFC
1
BYTE
Service request code
2..MAX_CTO1 BYTE
Optional service request data
You will find the Service Request Code table in ASAM XCP Part 2 Protocol Layer
Specification.
1.2.7 Calibrating Parameters in the SlaveTo change a parameter in an XCP Slave, the XCP Master must send the parameter’s loca
tion as well as the value itself to the Slave.
XCP always defines addresses with five bytes: four for the actual address and one byte for
the address extension. Based on a CAN transmission, only seven useful bytes are available
for XCP messages. For example, if the calibrator sets a 4byte value and wants to send both
pieces of information in one CAN message, there is insufficient space to do this. Since a
total of nine bytes are needed to transmit the address and the new value, the change can
not be transmitted in one CAN message (seven useful bytes). The calibration request is
therefore made with two messages from Master to Slave. The Slave must acknowledge
both messages and in sum four messages are exchanged.
30
1 Fundamentals of the XCP Protocol
The following figure shows the communication between Master and Slave, which is neces
sary to set a parameter value. The actual message is located in the line with the envelope
symbol. The interpretation of the message is shown by “expanding” it with the mouse.
Figure 14: Trace example from a calibration process in CANapeIn the first message of the Master (highlighted in blue in Figure 14), the Master sends the
command SET_MTA to the Slave with the address to which a new value should be written.
In the second message, the Slave gives a positive acknowledge to the command with
Ok:SET_MTA.
The third message DOWNLOAD transmits the hex value as well as the valid number of
bytes. In this example, the valid number of bytes is four, because it is a float value. The Slave
gives another positive acknowledge in the fourth message.
This completes the current calibration process. In the Trace display, you can recognize a ter
minating SHORT_UPLOAD – a special aspect of CANape, the measurement and calibration
tool from Vector. To make sure that the calibration was performed successfully, the value is
read out again after the process and the display is updated with the readout value. This lets
the user directly recognize whether the calibration command was implemented. This com
mand also gets a positive acknowledge with Ok:SHORT_UPLOAD.
When the parameter changes in the ECU’s RAM, the application processes the new value. A
reboot of the ECU, however, would lead to erasure of the value and overwriting of the value
in RAM with the original value from the flash (see chapter 3 “Calibration Concepts”). So,
how can the modified parameter set be permanently saved?
1.2 Exchange of CTOs
31
Essentially, there are two possibilities:
A) Save the parameters in the ECU
The changed data in RAM could for example be saved in the ECU’s EEPROM: either auto
matically when ramping down the ECU, or manually by the user. A prerequisite is that the
data can be stored in a nonvolatile memory of the Slave. In an ECU, this would be the
EEPROM or flash. ECUs with thousands of parameters, however, are seldom able to provide
so much unused EEPROM memory space, so this method is rare.
Another possibility is to write the RAM parameters back into the ECU’s flash memory. This
method is relatively complex. A flash memory must first be erased before it can be rewrit
ten. This, in turn, can only be done as a block. Consequently, it is not simply a matter of writ
ing back individual bytes. You will find more on this topic in chapter 3 “Calibration
Concepts”.
B) Save the parameters in the form of a file on the PC
It is much more common to store the parameters on the PC. All parameters – or subsets of
them – are stored in the form of a file. Different formats are available for this; the simplest
case is that of an ASCII text file, which only contains the name of the object and its value.
Other formats also permit saving other information, such as findings about the maturity
level of the parameter of the history of revisions.
Scenario: After finishing his or her work, the calibrator wishes to enjoy a free evening. So, the
calibrator saves the executed changes in the ECU’s RAM in the form of a parameter set file
on a PC. The next day, the calibrator wants to continue working where he or she left off. The
calibrator starts the ECU. Upon booting, the parameters are initialized in RAM. However,
the ECU does this using values stored in flash. This means that the changes of the previous
day are no longer available in the ECU. To now continue where work was left off on the pre
vious day, the calibrator transfers the contents of the parameter set file to the ECU’s RAM
by XCP using the DOWNLOAD command.
Figure 15: Transfer of a parameter set file to an ECU’s RAM
32
1 Fundamentals of the XCP Protocol
Saving parameter set file in hex files and flashingFlashing an ECU is another way to change the parameters in flash. They are then written to
RAM as new parameters when the ECU is booted. A parameter set file can also be trans
ferred to a C or H file and be made into the new flash file with another compiler/linker run.
However, depending on the parameters of the code, the process of generating a flashable
hex file could take a considerable amount of time. In addition, the calibrator might not have
any ECU source code – depending on the work process. That would prevent this method
from being available to the calibrator.
As an alternative, the calibrator can copy the parameter set file into the existing flash file.
Figure 16: Hex windowIn the flash file, there is a hex file that contains both the addresses and the values. Now a
parameter file can be copied to a hex file. To do this, CANape takes the address and the
value from the parameter set file and updates the parameter value at the relevant location
in the hex file. This results in a new hex file, which contains the changed parameter values.
However, this Hex file must now possibly run through further process steps to obtain a flash
able file. One recurring problem here is the checksums, which the ECU checks to determine
whether it received the data correctly. If the flashable file exists, it can be flashed in the ECU
and after the reboot the new parameter values are available in the ECU.
1.3 Exchanging DTOs – Synchronous Data Exchange As depicted in Figure 8, DTOs (Data Transfer Objects) are available for exchanging synchro
nous measurement and calibration data. Data from the Slave are sent to the Master by
DAQ – synchronous to internal events. This communication is subdivided into two phases:
In an initialization phase, the Master communicates to the Slave which data the Slave
should send for different events. After this phase, the Master initiates the measurement in
the Slave and the actual measurement phase begins. From this point in time, the Slave
sends the desired data to the Master, which only listens until it sends a “measurement stop”
to the Slave. Triggering of measurement data acquisition and transmission is controlled by
events in the ECU.
1.3 Exchanging DTOs – Synchronous Data Exchange
33
The Master sends data to the Slave by STIM. This communication also consists of two
phases:
In the initialization phase, the Master communicates to the Slave which data it will send to
the Slave. After this phase, the Master sends the data to the Slave and the STIM processor
saves the data. As soon as a related STIM event is triggered in the Slave, the data is trans
ferred to the application memory.
1.3.1 Measurement Methods: Polling versus DAQ Before explaining how eventsynchronous, correlated data is measured from a Slave, here is
a brief description of another measurement method known as Polling. It is not based on
DTOs, but on CTOs instead. Actually, this topic should be explained in a separate chapter,
but a description of polling lets us derive, in a very elegant way, the necessity of DTObased
measurement, so a minor side discussion at this point makes sense.
The Master can use the SHORT_UPLOAD command to request the value of a measurement
para meter from the Slave. This is referred to as polling. This is the simplest case of a
measure ment: sending the measured value of a measurement parameter at the time at
which the SHORT_UPLOAD command has been received and executed.
In the following example, the measurement parameter “Triangle” is measured from the
Slave:
Figure 17:
Address information
of the parameter
“Triangle” from the
A2L fileThe address 0x60483 is expressed as an address with five bytes in the CAN frame: one byte
for the address extension and four bytes for the actual address.
34
1 Fundamentals of the XCP Protocol
Figure 18: Polling communication in the CANape Trace windowThe XCP specification sets a requirement for polling: that the value of each measurement
parameter must be polled individually. For each value to be measured via polling, two mes
sages must go over the bus: the Master’s request to the Slave and the Slave’s response to
the Master.
Besides this additional bus load, there is another disadvantage of the polling method: When
polling multiple data values, the user normally wants the data to correlate to one another.
However, multiple values that are measured sequentially with polling do not necessarily
stand in correlation to one another, i.e. they might not originate from the same ECU com
puting cycle.
This limits the suitability of polling for measurement, because it produces unnecessarily high
data traffic and the measured values are not evaluated in relation to the process flows in
the ECU.
So, an optimized measurement must solve two tasks:
> Bandwidth optimization during the measurement
> Assurance of data correlation
This task is handled by the already mentioned DAQ method. DAQ stands for Data Acquisi
tion and it is implemented by sending DTOs (Data Transfer Objects) from the Slave to the
Master.
1.3.2 DAQ Measurement Method The DAQ method solves the two problems of polling as follows:
> The correlation of measured values is achieved by coupling the acquisition of measured
values to the events in the ECU. The measured values are not acquired and transferred
until it has been assured that all computations have been completed.
> To reduce bus load, the measurement process is subdivided into two phases: In a configu
ration phase, the Master communicates which values it is interested in to the Slave and
the second phase just involves transferring the measured values of the Slave to the
Master.
1.3 Exchanging DTOs – Synchronous Data Exchange
35
How can the acquisition of measured values now be coupled to processes in the ECU? Figure
19 shows the relationship between calculation cycles in the ECU and the changes in para
meters X and Y.
Calculation
Calculation
Calculation
cycle n
cycle n+1
cycle n+2
time
10
8
6
X 4 2 0
10
8
6
Y 4 2 0
E1
E1
E1
Read sensor X
Calculate Y = X
Figure 19:
Events in the ECULet’s have a look at the sequence in the ECU: When event E1 (= end of computation cycle) is
reached, then all parameters have been acquired and calculations have been made. This
means that all values must match one another and correlate at this time point. This means
that we use an eventsynchronous measurement method. This is precisely what is imple
mented with the help of the DAQ mechanism: When the algorithm in the Slave reaches the
“Computational cycle completed” event, the XCP Slave collects the values of the measure
ment parameters, saves them in a buffer and sends them to the Master. This assumes that
the Slave knows which parameters should be measured for which event.
An event does not absolutely have to be a cyclic, timeequidistant event, rather in the case
of an engine controller, for example, it might be anglesynchronous. This makes the time
interval between two events dependent on the engine rpm. A singular event, such as activa
tion of a switch by the driver, is also an event that is not by any means equidistant in time.
The user selects the signals. Besides the actual measurement object, the user must select
the underlying event for the measurement parameters. The events as well as the possible
assignments of the measurement objects to the events must be stored in the A2L file.
Figure 20:
Event definition
in an A2L
36
1 Fundamentals of the XCP Protocol
In the normal case, it does not make any sense to be able to simultaneously assign a mea
sured value to multiple events. Generally, a parameter is only modified within a single cycle
(e.g. only at 10ms intervals) and not in multiple cycles (e.g. at 10ms and 100ms
intervals).
Figure 21:
Allocation of
“Triangle” to possible events in the A2LFigure 21 shows that the “Triangle” parameter can in principle be measured with the 1 ms,
10 ms and 100 ms events. The default setting is 10 ms.
Measurement parameters are allocated to events in the ECU during measurement configu
ration by the user.
Figure 22:
Selecting events
(measurement mode)
for each measurement
parameterAfter configuring the measured signals, the user starts the measurement. The XCP Master
lists the desired measurement parameters in what are known as DAQ lists. In these lists, the
measured signals are each allocated to selected events. This configuration information is
sent to the Slave before the actual start of measurement. Then the Slave knows which
addresses it should read out and transmit when an event occurs. This distribution of the
measurement into a configuration phase and a measurement phase was already mentioned
at the very beginning of this chapter.
This solves both problems that occur in polling: bandwidth is used optimally, because the
Master no longer needs to poll each value individually during the measurement and the
measured values correlate with one another.
1.3 Exchanging DTOs – Synchronous Data Exchange
37
Figure 23: Excerpt from the CANape Trace window of a DAQ measurementFigure 23 illustrates an example of commandresponse communication (color highlighting)
between Master and Slave (overall it is significantly more extensive and is only shown in part
here for reasons of space). This involves transmitting the DAQ configuration to the Slave.
Afterwards, the measurement start is triggered and the Slave sends the requested values
while the Master just listens.
Until now, the selection of a signal was described based on its name and allocation to a
measurement event. But how exactly is the configuration transferred to the XCP Slave?
Let us look at the problem from the perspective of memory structure in the ECU: The user
has selected signals and wishes to measure them. So that sending a signal value does not
require the use of an entire message, the signals from the Slave are combined into message
packets. The Slave does not create this definition of the combination independently, or else
the Master would not be able to interpret the data when it received the messages. There
fore, the Slave receives an instruction from the Master describing how it should distribute
the values to the messages.
The sequence in which the Slave should assemble the bytes into messages is defined in what
are known as Object Description Tables (ODTs). The address and object length are impor
tant to uniquely identify a measurement object. An ODT provides the allocations of RAM
contents from the Slave to assemble a message on the bus. According to the communica
tion model, this message is transmitted as a DAQ DTO (Data Transfer Object).
38
1 Fundamentals of the XCP Protocol
RAM Cells
ODT
0
address, length
1
address, length
2
address, length
3
address, length
...
PID 0
1
2
3 ...
Figure 24:
ODT: Allocation of RAM
addresses to DAQ DTOStated more precisely, an entry in an ODT list references a memory area in RAM by the
address and length of the object.
After receiving the measurement start command, at some point an event occurs that is
associated with a measurement. The XCP Slave begins to acquire the data. It combines the
individual objects into packets and sends them on the bus. The Master reads the bus mes
sage and can interpret the individual data, because it has defined the allocation of individ
ual objects to packets itself and therefore it knows their relationships.
However, each packet has a maximum number of useful bytes, which depends on the trans
port medium that is used. In the case of CAN, this amounts to seven bytes. If more data
needs to be measured, an ODT is no longer sufficient. If two or more ODTs need to be used
to transmit the measured values, then the Slave must be able to copy the data into the cor
rect ODT and the Master must be able to uniquely identify the received ODTs. If multiple
measurement intervals of the ECU are used, the relationship between ODT and measure
ment interval must also be uniquely identifiable.
1.3 Exchanging DTOs – Synchronous Data Exchange
39
The ODTs are combined into DAQ lists in the XCP protocol. Each DAQ list contains a num
ber of ODTs and is assigned to an event.
ODT #2 0 address, length
1 address, length
ODT #1 0 address, length
2 address, length
1 address, length
ODT #0 0 address, length
3 address, length
2 address, length
1 address, length ...
PID=2 0
1
2
3
...
3 address, length
2 address, length
...
PID=1 0
1
2
3
...
3 address, length
...
PID=0 0
1
2
3
...
Figure 25:
DAQ list with three ODTsFor example, if the user uses two measurement intervals (= two different events in the
ECU), then two DAQ lists are used as well. One DAQ list is needed per event used. Each DAQ
list contains the entries related to the ODTs and each ODT contains references to the values
in the RAM cells.
It is also possible for the Slave to transfer time information. A DAQ list represents the val
ues belonging to a specific time event. Before these values in the Slave are recorded, the
point in time of the event is noted and transferred within the first ODT. The timestamp is
implemented using a counter. The time interval at which the counter is incremented is spec
ified in the A2L.
DAQ lists are subdivided into the types: static, predefined and dynamic.
40
1 Fundamentals of the XCP Protocol
Static DAQ lists:
If the DAQ lists and ODT tables are permanently defined in the ECU, as is familiar from CCP,
they are referred to as static DAQ lists. There is no definition of which measurement para
meters exist in the ODT lists, rather only the framework that can be filled (in contrast to
this, see predefined DAQ lists).
In static DAQ lists, the definitions are set in the ECU code and are described in the A2L.
Figure 26 shows an excerpt of an A2L, in which static DAQ lists are defined:
Figure 26:
Static DAQ listsIn the above example, there is a DAQ list with the number 0, which is allocated to a 10ms
event and can carry a maximum of two ODTs. The DAQ list with the number 1 has four ODTs
and is linked to the 100 ms event.
The A2L matches the contents of the ECU. In the case of static DAQ lists, the number of
DAQ lists and the ODT lists they each contain are defined with the download of the applica
tion into the ECU. If the user now attempts to measure more signals with an event than fit
in the allocated DAQ list, the Slave in the ECU will not be able to fulfill the requirements and
the configuration attempt is terminated with an error. It does not matter that the other
DAQ list is still fully available and therefore actually still has transmission capacity.
Predefined DAQ lists:
Entirely predefined DAQ lists can also be set up in the ECU. However, this method is practi
cally never used in ECUs due to the lack of flexibility for the user. It is different for analog
measurement systems which transmit their data by XCP: Flexibility is unnecessary here,
since the physical structure of the measurement system remains the same over its life.
1.3 Exchanging DTOs – Synchronous Data Exchange
41
Dynamic DAQ lists:
A special aspect of the XCP protocol are the dynamic DAQ lists. It is not the absolute param
eters of the DAQ and ODT lists that are permanently defined in the ECU code here, but just
the parameters of the memory area that can be used for the DAQ lists. The advantage is
that the measurement tool has more latitude in putting together the DAQ lists and it can
manage the structure of the DAQ lists dynamically.
Various functions especially designed for this dynamic management are available in XCP
such as ALLOC_ODT which the Master can use to define the structure of a DAQ list in the
Slave.
MIN_DAQ + DAQ_COUNT
DAQ1
DAQ0
ALLOC_DAQ
ALLOC_ODT_ENTRY
ODT_ENTERIES_COUNT
T
OC_OD
ALL
GRANULARITY_ODT_ENTRY_SIZE_DAQ
Figure 27: ODT_COUNT
Dynamic DAQ listsIn putting together the DAQ lists, the Master must be able to distinguish whether dynamic
or static DAQ lists are being used, how the parameters and structures of the DAQ lists look,
etc.
42
1 Fundamentals of the XCP Protocol
1.3.3 STIM Calibration MethodThe XCP calibration method was already introduced in the chapter about exchanging CTOs.
This type of calibration exists in every XCP driver and forms the basis for calibrating objects
in the ECU. However, no synchronization exists between sending a calibration command and
an event in the ECU.
In contrast to this, the use of STIM is not based on exchanging CTOs, rather on the use of
DTOs with communication that is synchronized to an event in the Slave. The Master must
therefore know to which events in the Slave it can even synchronize at all. This information
must also exist in the A2L.
Figure 28: Event for DAQ and STIMIf the Master sends data to the Slave by STIM, the XCP Slave must be informed of the loca
tion in the packets at which the calibration parameters can be found. The same mechanisms
are used here as are used for the DAQ lists.
1.3 Exchanging DTOs – Synchronous Data Exchange
43
1.3.4 XCP Packet Addressing for DAQ and STIM Addressing of the XCP packets was already discussed at the beginning of this chapter. Now
that the concepts of DAQ, ODT and STIM have been introduced, XCP packet addressing will
be presented in greater detail.
During transmission of CTOs, the use of a PID is fully sufficient to uniquely identify a packet;
however, this is no longer sufficient for transmitting measured values. The following figure
offers an overview of the possible addressing that could occur with the DTOs:
XCP DTO PacketIdentification Field
Timestamp Field
Data Field
PID
PID DAQ
TS
PID
DAQ
TS
Figure 29: PID FILL
DAQ
TIMESTAMP
DATA
Structure of the
XCP packet for DTO transmissionsTransmission type: “absolute ODT numbers”Absolute means that the ODT numbers are unique throughout the entire communication –
i.e. across all DAQ lists. In turn, this means that the use of absolute ODT numbers assumes
a transformation step that utilizes a socalled “FIRST_PID for the DAQ list.
If a DAQ list starts with the PID j, then the PID of the first packet has the value j, the second
packet has the PID value j + 1, the third packet has the PID value j + 2, etc. Naturally, the
Slave must ensure here that the sum of FIRST_PID + relative ODT number remains below
the PID of the next DAQ list.
DAQlist: 0
≤ PID ≤ k
DAQlist: k + 1 ≤ PID ≤ m
DAQlist: m + 1 ≤ PID ≤ n
etc.
44
1 Fundamentals of the XCP Protocol
In this case, the identification field is very simple:
Identification Field
PID
Figure 30: absolute ODT number
Identification field with absolute
ODT numbersTransmission type: “relative ODT numbers and absolute DAQ lists numbers”In this case, both the DAQ lists number and the ODT number can be transmitted in the Iden
tification Field. However, there is still space left over in the number of bytes that is available
for the information:
Identification Field
PID DAQ
absolute DAQ list number
Figure 31: relative ODT number
ID field with relative ODT and absolute
DAQ numbers (one byte)In the figure, one byte is available for the DAQ number and one byte for the ODT number.
The maximum number of DAQ lists can be transmitted using two bytes:
Identification Field
PID
DAQ
absolute DAQ list number
Figure 32: relative ODT number
ID field with relative ODT and absolute
DAQ numbers (two bytes)
1.3 Exchanging DTOs – Synchronous Data Exchange
45
If it is not possible to send three bytes, it is also possible to work with four bytes by using a
fill byte:
Identification Field
PID FILL
DAQ
absolute DAQ list number
for alignement
Figure 33: ID field with relative ODT and relative ODT number
absolute DAQ numbers as well as fill byte (total of four bytes)How does the XCP Master now learn which method the Slave is using? First, by the entry in
the A2L and second by the request to the Slave to determine which communication version
it has implemented.
The response to the GET_DAQ_PROCESSOR_INFO request also sets the DAQ_KEY_BYTE
that the Slave uses to inform the Master which transmission type is being used. If not only
DAQ is being used, but also STIM, the Master must use the same method for STIM that the
Slave uses for DAQ.
1.3.5 Bypassing = DAQ + STIM Bypassing can be implemented by joint use of DAQ and STIM (see Figure 8) and it repre
sents a special form of a rapid prototyping solution. For a deeper understanding, however,
further details are necessary, so this method is not explained until chapter 4.5 “Bypassing”.
1.3.6. Time Correlation and SynchronizationVarious mechanisms are available to the Master for correlating the timestamp of the mea
surement data of a Slave to the timestamps of other measurement data. In the simplest
form of a Slave implementation, the Slave features a clock and can access its value at any
time. The DAQ timestamps sent by the XCP Slave are based on this clock. Here, the Slave
transfers the time information in the first ODT of each DAQ event. The Slave retrieves the
timestamp at the point in time at which the event was initiated and at which it copies the
measurement data from RAM.
The correlation of this clock to other clocks is unknown to the Master, as the DAQ messages
require an undefined amount of time to reach the Master from the Slave. The clocks can be
correlated using the GET_DAQ_CLOCK command. Before the start of measurement, and
usually at regular intervals, the Master sends the GET_DAQ_CLOCK command and the
46
1 Fundamentals of the XCP Protocol
Slave responds with the current value of the Slave clock. Since the Master knows the point
in time at which it sent the command, it can calculate a time offset between the Master
clock and the Slave clock using the timestamp of the Slave and the point in time the com
mand was sent.
Naturally, this method is also afflicted with inaccuracies if the run time of the GET_DAQ_CLOCK
command is not precisely defined or the point in time at which the clocks are read in the
Master and Slave cannot be determined precisely when sending/receiving the command.
This is why version 1.3 of the XCP specification provides improved methods enabling correla
tion of the Master and Slave clocks with a precision of just a few microseconds.
1.3.6.1 MulticastFor better correlation of the clocks of multiple Slaves to one another, the Master reads the
clocks of multiple Slaves at the same time. For this purpose, the Master sends a command
to all Slaves which are accessible using the same transport medium. Each Slave records the
point in time at which it receives the command and transfers the value to the Master. To
achieve maximum precision, two requirements must be fulfilled to the greatest degree
possible:
On the one hand, the Slave implementation should ensure (as in the past) that the record
ing of the timestamp is initiated as soon as possible upon receipt of the command. On the
other hand, the latency times between the Slaves and the Master should be the same to the
greatest degree possible.
The GET_DAQ_CLOCK_MULTICAST command is available for this purpose. The Slave
responds with an EV_TIME_SYNC message, in which the timestamp is transferred.
XCP SlaveXCP MasterXCP Slave Clock
free running
GET_DAQ_CLOCK_MULTICAST
EV_TIME_SYNC
GET_DAQ_CLOCK_MULTICAST
EV_TIME_SYNC
Figure 34: t
XCP Slave with
free-running clock
1.3 Exchanging DTOs – Synchronous Data Exchange
47
1.3.6.2. Grandmaster ClockA further solution involves the time of the Slave already being synchronized/coordinated
with another clock, the socalled grandmaster clock.
First, an explanation of the terms “synchronized” and “coordinated”:
Stated simply, two clocks are synchronized with one another if they supply the identical
timestamp when they are read at the same time.
In contrast, clocks which are coordinated to one another do not necessarily need to sup
ply the same timestamp. In both clocks, 1 second is exactly the same length.
IEEE 1588 with PTP (Precision Time Protocol) is used. In the first step, the XCP Master must
know whether the Slave is linked to an external clock. As there can be more than one grand
master clock in an overall system, information on the exact clock to which the Slave is linked
must be available to the XCP Master.
XCP SlaveXCP MasterXCP Slave Clock
synchronized to a
Grandmaster ClockGrandmaster Clock
e.g.
IEEE 1588
GET_DAQ_CLOCK_MULTICAST
EV_TIME_SYNC
GET_DAQ_CLOCK_MULTICAST
EV_TIME_SYNC
t
Figure 35: The clock of the XCP Slave is synchronized with the grandmaster clock
48
1 Fundamentals of the XCP Protocol
The XCP standard supports additional scenarios which can only briefly be sketched out here
briefly. Further details can be found in the XCP specifications.
> Should it be possible to coordinate the XCP Slave clock with the external clock, but
not synchronize them, there will be an offset between the grandmaster clock and
the Slave clock. The XCP Master can request the details from the Slave using the TIME_
CORRELATION_PROPERTIES command.
> The freerunning clock of the Slave cannot be synchronized with a grandmaster clock, but
there is another clock in the Slave, e.g. a clock synchronized with the grandmaster clock in
the Ethernet PHY of the Slave. If the Master receives both times at the same point in time,
it can correlate the DAQ timestamp of the freerunning clock with the grandmaster clock
and its own time domain.
> Another scenario arises when there is a freerunning clock of the XCP Slave and an ECU
clock and the DAQ timestamps originate from the ECU clock. This is the case when an
external XCP Slave, such as the VX1000 measurement and calibration hardware is used
from Vector, is used.
> If all of the sketched solutions are combined, a total of three different clocks are involved:
the freerunning Slave clock, a clock which is synchronized with a grandmaster clock and
the ECU clock.
> In the last scenario, there is no Slave clock, but there is an ECU clock which is synchronized
with a grandmaster clock.
Synchronization between the DAQ timestamps and the Master domain time can be realized
for all scenarios in the Master using the XCP mechanisms.
1.4 XCP Transport Layers
49
1.4 XCP Transport Layers A main requirement in designing the XCP protocol was that it must support different trans
port layers. At the time this document was defined, the following layers had been defined:
XCP on CAN, FlexRay, Ethernet, SxI and USB. The bus systems CAN, LIN and FlexRay are
explained on the Vector ELearning platform, as well as an introduction to AUTOSAR. For
details see the website www.vectorelearning.com.
1.4.1 CAN XCP was developed as a successor protocol of the CAN Calibration Protocols (CCP) and
must absolutely satisfy the requirements of the CAN bus. The communication over the CAN
bus is defined by the associated description file. Usually the DBC format is used, but in some
isolated cases the AUTOSAR format ARXML is being used too.
A CAN message is identified by a unique CAN identifier. The communication matrix is defined
in the description file: Who sends which message and how are the eight useful bytes of the
CAN bus being used? The following figure illustrates the process:
DataCAN CANCANCANFrameNode ANode BNode CNode DID=0x12
Sender
Receiver
ID=0x34
Sender
Receiver
Receiver
ID=0x52
Receiver
Sender
ID=0x67
Receiver
Receiver
Sender
Receiver
ID=0xB4
Receiver
Sender
Figure 36:
Definition of which ID=0x3A5
Sender
Receiver
Receiver
Receiver
bus nodes send which
messagesThe message with ID 0x12 is sent by CAN node A and all other nodes on the bus receive this
message. In the framework of acceptance testing, CAN nodes C and D conclude that they
do not need the message and they reject it. CAN node B, on the other hand, determines that
its higherlevel layers need the message and they provide them via the Rx buffer. The CAN
nodes are interlinked as follows:
50
1 Fundamentals of the XCP Protocol
CAN Node ACAN Node BHost
Host
CAN Interface
CAN Interface
Tx
Rx
Tx
Rx
Buffer
Buffer
Buffer
Buffer
Acceptance
Acceptance
Test
Test
Send
Receive
Send
Receive
CANReceive
Send
Receive
Send
Acceptance
Acceptance
Test
Test
Rx
Tx
Rx
Tx
Buffer
Buffer
Buffer
Buffer
CAN Interface
CAN Interface
Host
Host
Figure 37: CAN Node CCAN Node DRepresentation of a
CAN networkThe XCP messages are not described in the communication matrix! If measured values are
sent from the Slave via dynamic DAQ lists, e.g. with the help of XCP, the messages are
assembled according to the signals selected by the user. If the signal selection changes, the
message contents change as well. Nonetheless, there is a relationship between the commu
nication matrix and XCP: CAN identifiers are needed to transmit the XCP messages over
CAN. To minimize the number of CAN identifiers used, the XCP communication is limited to
the use of just two CAN identifiers that are not being used in the DBC for “normal” commu
nication. One identifier is needed to send information from the Master to the Slave; the
other is used by the Slave for the response to the Master.
The excerpt from the CANape Trace window shows the CAN identifiers that are used under
the “ID” column. In this example, just two different identifiers are used: 554 as the ID for the
message from Master to Slave (direction Tx) and 555 for sending messages from the Slave
to the Master (direction Rx).
1.4 XCP Transport Layers
51
Figure 38: Example of XCP-on-CAN communicationIn this example, the entire XCP communication is handled by the two CAN identifiers 554
and 555. These two IDs may not be allocated for other purposes in this network.
The CAN bus transmits a maximum of eight useful bytes per message. In the case of XCP,
however, we need information on the command used or the sent response. This is provided
in the first byte of the CAN useful data. This means that seven bytes are available per CAN
message for transporting useful data.
XCP on CAN Message (Frame)XCP Packet
XCP Tail
XCP Header
empty for CAN PID FILL DAQ TIMESTAMP
DATA
FILL
Control Field
Control Field
empty for CAN
for CAN
Figure 39: Representation of an XCP-on-CAN messageIn CANape, you will find an XCPonCAN demo with the virtual ECU XCPsim. You can learn
about more details of the standard in ASAM XCP on CAN Part 3 Transport Layer
Specification.
52
1 Fundamentals of the XCP Protocol
1.4.2 CAN FDCAN FD (CAN with flexible data rate) is an extension of the CAN protocol developed by
Robert Bosch GmbH. Its primary difference to CAN involves extending the useful data from
8 to 64 bytes. CAN FD also offers the option of sending the useful data at a higher data
rate. After the arbitration phase, the data bytes are sent at a higher transmission rate than
during the arbitration phase. This covers the need for greater bandwidth in automotive net
works while preserving valuable experience gained from CAN development.
The XCPonCANFD specification was defined in the XCPonCAN description of the XCP
standard, Version 1.2 (June 2013).
F
r1
K
O
r0
S
IDE
EDL
BRS
ESI
DLC
Data
CRC
elim.
AC
elim.
EOF
IFS
tifier
D
Iden
CK
CRC D
A
1
11
1
1
1
1
1
1
4
0…512
17/21
1
1
1
7
3
Arbitration phaseData phaseArbitration phase(standard bit rate)
(optional high bit rate)
(standard bit rate)
EDL = Extended Data Length:
ESI = Error State Indicator:
CAN (dominant (0) = CAN frame
Dominant (0) = CAN FD node is error active
Recessive (1) = CAN FD frame
Recessive (1) = CAN FD node is error passive
BRS = Bit Rate Switch:
CAN FD data phase starts immediately at sampling point of BRS:
Dominant (0) = No change of bit rate for data phase
Recessive (1) = Change to higher bit rate for data phase
Figure 40: Illustration of a CAN FD frameDespite the largely similar modes of operation, this protocol requires extensions and modifi
cations to the hardware and software. Among other things, CAN FD introduces three new
bits to the control field:
> Extended Data Length (EDL)
> Bit Rate Switch (BRS)
> Error State Indicator (ESI)
1.4 XCP Transport Layers
53
A recessive EDL bit (high level) distinguishes frames in extended CANFD format from those
in standard CAN format, because they are identified by a dominant EDL bit (low level). Sim
ilarly, a recessive BRS bit causes the transmission of the data field to be switched to the
higher bit rate. The ESI bit identifies the error state of a CAN FD node. Another four bits
make up what is known as the Data Length Code (DLC), which represents the extended
useful data length as a possible value of 12, 16, 20, 24, 32, 48 and 64 bytes.
The use of XCP on CAN FD assumes that a second transmission rate has been defined for
the useful data in the A2L file. This is fully transparent to the user, who gets a complete A2L
parameterization. A measurement configuration in the XCP Master considers the maximum
packet length, and the user does not need to make any other settings.
CAN FD is supported in CANape, Version 12.0 and higher. Every CAN hardware product from
Vector which begins with “VN” supports the CAN FD transport protocol.
54
1 Fundamentals of the XCP Protocol
1.4.3 FlexRayA basic idea in the development of FlexRay was to implement a redundant system with
deterministic time behavior. The connection redundancy was achieved by using two chan
nels: channel A and channel B. If multiple FlexRay nodes (= ECUs) are redundantly intercon
nected and one branch fails, the nodes can switch over to the other channel to make use of
the connection redundancy.
Node K
Node L
Node M
Node N
Node O
CH A
CH B
Figure 41: Nodes K and L are redundantly interconnectedDeterministic behavior is achieved by transmitting data within defined time slots. Also
defined here is which node sends which content in which time slot. These time slots are com
bined to form one cycle. The cycles repeat here, as long as the bus is active. The assembly of
the time slots and their transport contents (who sends what at which time) is known as
scheduling.
Node K
Node L
Node M
Slot
Direction Frame
Slot
Direction Frame
Slot
Direction Frame
1
Tx
a
1
Tx
a
1
Tx
a
3
Rx
x
3
Rx
b
3
Rx
x
Frame: a
Frame: b
Frame: x
Frame: a
Frame: b
Frame: x
Slot 1
Slot 2
Slot 3
Slot 1
Slot 2
...
Real-time
t1
t2
t3
t4
t5
t6
Communication Cycle
Next Communication Cycle
Figure 42: Communication by slot definition
1.4 XCP Transport Layers
55
In the first communication cycle, node K sends frame a in slot 1. The scheduling is also stored
in the software of nodes L and M. Therefore, the contents of frame a are passed to the next
higher communication levels.
Scheduling is consolidated in a description file. This is not a DBC file, as in the case of CAN,
rather it is a FIBEX file. FIBEX stands for “Field Bus Exchange Format” and could also be
used for other bus systems. However, its current use is practically restricted to the descrip
tion of the FlexRay bus. FIBEX is an XML format and the XCPonFlexRay specification
relates to FIBEX Version 1.1.5 and FlexRay specification Version 2.1.
CyclesSlotECUChannel0123456...63A
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
1
Node K
entB
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
b [rep: 1]
egmA
c [rep: 4]
x [rep: 2]
y [rep: 4]
x [rep: 2]
c [rep: 4]
x [rep: 2]
y [rep: 4]
x [rep: 2]
2
Node M
B
tatic SA
a [rep: 1]
a [rep: 1]
a [rep: 1]
a [rep: 1]
a [rep: 1]
a [rep: 1]
a [rep: 1]
a [rep: 1]
S 3
Node L
B
d [rep: 1]
d [rep: 1]
d [rep: 1]
d [rep: 1]
d [rep: 1]
d [rep: 1]
d [rep: 1]
d [rep: 1]
Node L
A
n [rep: 1]
n [rep: 1]
n [rep: 1]
n [rep: 1]
n [rep: 1]
n [rep: 1]
n [rep: 1]
n [rep: 1]
4
Node O
B
m [rep: 1]
m [rep: 1]
m [rep: 1]
m [rep: 1]
m [rep: 1]
m [rep: 1]
m [rep: 1]
m [rep: 1]
Node N
A
r [rep: 1]
r [rep: 1]
r [rep: 1]
r [rep: 1]
r [rep: 1]
r [rep: 1]
r [rep: 1]
r [rep: 1]
ent 5
B
egmA
6
ic SNode K
B
o [rep: 1]
o [rep: 1]
o [rep: 1]
o [rep: 1]
o [rep: 1]
o [rep: 1]
o [rep: 1]
o [rep: 1]
Node M
A
t [rep: 2]
p [rep: 4]
t [rep: 2]
t [rep: 2]
p [rep: 4]
t [rep: 2]
ynam
DB
Node L
A
u [rep: 4]
u [rep: 4]
7
Node L
B
v [rep: 8]
A
Node O
B
w [rep: 4]
w [rep: 4]
Figure 43: Representation of a FlexRay communication matrixAnother format for describing bus communication has been defined as a result of the devel
opment of AUTOSAR solutions: the AUTOSAR Description File, which is available in XML for
mat. The definition of XCPonFlexRay was taken into account in the AUTOSAR 4.0 specifi
cation. However, at the time of publication of this book this specification has not yet been
officially approved and therefore it will not be discussed further.
Due to other properties of the FlexRay bus, it is not sufficient to just give the slot number as
a reference to the contents. One reason is that multiplexing is supported: whenever a cycle
is repeated, the transmitted contents are not necessarily the same. Multiplexing might spec
ify that a certain piece of information is only sent in the slot in every second pass.
56
1 Fundamentals of the XCP Protocol
Instead of indicating the pure slot number, “FlexRay Data Link Layer Protocol Data Unit
Identifiers” (FLX_LPDU_ID) are used, which can be understood as a type of generalized Slot
ID. Four pieces of information are needed to describe such an LPDU:
> FlexRay Slot Identifier (FLX_SLOT_ID)
> Cycle Counter Offset (OFFSET)
> Cycle Counter Repetition (CYCLE_REPETITION)
> FlexRay Channel (FLX_CHANNEL)
LPDU_ID...
Channel A
... ...
Channel B
ycle ID
C . . . . . . . . . .
. . . ...
.
. . . . .
. .. .. .. .. .. .. .. .. ..
.. .. .. .. ..
.. . . . . . . . . . . . . . . . . .
. .. .. .. .. .. .. .. .. ..
.
...
. .. .. .. ..
... ...
... ...
...
Figure 44: Slot ID
Representation of the
FlexRay LPDUsScheduling also has effects on the use of XCP on FlexRay, because it defines what is sent
precisely. This cannot be readily defined in XCP; not until the measurement runtime does the
user define which measured values are sent by assembling signals. This means that it is only
possible to choose which aspect of XCP communication can be used in which LPDU: CTO or
DTO from Master to Slave or from Slave to Master.
The following example illustrates this process: the XCP Master may send a command (CMD)
in slot n and Slave A gives the response (RES) in slot n + 2. XCPonFlexRay messages are
always defined using LPDUs.
The A2L description file is needed for access to internal ECU parameters; the objects with
their addresses in the ECU are defined in this file. In addition, the FIBEX file is necessary, so
that the XCP Master knows which LPDUs it may send and to which LPDUs the XCP Slaves
send their responses. Communication between XCP Master and XCP Slave(s) can only func
tion through combination of the two files, i.e. by having an A2L file reference a FIBEX file.
1.4 XCP Transport Layers
57
Excerpt of an A2L with XCPonFlexRay parameter setting:
…
/begin XCP_ON_FLX
…
„XCPsim.xml“
„Cluster_1“
…
In this example, “XCPsim.xml” is the reference from the A2L file to the FIBEX file.
XCP-dedicated LPDU_IDs...
Channel A
... ...
Channel B
ycle ID
C . . . . . . . . . .
. . . ...
.
. . . . .
. .. .. .. .. .. .. .. .. ..
.. .. .. .. ..
.. . . . . . . . . . . . . . . . . .
. .. .. .. .. .. .. .. .. ..
.
...
. .. .. .. ..
... ...
... ...
Figure 45: ...
Allocation of XCP Slot ID
communication to LPDUsYou can read more details about XCP on FlexRay in CANape’s Online Help. Supplied with
CANape is the FIBEX Viewer, which lets users conveniently view the scheduling. It is easy to
allocate the XCP messages to the LPDUs by making driver settings for the XCPonFlexRay
device in CANape.
The protocol is explained in detail in ASAM XCP on FlexRay Part 3 Transport Layer Specifi
cation. You will find an XCPonFlexRay demo in CANape with the virtual ECU XCPsim. The
demo requires real Vector FlexRay hardware.
1.4.4 EthernetXCP on Ethernet can be used with either TCP/IP or UDP/IP. TCP is a protected transport
protocol on Ethernet, in which the handshake method is used to detect any loss of a packet.
In case of packet loss, TCP organizes a repetition of the packet. UDP does not offer this pro
tection mechanism. If a packet is lost, UDP does not offer any mechanisms for repeated
sending of the lost packet on the protocol level.
Not only can XCP on Ethernet be used with real ECUs, it can also be used for measurement
and calibration of virtual ECUs. Here, a virtual ECU is understood as the use of code that
would other wise run in the ECU as an executable program (e.g. DLL) on the PC. Entirely dif
ferent resources are available here compared to an ECU (CPU, memory, etc.).
58
1 Fundamentals of the XCP Protocol
But first the actual protocol will be discussed. IP packets always contain the addresses of
the sender and receiver. The simplest way to visualize an IP packet is as a type of letter that
contains the addresses of the recipient and the sender. The addresses of individual nodes
must always be unique. A unique address comprises the IP address and port number.
XCP on Ethernet (TCP/IP and UDP/IP) Message (Frame)XCP Header
XCP Packet
XCP Tail
empty for Ethernet
(TCP/IP and UDP/IP)
LEN
CTR
PID FILL DAQ
TIMESTAMP
DATA
Control Field
Length (LEN)
Control Field
for Ethernet
empty for Ethernet
(TCP/ IP and UDP/IP)
(TCP&IP and UDP&IP)
Figure 46: XCP packet with TCP/IP or UDP/IPThe header consists of a Control Field with two words in Intel format (= four bytes). These
words contain the length (LEN) and a counter (CTR). LEN indicates the number of bytes in
the XCP packet. The CTR is used to detect the packet loss. UDP/IP is not a protected proto
col. If a packet is lost, this is not recognized by the protocol layer. Packet loss is monitored by
counter information. When the Master sends its first message to the Slave, it generates a
counter number that is incremented with each additional transmission of a frame. The Slave
responds with the same pattern: It increments its own counter with each frame that it
sends. The counters of the Slave and the Master operate independently of one another.
UDP/IP is well suited for sending measured values. If a packet is lost, then the measured
values it contains are lost, resulting in a measurement gap. If this occurs infrequently, the
loss might just be ignored. But if the measured data is to be used as the basis for fast con
trol, it might be advisable to use TCP/IP.
An Ethernet packet can transport multiple XCP packets, but an XCP packet may never
exceed the limits of a UDP/IP packet. In the case of XCP on Ethernet, there is no “Tail”, i.e.
an empty control field.
1.4 XCP Transport Layers
59
Detection of XCP-on-Ethernet SlavesWith version 1.3 of the XCP standard, an expansion for XCP Slave detection was defined
specifically for XCP on Ethernet.
The Master can detect the XCP Slaves using the GET_SLAVE_ID command. Here, the Master
broadcasts a multicast message (IPv4) with the IP address 239.255.0.0 on port 5556.
Regardless of whether or not an XCP Slave already has a connection to a Master, the Slave
must process the request and return a response.
The response of the Slave contains, among other things:
> The IP address (IPv4)
> The port number
> TCP, UDP or both
> Information on the status of whether or not there is already a connection to an XCP
Master
You will find more detailed information on the protocol in ASAM XCP on Ethernet Part 3
Transport Layer Specification. In CANape, you will also find an XCP on Ethernet demo with
the virtual ECU XCPsim or with virtual ECUs in the form of DLLs, which have been imple
mented by Simulink models and the Simulink Coder.
1.4.5 SxI SxI is a collective term for SPI or SCI. Since they are not buses, but instead are controller
interfaces which are only suited for pointtopoint connections, there is no addressing in this
type of transmission. The communication between any two nodes runs either synchronously
or asynchronously.
XCP on Sxl Message (Frame)XCP Header
XCP Packet
XCP Tail
LEN
CTR
PID FILL DAQ
TIMESTAMP
DATA
FILL
CS
Control Field
Length (LEN)
Control Field
for SxI
for SxI
Checksum (CS)
Figure 47: XCP-on-SxI packetThe XCP header consists of a control field with two pieces of information: the length LEN
and the counter. The length of these parameters may be in bytes or words (Intel format).
LEN indicates the number of bytes of the XCP packet. The CTR is used to detect the loss of
a packet. This is monitored in the same way as for XCP on Ethernet: with counter informa
60
1 Fundamentals of the XCP Protocol
tion. Under certain circumstances it may be necessary to add fill bytes to the packet, e.g. if
SPI is used in WORD or DWORD mode or to avoid the message being shorter than the
minimal packet length. These fill bytes are appended in the control field.
You will find more detailed information on the protocol in ASAM XCP on SxI Part 3 Transport
Layer Specification.
1.4.6 USB Currently, XCP on USB has no practical significance. Therefore, no further mention will be
made of this topic; rather we refer you to ASAM documents that describe the standard:
ASAM XCP on USB Part 3 Transport Layer Specification.
1.4.7 LIN At this time, ASAM has not yet defined an XCPonLIN standard. However, a solution exists
from Vector (XCPonLIN driver and CANape as XCPonLIN Master), which violates neither
the LIN nor the XCP specification and is already being used on some customer projects. For
more detailed information, please contact Vector.
1.5 XCP Services
61
1.5 XCP ServicesThis chapter contains a listing and explanation of other services that can be realized over
XCP. They are all based on the already described mechanisms of communication with the
help of CTOs and DTOs. Some XCP services have already been explained, e.g. synchronous
data acquisition/stimulation and read/write access to device memory.
The XCP specification does indeed uniquely define the different services; at the same time it
indicates whether the service always needs to be implemented or whether it is optional. For
example, an XCP Slave must support “Connect” for the Master to set up a connection. On
the other hand, flashing over XCP is not absolutely necessary and the XCP Slave does not
need to support it. This simply depends on the requirements of the project and the software.
All of the services described in this chapter are optional.
1.5.1 Memory Page Switching As already explained in the description of calibration concepts, parameters are normally
located in flash memory and are copied to RAM as necessary. Some calibration concepts
offer the option of switching memory segment pages from RAM and Flash. XCP describes a
somewhat more general, generic approach, in which a memory segment may contain multi
ple switchable pages. Normally, this consists of a RAM page and a flash page. But multiple
RAM pages or the lack of a flash page are conceivable as well.
For a better understanding of the XCP commands for page switching, the concepts of sec
tor, segment and page will be explained once again at this point.
XCP access
Segment 1
t 1
Segment 1
Segment 1
2
Page 0
Page 1
Page 2
egmem
S
tor
ec
S
ECU access
Segment 0
t 0
Page 0
1
egmem
S
tor
ec
S
0
tor
ec
address
S
Figure 48:
Memory representation
62
1 Fundamentals of the XCP Protocol
From an XCP perspective, the memory of a Slave consists of a continuous memory that is
addressed with a 40bit width. The physical layout of the memory is based on sectors.
Know ledge of the flash sectors is absolutely necessary in flashing, because the flash mem
ory can only be erased a block at a time.
The logical structure is based on what are known as segments; they describe where calibra
tion data is located in memory. The start address and parameters of a segment do not have
to be aligned with the start addresses and parameters of the physical sectors. Each seg
ment can be subdivided into multiple pages. The pages of a segment describe the same
parameters at the same addresses. The values of these parameters and read/write rights
can be controlled individually for each page.
The allocation of an algorithm to a page within a segment must always be unique. Only one
page may be active in a segment at any given time. This page is known as the “active page
for the ECU in this segment.” The particular page that the ECU and the XCP driver actively
access can be individually switched. No interdependency exists between these settings. Sim
ilar to the naming convention for the ECU, the active page for XCP access is referred to as
the “active page for XCP access in this segment“.
In turn, this applies to each individual segment. Segments must be listed in the A2L file and
each segment gets a number that is used to reference the segment. Within an XCP Slave,
the SEGMENT_NUMBER must always begin at 0 and it is then incremented in consecutive
numbers. Each segment has at least one page. The pages are also referenced by numbers.
The first page is PAGE 0. One byte is available for the number, so that a maximum of 255
pages can be defined per segment.
The Slave must initialize all pages for all segments. The Master uses the command
GET_CAL_PAGE to ask the Slave which page is currently active for the ECU and which page
for XCP access. It can certainly be the case that mutual blocking may be necessary for the
accesses. For example, the XCP Slave may not access a page, if this page is currently active
for the ECU. As mentioned, there may be a dependency – but not necessarily. It is a question
of how the Slave has been implemented.
If the Slave supports the optional commands GET_CAL_PAGE and SET_CAL_PAGE, then it
also supports what is known as page switching. These two commands let the Master poll
which pages are currently being used and if necessary it can switch pages for the ECU and
XCP access. The XCP Master has full control over switching of pages. The XCP Slave cannot
initiate switching by itself. But naturally the Master must respect any restrictions of the
Slave implementation.
What is the benefit of switching?
First, switching permits very quick changing of entire parameter sets – essentially a before
andafter comparison. Second, the plant remains in a stable state, while the calibrator per
forms extensive parameter changes on another page in the ECU. This prevents the plant
from going into a critical or unstable state, e.g. due to incomplete datasets during para
meter setting.
1.5 XCP Services
63
1.5.2 Saving Memory Pages – Data Page Freezing When a calibrator calibrates parameters on a page, there is the conceptual ability in XCP to
save the data directly in the ECU. This involves saving the data of a RAM page to a page in
nonvolatile memory. If the nonvolatile memory is flash, it must be taken into account that
the segment start address and the segment size might not necessarily agree with the flash
sectors, which represents a problem in erasing and rewriting the flash memory (see ASAM
XCP Part 2 Protocol Layer Specification).
1.5.3 Flash Programming Flashing means writing data in an area of flash memory. This requires precise knowledge of
how the memory is laid out. A flash memory is subdivided into multiple sectors (physical sec
tions), which are described by a start address and a length. To distinguish them from one
another, they each get a consecutive identification number. One byte is available for this
number, resulting in a maximum of 255 sectors.
SECTOR_NUMBER [0, 1, 2 … 255]
The information about the flash sectors is also part of the A2L data set.
Figure 49:
Representation
of driver settings
for the flash area
64
1 Fundamentals of the XCP Protocol
Flashing can be implemented using what are referred to as “flash kernels”. A flash kernel is
executable code that is sent to the Slave’s RAM area before the actual flashing; the kernel
then handles communication with the XCP Master. It might contain the algorithm that is
responsible for erasing the flash memory. For security and space reasons, very frequently
this code is not permanently stored in the ECU’s flash memory. Under some circumstances,
a converter might be used, e.g. if checksum or similar computations need to be performed.
Flashing with XCP roughly subdivides the overall flash process into three areas:
> Preparation (e.g. for version control and therefore to check whether the new contents can
even be flashed)
> Execution (the new contents are sent to the ECU)
> Postprocessing (e.g. checksum checking etc.)
In the XCP standard, the primary focus is directed to the actual execution of flashing. Any
one who compares this operation to flashing over diagnostic protocols will discover that the
processspecific elements, such as serial number handling with metadata, are supported in
a rather spartan fashion in XCP. Flashing in the development phase was clearly the main
focus in its definition and not the complex process steps that are necessary in endofline
flashing.
Therefore, what is important in the preparation phase is to determine whether the new con
tents are even relevant to the ECU. There are no special commands for version control.
Rather the practice has been to support those commands specific to the project.
The following XCP commands are available:
PROGRAM_START: Beginning of the flash procedure
This command indicates the beginning of the flash process. If the ECU is in a state that does
not permit flashing (e.g. vehicle speed > 0), the XCP Slave must acknowledge with an ERRor.
The actual flash process may not begin until the PROGRAM_START has been successfully
acknowledged by the Slave.
PROGRAM_CLEAR: Call the current flash memory erasing routine
Before flash memory can be overwritten with new contents, it must first be cleared. The call
of the erasing routine via this command must be implemented in the ECU or be made avail
able to the ECU with the help of the flash kernel.
PROGRAM_FORMAT: Select the data format for the flash data
The XCP Master uses this command to define the format (e.g. compressed or encrypted) in
which the data are transmitted to the Slave. If the command is not sent, the default setting
is noncompressed and nonencrypted transmission.
PROGRAM: Transfer the data to the XCP Slave
For the users who are very familiar with flashing via diagnostics: this command corresponds
to TRANSFERDATA in diagnostics. Using this command, data is transmitted to the XCP
Slave, which is then stored in flash memory.
1.5 XCP Services
65
PROGRAM_VERIFY: Request to check the new flash contents
The Master can request that the Slave perform an internal check to determine whether the
new contents are OK.
PROGRAM_RESET: Reset request to the Slave
Request by the Master to the Slave to execute a Reset. Afterwards, the connection to the
Slave is always terminated and a new CONNECT must be sent.
1.5.4 Automatic Detection of the Slave The XCP protocol lets the Master poll the Slave about its protocolspecific properties. A
number of commands are available for this.
GET_COMM_MODE_INFO
The response to this command gives the Master information about the various communica
tion options of the Slave, e.g. whether it supports block transfer or interleaved mode or
which minimum time intervals the Master must maintain between requests in these modes.
GET_STATUS
The response to this request returns all current status information of the Slave. Which
resources (calibration, flashing, measurement, etc.) are supported? Are any types of mem
ory activities (DAQ list configuration, etc.) still running currently? Are DTOs (DAQ, STIM)
being exchanged right now?
GET_DAQ_PROCESSOR_INFO
The Master gets general information, which it needs to know about the Slave limitations:
number of predefined DAQ lists, available DAQ lists and events, etc.
GET_DAQ_RESOLUTION_INFO
Other information about the DAQ capabilities of the Slave is exchanged via this command:
maximum number of parameters for an ODT for DAQ and for STIM, granularity of the ODT
entries, number of bytes in timestamp transmission, etc.
GET_DAQ_EVENT_INFO
When this command is used, the call is made once per ECU event. Information is transmit
ted here on whether the event can be used for DAQ, STIM or DAQ/STIM, whether the event
occurs periodically and if so which cycle time it has, etc.
66
1 Fundamentals of the XCP Protocol
1.5.5 Block Transfer Mode for Upload, Download and Flashing In the “normal” communication mode, each command from the Master is acknowledged by
a response of the Slave. However, in some cases it may be desirable, for performance rea
sons, to use what is referred to as the block transfer mode.
Master
Slave
Request k
Part1
Part2
MIN_ST
Part3
MAX_BS
Response k
Request k+1
Time
Figure 50:
Representation of the block transfer modeThe use of such a method accelerates the procedure when transmitting large amounts of
data (UPLOAD, SHORT_UPLOAD, DOWNLOAD, SHORT_DOWNLOAD and PROGRAM). The
Master can find out whether the Slave supports this method with the request GET_COMM_
MODE_INFO. You will find more on this in ASAM XCP Part 2 Protocol Layer Specification.
1.5 XCP Services
67
1.5.6 Cold Start Measurement (during Power-On) Even with the capabilities of XCP described to this point, it would be impossible to imple
ment an eventdriven measurement that can in practice be executed early in the ECU’s start
phase. The reason is that the measurement must be configured before the actual measure
ment takes place. If one attempts to do this, the ECU’s start phase has long been over by
the time the first measured values are transmitted. The approach that is used to overcome
this problem is based on a simple idea.
It involves separating the configuration and the measurement in time. After the configura
tion phase, the measurement is not started immediately; rather the ECU is shut down. After
a reboot, the XCP Slave accesses the existing configuration directly and immediately begins
to send the first messages. The difficulties associated with this are obvious: the configura
tion of the DAQ lists is stored in RAM, and therefore the information no longer exists after
a reboot.
To enable what is known as the RESUME mode to enable a Cold Start Measurement, a non
volatile memory is needed in the XCP Slave which preserves its data even when it is not
being supplied with power. EEPROMs are used in this method. In this context, it is irrelevant
whether it is a real EEPROM or one that is emulated by a flash memory.
You will find more details in ASAM XCP Part 1 Overview Specification in the chapter 1.4.2.2
“Advanced Features”.
68
1 Fundamentals of the XCP Protocol
1.5.7 Security Mechanisms with XCP An unauthorized user should be prevented as much as possible from being able to make a
connection to an ECU. The “seed & key” method is available for checking whether or not a
connection attempt is authorized. The three different access types can be protected by seed
& key: measurement / stimulation, calibration and flashing.
The “seed & key” method operates as follows: in the connect request by the Master, the
Slave sends a random number (= seed) to the Master. Now, the Master must use an algo
rithm to generate a response (= key). The key is sent to the Slave. The Slave also computes
the expected response and compares the key of the Master with its own result. If the two
results agree, both the Master and Slave have used the same algorithm. Then the Slave
accepts the connection to the Master. If there is no agreement, the Slave declines commu
nication with the Master.
Normally, the algorithm is available as a DLL in the Master. So, if a user has the “seed & key”
DLL and the A2L file, nothing stands in the way of accessing the ECU’s memory. When the
ECU is approaching a production launch, the XCP driver is often deactivated. A unique
sequence of individual diagnostic commands is usually used to restore XCP access to the
ECU. This makes the XCP driver largely available even in production vehicles, but it is nor
mally deactivated to protect against unauthorized manipulation of the ECU (see ASAM XCP
Part 2 Protocol Layer Specification).
Whether or not seed & key or deactivation of the XCP driver is used in a project is implemen
tationspecific and independent of the XCP specification.
2 ECU Description File A2L
71
2 ECU Description File A2L
72
2 ECU Description File A2L
One reason why an A2L file is needed has already been named: to allocate symbolic names
to addresses. For example, if a software developer has implemented a PID controller and
assigned the names P1, I1 and D1 in his application for the proportional, integral and differ
ential components, then the calibrator should be able to access these parameters with their
symbolic names. Let us take the following figure as an example:
Figure 51:
Parameters in a calibration windowThe user can conveniently modify values using symbolic names. Another example is provided
by viewing signal variables that are measured from the ECU:
Figure 52: Signal response over timeIn the legend, the user can read the logical names of the signals. The addresses at which the
parameters were located in the ECU are of secondary importance in the offline analysis of
values. Naturally, the correct address is needed to request the values in the ECU, but the
numeric value of the address itself is of no importance to the user. The user uses the logical
name for selection and visualization purposes. That is, the user selects the object by its
name and the XCP Master looks for the associated address and data type in the A2L.
2 ECU Description File A2L
73
Another attribute of a parameter might be the definition of a minimum or maximum value.
The value of the object would then have to lie within these limits. Imagine that you as the
software developer define a parameter that has a direct effect on a power output stage.
You must now prevent the user – whatever the user’s reasons might be – from configuring
the output stage that would result in catastrophic damage. You can accomplish this by
defining minimum and maximum values in the A2L to limit the permitted values.
Rules for conversion between physical and raw values are also defined in the A2L. You can
visualize a simple example of such a conversion rule in a sensor that has an 8bit value. The
numeric values output by the sensor lie between 0 and 255, but you wish to see the value as
a percentage value. Mapping of the sensor value [0 … 255] to [0 … 100 %] is performed with
a conversion rule, which in turn is stored in the A2L. If an object is measured, which exists as
a raw value in the ECU and is also transmitted as such, the measurement and calibration
tool uses the stored formula and visualizes the physical value.
Besides scalar parameters, characteristic curves and maps are frequently used. Some might
utilize a proximity sensor such as a Hall sensor, which determines distance as a function of
magnetic field strength and you may wish to use this distance value in your algorithm. The
magnetic field and distance value do not run linear to one another. This nonlinearity of
values would make formulation of the algorithm unnecessarily difficult. With the help of a
characteristic curve, you can first linearize the values before you input the values into your
algorithm as input variables.
Another application area for characteristic maps is their use as substitutes for complex
computations. For example, if there is a relationship y = f(x) and the function f is associated
with a lot of computing effort, it is often simpler to simply compute the values over the
potential range of x in advance and store the results in the form of a table (= characteristic
curve). If the value x is now in the ECU, the value y does not need to be computed at the con
troller’s runtime, rather the map returns the result y to the input variable x. It may be neces
sary to interpolate between two values, but that would be the extent of the calculations.
How is this characteristic curve stored in memory? Are all x values input first and then all y
values? Or does storage follow the pattern: x1, y1; x2, y2; x3, y3 …? Since various options are
available, the type of memory storage is defined in a storage scheme in the A2L.
The convenience for the user comes from the ability to work with symbolic names for param
eters, the direct look at the physical values and access to complex elements such as charac
teristic maps, without having to concern oneself with complex storage schemes.
Another advantage is offered by the communication parameters. They are also defined in
the A2L. In the communication between the measurement and calibration tool and the ECU,
the parameter set from the A2L is used. The A2L contains everything that the measurement
and calibration tool needs to communicate with the ECU.
74
2 ECU Description File A2L
2.1 Setting Up an A2L File for an XCP Slave The A2L file is an ASCIIreadable file, which describes the following with the help of
keywords:
> Interfacespecific parameters between measurement and calibration tool and A2L file
(the description is located at the beginning of the A2L file and is located in what is referred
to as the AML tree),
> Communication to the ECU,
> Storage scheme for characteristic curves and maps (keyword RECORD_LAYOUT),
> Conversion rules for converting raw values to physical values (keyword COMPU_METHOD),
> Measurement parameters (keyword MEASUREMENT),
> Calibration parameters (keyword CHARACTERISTIC) and
> Events that are relevant for triggering a measurement keyword EVENT),
A summary of parameters and measurement parameters is made with the help of groups
(keyword GROUP).
Example of a measurement parameter with the name “Shifter_B3”:
/begin MEASUREMENT Shifter_B3 „Single bit signal (bit from a byte shifting)“
UBYTE HighLow 0 0 0 1
READ_WRITE
BIT_MASK 0x8
BYTE_ORDER MSB_LAST
ECU_ADDRESS 0x124C02
ECU_ADDRESS_EXTENSION 0x0
FORMAT „%.3“
/begin IF_DATA CANAPE_EXT
100
LINK_MAP „byteShift“ 0x124C02 0x0 0 0x0 1 0x87 0x0
DISPLAY 0 0 20
/end IF_DATA
/end MEASUREMENT
Example of a parameter map with the name KF1:
/begin CHARACTERISTIC KF1 „8*8 BYTE no axis“
MAP 0xE0338 __UBYTE_Z 0 Factor100 0 2.55
ECU_ADDRESS_EXTENSION 0x0
EXTENDED_LIMITS 0 2.55
BYTE_ORDER MSB_LAST
BIT_MASK 0xFF
/begin AXIS_DESCR
FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7
EXTENDED_LIMITS 0 7
2.1 Setting Up an A2L File for an XCP Slave
75
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT „%.0“
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
/begin AXIS_DESCR
FIX_AXIS NO_INPUT_QUANTITY BitSlice.CONVERSION 8 0 7
EXTENDED_LIMITS 0 7
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT „%.0“
FIX_AXIS_PAR_DIST 0 1 8
/end AXIS_DESCR
/begin IF_DATA CANAPE_EXT
100
LINK_MAP „map3_8_8_uc“ 0xE0338 0x0 0 0x0 1 0x87 0x0
DISPLAY 0 0 255
/end IF_DATA
FORMAT „%.3“
/end CHARACTERISTIC
The ASCII text is not easy to understand. You will find a description of its structure in ASAM
XCP Part 2 Protocol Layer Specification in chapter 2.
The sections below describe how to create an A2L. Let us focus on the actual contents of an
A2L and their meanings and leave the details of the A2L description language to an editor.
The A2L Editor that is supplied with CANape is used here.
2.2 Manually Creating an A2L FileThe A2L mainly describes the contents of the memory of the XCP Slave. The contents depend
on the application in the Slave, which was developed as C code. After the compiler/linker run
of the application code, important elements of an A2L file already exist in the linkermap file:
the names of the objects, their data types and memory addresses. Still lacking are the
parameters for communication between XCP Master and Slave. Other information is usually
needed such as minimum and maximum values of parameters, conversion rules, storage
schemes for characteristic maps etc.
Let us begin by creating an empty A2L and the communication parameters: If you wish to
create an A2L that describes an ECU with an XCPonCAN interface, for example, you cre
ate a new device in CANape and select XCP on CAN as the interface. Then you can supple
ment this with other communicationspecific information (e.g. CAN identifiers). After saving
the file, you have an A2L that contains the entire communication content of the A2L. Still
lacking are the definitions of the actual measurement and calibration parameters.
76
2 ECU Description File A2L
In the A2L Editor, the linkermap file is associated to the A2L. In a selection dialog, the user
can now select those parameters from the map file which it needs in the A2L: scalar
measurement and calibration parameters, characteristic curves and maps. The user can
gradually add the desired parameters to the A2L step by step and group them. Other object
specific information is also added using the editor.
What should be done when you modify your code, recompile it and link it? It is highly proba
ble that the addresses of objects will change. Essentially, it is not necessary to generate a
new A2L. If you wish to have objects just added to the code also be available in the A2L, you
must of course add them to the A2L. Address updating is always necessary in the A2L. This
is done with the editor; it searches for the relevant entry in the linkermap file based on the
name of the A2L object, reads out the address and updates it in the A2L.
If your application changes very dynamically – objects are renamed, data types are adapted,
parameters are deleted and others added – then the manual work method is impractical. To
generate an A2L from a C code, other tools are available for automatic processing.
On the Vector homepage you will find information on the “ASAP2 ToolSet“ with which you
can automate the generation of A2Ls from the source code in a batch process.
2.3 A2L Contents versus ECU ImplementationWhen an XCP Master tool reads in an A2L that does not fully match the ECU, misunder
standings in the communication might occur. For example, another value related to time
stamp resolution might be in the A2L file that differs from the value implemented in the
ECU. If this is the case, the problem must be detected and solved. The user gets support
from the Master, who can poll the Slave via the protocol to determine what was really imple
mented in the Slave.
XCP offers a number of functions that were developed for automatic detection of the Slave.
Of course, this assumes that automatic detection is implemented in the Slave. If the Master
polls the Slave and the Slave’s responses do not agree with the parameter set of the A2L
description file, the Master must decide which settings to use. In CANape, the information
that is read out by the Slave is given a higher priority than the information from the A2L.
2.3 A2L Contents versus ECU Implementation
77
Here is an overview of possible commands that are used to find out something about the
XCP implementation in the Slave:
GET_DAQ_PROCESSOR_INFO
Returns general information on the DAQ lists: MAX_DAQ, MAX_EVENT_CHANNEL,
MIN_DAQ
GET_DAQ_RESOLUTION_INFO
Maximum parameter of an ODT entry for DAQ/STIM, time interval information
GET_DAQ_EVENT_INFO (Event_channel_number)
Returns information for a specific time interval: Name and resolution of the time interval,
number of DAQ lists that may be assigned to this time interval …
GET_DAQ_LIST_INFO (DAQ_List_Number)
Returns information on the selected DAQ list: MAX_ODT, MAX_ODT_ENTRIES exist as pre
defined DAQ lists …
3 Calibration Concepts
79
3 Calibration Concepts
80
3 Calibration Concepts
ECU parameters are constant parameters that are adapted and optimized during the
development of the ECU or an ECU variant. This is an iterative process, in which the optimal
value of a parameter is found by repeated measurements and changes.
The calibration concept answers the question of how parameters in the ECU can be changed
during an ECU’s development and calibration phases. There is not one calibration concept
that exists, rather several. Which concept is utilized usually depends very much on the capa
bilities and resources of the microcontroller that is used.
Normally, parameters are stored in the production ECU’s flash memory. The underlying pro
gram variables are defined as constants in the software. To make parameters modifiable at
runtime during an ECU’s development, additional RAM memory is needed.
A calibration concept is concerned with such questions as these: How do the parameters ini
tially find their way from flash to RAM? How is the microcontroller’s access to RAM rerouted?
What does the solution look like when there are more parameters than can be simultane
ously stored in RAM? How are the parameters copied back into flash? Are changes to the
parameters persistent, i.e. are they preserved when the ECU is turned off?
A distinction is made between transparent and nontransparent calibration concepts. Trans
parent means that the calibration tool does not need to be concerned with the above
questions, because all necessary mechanisms are implemented in the ECU.
Several methods are briefly introduced in the following.
3.1 Parameters in FlashThe software developer defines in the source code whether a parameter is a variable or a
constant, i.e. whether a parameter is stored in flash or in RAM memory.
C code example:
const float factor = 0.5;
The “factor” parameter represents a constant with the value 0.5. During compiling and link
ing of the code, memory space is provided in flash for the “factor” object. The object is allo
cated an address that lies in the data area of the flash memory. The value 0.5 is found at
the relevant address in the hex file and the address appears in the linkermap file.
The simplest conceivable calibration concept involves modifying the value in C code, gener
ating a new hex file and flashing. However, this method is very laborious, because every
value change must be made in code, resulting in the need for a compiler/linker run with sub
sequent flashing. An alternative approach would be to only modify the value in the hex file
and then reflash this file. Every calibration tool is capable of doing this. It is referred to as
“offline calibration” of the hex file, which is a very commonly used method.
3.1 Parameters in Flash
81
Under some circumstances, with certain compilers it may be necessary to explicitly ensure
that parameters are always also stored in flash memory and not integrated in the code, for
example and therefore do not appear at all in the linkermap file. Usually, one does not want
to leave to chance where a constant is created in flash memory. The necessary means for
accomplishing this are almost always compilerspecific pragma instructions. To prevent the
compiler from embedding them in the code, it is generally sufficient to use the “volatile”
attribute for constant parameters. A typical definition of a flash constant appears as in the
following example:
C code example:
#pragma section “FLASH_Parameter”
volatile const float factor = 0.5;
It is normally not possible to calibrate parameters in flash online. Indeed, most microcon
trollers are able to program their flash themselves, which is necessary for the purposes of
reprogramming in the field. Nonetheless, flash memory always has the property of being
organized into larger blocks (sectors), which can only be erased as a whole. It is practically
impossible to flash just individual parameters, because the ECU normally does not have the
resources to buffer the rest of the sector and reprogram it. In addition, this process would
take too much time.
Some ECUs have the ability to store data in what is known as an EEPROM memory. In con
trast to flash memories, EEPROM memories can erase and program each memory cell indi
vidually. The amount of available EEPROM memory is always considerably less than the
available flash memory and it is usually limited to just a few kilobytes. EEPROM memory is
often used to store programmable parameters in the service shop or to implement a persis
tence mechanism in the ECU, e.g. for the odometer. Online calibration would be conceivable
here, but it is seldom used, because access to EEPROM cells is relatively slow and during the
booting process EEPROM parameters are usually copied over to RAM memory, where it is
possible to access them directly. ECUs which have no EEPROM memory often implement
what is known as an EEPROM emulation. In this method, multiple small flash sectors are
used in alternation to record parameter changes, so that the last valid value can always be
determined. Online calibration would also be conceivable with this method.
In both cases, the relevant memory accesses would then be intercepted in the software
components of the XCP driver and implemented with the software routines of the EEPROM
or the EEPROM emulation. The Vector XCP Professional driver offers the software hooks
needed for this.
82
3 Calibration Concepts
3.2 Parameters in RAMThe most frequently used approach to modifying parameters at runtime (“online calibra
tion”) is to create the parameters in the available RAM memory.
C code example:
#pragma section “RAM_Parameter”
volatile float factor = 0.5;
This defines the parameter “factor” as a RAM variable with the initial value 0.5. During com
piling and linking of the code, memory space is reserved for the object “factor” in RAM and
the associated RAM address appears in the linkermap file. The initial value 0.5 is stored in
flash memory and at the relevant location in the hex file. The addresses of the initial values
in flash memory are defined by parameterization of the linker, but they do not appear in the
linkermap file.
During booting of the ECU, all RAM variables are initialized once with their initial values
from flash memory. This is usually executed in the startup code of the compiler producer
and the application programmer does not need to be concerned with it. The application uses
the values of parameters located in RAM and they can be modified via normal XCP memory
accesses.
From the perspective of the ECU software, calibration parameters in RAM are always still
unchangeable, i.e. the application itself does not change them. Many compilers discover this
fact by code analysis and simply optimize the necessary RAM memory space away. Nor
mally, it is therefore also necessary to prevent the compiler from optimizing by using the
“volatile” attribute.
From the perspective of the calibration tool, the RAM area in which the parameters are
located is referred to as calibration RAM (memory that can be calibrated).
FLASH
RAM
Calibration RAM
Parameters
Figure 53:
Initial parameter setting in RAMThe calibration RAM does not need to consist of a fully contiguous RAM area. It may also be
distributed into multiple areas or even in any desired way. Nonetheless, it offers significant
advantages for organizing the parameters in just a few contiguous RAM areas and isolating
them from other RAM parameters such as changing state variables and intermediate
results. This is especially important if offline calibration of the calibration RAM with a hex
file should be enabled. At the user’s request, the calibration tool must be able to load the
3.2 Parameters in RAM
83
parameters that were modified offline into the ECU during the transition from offline cali
bration to online calibration.
This case occurs very frequently. For example, when calibrators reconnect with their ECU on
the next work day, they want to resume work at the point at which they stopped the evening
before. However, booting of the ECU causes the flashed contents to be copied to the RAM
as an initial dataset. To let users resume with work accomplished on the previous day, the
parameter set file saved the previous evening in the ECU’s RAM must be loaded. This load
ing process may be time optimized by limiting the number of necessary transmissions to a
minimum. It is advantageous here if the tool can quickly and reliably determine – by forming
a checksum over larger contiguous areas – whether there are differences. If there are no dif
ferences between the calibration RAM contents in the ECU and the file modified using the
tool, this area does not need to be transferred. If the memory area with the calibration
parameters is not clearly defined, or if it includes parameters that are modified by the ECU
software, a checksum calculation always shows a difference and the parameter values are
transmitted, either from the ECU to the XCP Master or in a reverse direction. Depending on
the transmission speed and amount of data, this transmission could take several minutes.
Another advantage of clearly defined memory segments is that the memory area for initial
values in flash memory can be used for offline calibration. The contents of the flash memory
are defined using flashable hex files. If the calibration tool knows the location of parameters
in the hex file, it can modify their values and implement new initial values in the ECU by
flashing the modified hex file.
The calibration tool not only needs to know the location of parameters in RAM, but also the
initial values in flash. A prerequisite is that the RAM memory segment must be initialized by
copying from an identically laid out memory segment in flash, as is the usual practice in
most compilers/linkers. If the addresses of parameters in RAM are in the A2L file, it is only
necessary to let the tool know the offset to the start address of the calibration RAM, which
it must add to get to the start address of the relevant flash area. This offset then applies to
each individual parameter in the A2L.
The calibration tool can then either generate flashable hex files for this area itself, or it can
place them directly on the original hex files of the linker to modify the initial values of para
meters in the hex file.
84
3 Calibration Concepts
3.3 Flash OverlayMany microcontrollers offer options for overlaying memory areas in flash with internal or
external RAM. This process is referred to as flash emulation or flash overlay. A lot is possible,
from the use of a Memory Management Unit all the way to dedicated mechanisms that pre
cisely serve this purpose. In this case the parameters are created as parameters in flash just
as in calibration concept 1. This method offers enormous advantages compared to the
described calibration concept 2 “Parameters in RAM”:
> No distinction is made between flash and RAM addresses. The flash addresses are always
located in the A2L file, the hex file and linkermap file. This produces clear relationships,
the hex file is directly flashable and the A2L file matches it exactly.
> The overlay can be activated or deactivated as a whole, which enables lightningquick
swapping between values in flash and those in RAM. They are referred to as the RAM page
and the flash page of a memory segment. XCP supports control of memory page switch
ing with special commands.
> The memory pages might be switched separately, e.g. for XCP access and ECU access, i.e.
XCP could access a memory page while the ECU software works with the other page. This
permits such operations as downloading of the offline calibration data to RAM, while the
ECU is still working with the flash data; this avoids potential inconsistencies that could be
problematic on a running ECU.
> The overlay with RAM does not need to be complete and it can be adapted to the applica
tion case. It is possible to work with less RAM than with flash. More on this later.
A typical procedure for connecting the calibration tool to the ECU with the subsequent
download of values that were calibrated offline appears as follows:
Connects to the ECU
CONNECT
Connects XCP Master to RAM page
SET_CAL_PAGE XCP to RAM
Checksum calculation
CALC_CHECKSUM
When a difference has been detected in the checksum calculation over the RAM area, first
the user is normally asked how to proceed. Should the contents of ECU RAM be sent to the
Master, or should the contents of a file on the Master page be sent to the ECU’s RAM? If the
user decides to write the offline changes to the ECU, the subsequent process appears as
follows:
ECU should use the dataset of the flash page SET_CAL_PAGE ECU to FLASH
Copy file from Master to the RAM page
DOWNLOAD …
ECU should use the dataset of the RAM page SET_CAL_PAGE ECU to RAM
Afterwards, the memory page is always switched over to RAM, so that parameters can be
modified. But the user can also explicitly indicate which memory page should be active in the
ECU. For example, the behavior of the RAM parameter set can be compared to that of the
flash parameter set, or in an emergency it can be switched back to a proven parameter set
in flash at lightning speed.
3.4 Dynamic Flash Overlay Allocation
85
3.4 Dynamic Flash Overlay AllocationThe concepts for calibration RAM described so far are unproblematic if sufficient RAM is
available for all parameters. But what if the total number of parameters does not fit into
the available RAM area?
Here, it is advisable to overlay flash with RAM dynamically and do not overlay the affected
flash memory with RAM until the actual write access to a parameter. This procedure can
occur with a certain granularity and – depending on the implementation – it may be trans
parent to the calibration tool from the XCP perspective. If the XCP driver detects a write
access to flash in the ECU which would lead to a change, a part of calibration RAM is used
to copy over the relevant part of flash and activate the overlay mechanism for this part. This
involves allocating the RAM, i.e. in a fixed layout and it is identified as utilized. However, the
resources of the calibration RAM are limited. During the calibration process, RAM area that
has already been allocated is no longer released, so the available calibration RAM dwindles
with further requests. If the RAM resources are used up and a new allocation is required, the
user is informed of the exhausted RAM resources. The user is offered the option of flashing
or saving the changes made up to that point. This frees up the allocated RAM area again
and the user can once again calibrate. The variant in which the ECU autonomously flashes
the previously changed parameters is usually ruled out here for the reasons already cited in
calibration concept “Parameter in Flash”.
In some cases, the download of a parameter set created offline might not be executable due
to insufficient RAM resources. The only alternative is to flash it. The user can always cancel
the changes from the tool and this releases the allocated RAM blocks again.
In this concept, page switching between the RAM and flash pages is also possible without
any limitations. The parameters should be organized together in flash according to function,
so that the available RAM blocks can be used as efficiently as possible. The software devel
oper then specifies that the parameters, which belong together thematically, also lie in a
contiguous memory area. After copying to RAM, the parameters needed for tuning the par
ticular function are fully ready for use.
86
3 Calibration Concepts
3.5 RAM Pointer Based Calibration Concept per AUTOSARThis concept does not require necessarily the use of an AUTOSAR operating system; it can
even be used in a different environment – e.g. without an operating system. The concept
exhibits a key similarity to the previous concept. The primary difference is that the substitu
tion of flash for RAM is not implemented by hardware mechanisms, but by software mech
anisms instead. The calibration parameters are always referenced by pointers from the ECU
software. Flash or RAM contents are accessed by changing this pointer. The flash parame
ters to be modified are copied to a defined block with available RAM. This method can be
implemented fully transparently from the XCP perspective, just as in the previous method.
As an alternative, the user of the calibration tool can explicitly select the parameters to be
modified by preselecting the desired parameters. The advantage of this is that resource uti
lization and loading is visible to the user and the user is not surprised by a lack of memory in
the midst of working.
3.5.1 Single Pointer ConceptThe pointer table is located in RAM. When booting the ECU, all pointers indicate the para
meter values in flash. The location and parameters of the calibration RAM are indeed known,
but it does not yet contain any parameter values after booting. Initially, the application
works entirely from flash.
FLASH
Pointertable
RAM
Parameters
Figure 54:
Initial situation after bootingWhen the user selects a parameter from the A2L file for the first time after booting and
wishes to write access it, this triggers a copying operation within the ECU first. The XCP
Slave determines that the address to which the access should be made is located in the
flash area, and it copies the parameter value to the calibration RAM. A change is also made
in the pointer table to ensure that the application no longer gets the parameter value from
flash, but instead from the RAM area:
3.5 RAM Pointer Based Calibration Concept per AUTOSAR
87
FLASH
Pointertable
RAM
Parameters
Figure 55:
Pointer change and copying to RAMThe application continues to get the parameter value via the pointer table. But since the
pointer indicates the RAM address, the value is retrieved from there. As a result, the user can
change the parameter value via XCP and observe the effects of the change in the measure
ment. The disadvantage of this method is that an entry in a pointer table must be available
for each parameter and in turn the method is associated with substantial additional RAM
memory requirements for the pointer table.
The next figure illustrates the problem. Three parameters of a PID controller (P, I and D) are
contained in an ECU’s flash area. The RAM addresses and parameter values in RAM are also
already changed in the pointer table.
ParameterFlashPointertableRAMAddress
Content
Address
Address
Content
P0x0000100A 0x11
0x000A100A
0x000A100A 0x44
I0x000012BC 0x22
0x000A100B
0x000A100B 0x55
D0x00007234 0x33
0x000A100C
0x000A100C 0x66
Figure 56: Pointer table for individual parametersCalibration concepts are very important, because RAM resources are scarce. Large RAM
pointer tables would make a concept selfdefeating.
To avoid having to create a pointer for each individual parameter and having the method be
used as such, the parameters can be combined into structures. This requires just one pointer
per structure. When the user selects a parameter, not only is this parameter copied to RAM,
but so is the entire associated structure. The granularity of the structures is of key impor
tance here. With large structures only a few pointers are necessary. In turn, this means that
with the decision for a specific parameter, a rather large associated structure is copied to
the RAM area and this can cause the limits of calibration RAM space to be reached quickly.
88
3 Calibration Concepts
Example:
The calibration RAM should be 400 bytes in size. Four structures are defined in the software
with the following parameters:
Structure A: 250 bytes
Structure B: 180 bytes
Structure C: 120 bytes
Structure D: 100 bytes
When the user selects a parameter from structure A, the 250 bytes are copied from flash to
the calibration RAM, and the user has XCP access to all parameters located in structure A.
If the calibration task is limited to the parameters of this structure, the calibration RAM is
fully sufficient. However, if the user selects another parameter located in a different struc
ture, e.g. structure C, these 120 bytes must also be copied to the calibration RAM. Since the
calibration RAM can handle 400 bytes, the user can access all parameters of structures A
and C simultaneously.
If another selected parameter is not located in structure C, but rather in structure B, the 180
bytes of structure B would have to be copied to RAM in addition to the 250 bytes of struc
ture A. However, since the space in RAM is inadequate for this, the user indeed has access to
the parameters of structure A, but not to the data of structure B, because the ECU cannot
execute the copy command.
You can learn more about how this approach works in CANape. Start CANape with the
“AUTOSAR Single Pointered Demo” project. You will find more information on its use in
CANape on the “Introduction” page of the project.
You will find a source code example under the “Demos” category at the Vector Download
Center. A code example on how to use the calibration concept is contained in the “XCP Sample
Implementation” under <Installation DIR>\Samples\CAN\CAN MPC55xx\XCPDemo.
3.5.2 Double Pointer ConceptA disadvantage of the single pointer concept is that memory page switching is not easy to
implement. The calibration tool could simply describe the pointer table completely for page
swapping, but this is not feasible in a short period of time without resulting in temporary
inconsistencies and side effects. A tooltransparent implementation would double the mem
ory space requirement for the pointer table, because when switching the memory page into
flash, a copy of the previous pointer table would have to be created with RAM pointers.
For applications with large pointer tables, a transparent implementation or a fully consis
tent switching, there is the option of extending the method to a double pointer concept. To
explain how this is done, we return once again to the initial RAM setting.
3.5 RAM Pointer Based Calibration Concept per AUTOSAR
89
Figure 57 represents the pointer table. It lies in RAM. As already mentioned, this table must
be copied from flash into RAM. As a result, this table lies in flash memory. If another pointer
is now used (a table pointer), which points to either the pointer table in RAM or in flash, one
arrives at a double pointer solution.
FLASH
RAM
Pointertable
FLASH
Pointertable
RAM
Tablepointer
Figure 57:
Double pointer conceptThe parameter values are initially accessed via the table pointer. If the table pointer indi
cates the pointer table in RAM, the application essentially accesses the actual parameters
via the contents of the RAM pointer table. The low access speed and the creation of more
program code are disadvantages of this solution.
3.6 Flash Pointer Based Calibration Concept This method was patented several years ago by the company ZF Friedrichshafen under the
name “InCircuit2” and bears a strong resemblance to the pointerbased concept of AUTOSAR.
Here too, the application in the ECU accesses parameter data using a pointer table. How
ever, this pointer table is not located in RAM, but in flash instead. Changes to the pointer
table can therefore only be made by flash programming. A tooltransparent implementation
is not possible. The advantage lies in the RAM memory that is saved since it no longer con
tains the pointer table.
You can find out how this approach works in CANape. Start CANape with the “InCircuit2”
project. You will find more information on its use in CANape on the “Introduction” page of
the project.
4 Application Areas of XCP
91
4 Application Areas of XCP
92
4 Application Areas of XCP
When ECU calibrators think about the use of XCP, they are usually fixated on use of the pro
tocol in the ECU.
Simulink
Slave
Prototype or
ECU Hardware
Slave
Measurement/
XCPCalibration
Master
Slave
PC
Hardware*
EXE/DLL
Slave
HIL/SIL Systems
Slave
Figure 58:
Application areas and * Debug Interfaces, Memory Emulator ...
application casesIn a survey of development processes, one encounters many different solution approaches
for the development of electronics and software. HIL (Hardware in the Loop), SIL (Software
in the Loop) and Rapid Prototyping are keywords here and they describe different scenarios.
They always have a “plant” and a “controller” in common.
Manipulated Disturbance
Offset
Variable
Variable
Reference Variable
ControllerPlantControlled Variable
(Set Value)
(Actual Value)
Figure 59: Plants and controllersIn the context of automotive development, the controller is represented by the ECU and the
plant is the physical system to be controlled such as the transmission, engine, side mirrors,
etc.
The rough subdivision is made between different development approaches according to
whether the controller or the plant runs in real or simulated mode. Some combinations will
be described in greater detail.
4.1 MIL: Model in the Loop
93
4.1 Model in the Loop (MIL) Simulink
Controller ModelPlant ModelFigure 60:
Model in the Loop
in SimulinkIn this development environment, both the controller and the plant are simulated as a
model. In the example shown, both models run in Simulink as the runtime environment. The
capabilities of the Simulink runtime environment are available to you for analyzing the
behavior.
To realize the convenience of a measurement and calibration tool like CANape in an early
development phase, an XCP Slave can be integrated in the controller model. In an authoring
step, the Slave generates the A2L that matches the model and the user already has the full
range of convenient operating features with visualization of process flows in graphic win
dows, access to characteristic curves and maps and much more.
Simulink
Controller ModelPlant ModelCANapeSimulinkFigure 61: XCP ServerCANape as measurement A2L
and calibration tool
with Simulink modelsNeither a code generation step nor instrumentation of the model is necessary for this. Time
stamps are also included with transmissions over XCP. CANape completely adapts to the
time behavior of the Simulink runtime environment here. Whether the model is running
faster or slower than in real time is of no consequence. For example, if the functional devel
oper uses the Simulink Debugger in the model to step through the model, CANape still takes
the time transmitted via XCP as the reference time.
94
4 Application Areas of XCP
4.2 Software in the Loop (SIL) Simulink
Controller ModelPlant ModelCode Generation
Controller ModelFigure 62: Windows DLLSoftware in the Loop
with Simulink environmentIn this development step, code is generated from the model of the controller, which is then
used in a PCbased runtime environment. Naturally, the controller may also have been devel
oped without any sort of modelbased approach. The plant continues to be simulated. XCP
can be used to measure and calibrate the controller. If the controller originates from a
Simulink model, a code generation step (Simulink Coder with the target “CANape”) is used
to generate the C code for a DLL and the associated A2L. If the Controller development is
conducted based on manually written code, it is embedded in a C++ project that is delivered
with CANape.
After compiling and linking, the DLL is used in the CANape context. With the support of the
XCP connection, the algorithms in the DLL can be measured and calibrated exactly as if the
application were already integrated in an ECU.
Simulink
Controller ModelPlant ModelCode generation
Controller ModelCANapeWindows DLLA2L
Figure 63:
CANape as SIL
development platform
4.3 HIL: Hardware in the Loop
95
4.3 Hardware in the Loop (HIL) Many different kinds of HIL systems are available. They range from very simple, costeffec
tive systems all the way to very large and expensive expansion stages. The following figure
shows the rough concept:
Controller ModelHIL Platform
I/O
Plant ModelECU
Figure 64: HIL solutionThe controller algorithm runs in a microcontroller platform (e.g. the ECU), while the plant
continues to be simulated. Depending on the parameters and the complexity of the plant
and the necessary I/O, requirements of the HIL platform and the associated costs can rise
steeply. Since the ECU runs in real time, the model of the plant must also be computed in
real time.
To now introduce XCP for optimization appears trivial, because another ECU is being added.
The whole system looks like this:
Controller ModelA2L
HIL Platform
I/O
CANapePlant ModelFigure 65:
HIL with CANape ECU
as measurement and
calibration toolFrom CANape, the user has access to the algorithms in the ECU over XCP.
96
4 Application Areas of XCP
The Vector Tool CANoe is also used by many customers as a HIL system. With CANoe, a HIL
system might look like this:
CANoe RT User PCEthernet
CANoe RT Server
CAN
LIN
Plant ModelMOST
A2L
FlexRay
Digital I/O
Analog I/O
XCP
CANapeECU
Figure 66:
CANoe as HIL systemThe ability to access XCP data directly from CANoe for testing purposes results in the fol
lowing variant as well:
CANoe RT User PCA2L
Ethernet
CANoe RT Server
CAN
LIN
Plant ModelXCP
MOST
FlexRay
Digital I/O
Analog I/O
Figure 67:
CANoe as HIL system
with XCP access ECU
to the ECUHere the model of the plant runs on the CANoe realtime server. At the same time, XCP
access to the ECU is also realized from CANoe. This gives a tool simultaneous access to the
plant and the controller.
4.3 HIL: Hardware in the Loop
97
To round out the picture, yet another HIL solution option should be mentioned. The plant
might also run as a DLL in CANape. This gives the user full access to the plant and to the
controller over XCP.
ECU
CANapePlant ModelA2L
Windows DLLXCP
Plant
A2L
XCP
ECU
Figure 68: CANape as HIL solution4.4 Rapid Control Prototyping (RCP) In this development phase, the control algorithm runs on realtime hardware instead of an
ECU. This situation often occurs when the necessary ECU hardware is not yet available.
Several platforms come in question as suitable hardware: from simple evaluation boards all
the way to special automotivelevel hardware solutions, depending on which additional
requirements need to be fulfilled. Here too, integration with XCP helps in setting up an OEM
independent tool chain.
Controller ModelCANapeEVA BoardA2L
XCP
I/O
Plant
Figure 69: Solution for Rapid Control PrototypingThe concepts “Rapid” and “Prototyping” describe the task very well. The aim is to develop a
functional prototype as quickly as possible, to use and test it in the runtime environment.
This just requires simple work steps throughout the entire process.
98
4 Application Areas of XCP
In the literature, the RCP approach is frequently subdivided into two areas: fullpassing and
bypassing.
As depicted in Figure 69, the entire controller runs on separate realtime hardware. This
method is known as fullpassing, because the entire controller runs on the controller hard
ware. It must have the necessary I/O to be able to interface with the plant. Very often, it is
only possible to fulfill technical requirements for the I/O with suitable power electronics.
It is not only the I/O that represents a challenge; often functional elements of the ECU soft
ware (e.g. network management) are needed to enable functionality in a more complex net
work. However, if a complete ECU is used for Rapid Control Prototyping instead of a general
controller platform, the complexity of the flash process, the size of the overall software, etc.
all work against the requirement for “rapid” development.
In summary: the use of an entire ECU as the runtime environment for the controller offers
the advantage that the necessary hardware and software infrastructure for the plant exists.
The disadvantage lies in the high degree of complexity. The concept of bypassing was devel
oped to exploit the advantages of the ECU infrastructure without being burdened by the
disadvantages of high complexity.
4.5 Bypassing When bypassing occurs, data is recorded from the ECU and processed outside the ECU, and
the result is written back to the ECU. As both measurement and writing to the ECU must
occur in sync with the ECU processes, DAQ and STIM mechanisms are used. At least two
DAQ lists are required, one with the DAQ direction (from Slave to Master) and one with the
STIM direction (from Master to Slave).
In Figure 70, the ECU is connected to the plant. The necessary I/O and software compo
nents are available in the ECU. In the bypassing hardware, an algorithm A1 runs, which
occurs in Version A of the ECU. A1 is a new variant of the algorithm and should now be tried
out on the real plant.
4.5 Bypassing
99
ECU
A2L
XCP
Bypassing Hardware
CANapeBypassing
Hardware
A2L
XCP
I/O
Controller ModelECU
Plant
Figure 70: Basic principle of bypassingThe bypassing hardware (a VN8900 device in the figure) and the ECU are interconnected
over XCP. One goal here is to get the data needed for algorithm A1 from the ECU by DAQ;
another goal is to stimulate the results of A1 back into the ECU. The following figure illus
trates the schematic flow:
Bypassing Hardware
Algorithm A’2.BypassingCoordinator3.1. XCP 4.Algorithm AECU
Figure 71:
Bypassing flowDepicted in the ECU is a blue function block in which the algorithm A runs. To ensure that A1
can now be used, the data enters algorithm A as an input variable and it is measured from
the ECU by DAQ.
Step 1: In the ECU, the data is recorded and sent to the bypassing tool before the original
function is calculated in the ECU. Normally, the input data in functions A and A1 is are
identical.
Step 2: The data transferred via DAQ is now transferred to algorithm A1.
Step 3: The results of the calculation of algorithm A1 are transferred to the bypassing tool.
Step 4: The data is transferred into the ECU via STIM. The ECU calculates algorithm A dur
ing this time. If the stimulated results are available and calculation of algorithm A is com
100
4 Application Areas of XCP
plete, the values calculated in the ECU are typically overwritten by the stimulated values of
algorithm A1.
This makes it possible to use the value computed by algorithm A1 and not from A in the
ECU’s overall control process. This method permits using a combination of the rapid substi
tution of algorithms on the bypassing hardware that incorporates the I/O and the ECU’s
basic software.
Of course, performance limits of the transport protocol also affect bypassing. If short
bypassing times are needed, access to the ECU by DAQ and STIM may also be performed via
the controller’s debugging or trace interfaces. The Vector VX1000 measurement and cali
bration hardware converts the data into an XCPonEthernet data stream from the control
ler interface. In this process, up to one megabyte of data can be transported into the ECU.
XCP
Bypassing Hardware
Bypassing
CANapeHardware
A2L
XCP
Measurement & Calibration
Hardware VX1000
Debugging and
Trace Interface
I/O
Controller ModelECU
Plant
Figure 72: Bypassing with real-time bypassing hardware and fast ECU accessIn the figure, ECU access occurs via XCP on Ethernet, and calculation of the bypass algo
rithm occurs on separate bypassing hardware (VN8900 network interface) with a realtime
operating system. This means that the variance of the calculation time is considerably
smaller than with calculation on a laptop, as the processing time is not affected by other
applications.
4.6 Shortening Iteration Cycles with Virtual ECUs
101
4.6 Shortening Iteration Cycles with Virtual ECUs Stimulation with data is necessary to optimize the algorithm in the ECU with the help of
XCP. This can be done in the ECU in the framework of test drives. But there is yet another
solution that is available with XCP, in which the algorithm does not run on an ECU; rather it
runs on the PC in the form of executable code or as a model in Simulink in the form of a
“virtual ECU.” This virtual ECU does not need to run in real time, because in this case no con
nection to a real system exists. It can run significantly faster – depending on the PC’s com
puting power.
The algorithm is stimulated by a previously logged measurement file, which contains all
signals that are needed as input signals for the algorithm. The connection to CANape is set
up over XCP. The user can perform the parameterization and measurement configuration.
Afterwards, execution is started. Here the data from the test drive is fed into the algorithm
as stimulation and the desired measurement parameters from the application are simulta
neously measured out and saved to a measurement file.
Para-
MDF
meter
test drive
Application
5. Analyze
1. Set parameters
2. Start
Simulink/CANapeDLL3. Send test drive data
4. Measurement data
Slave
New
MDF
Figure 73:
Short calibration cycles
with virtual ECUs
102
4 Application Areas of XCP
After the calculation has been completed, a new measurement file is available to the user
for analysis of ECU behavior. The length of time of the new measurement file precisely
matches the length of the input measurement file. If the duration of a test drive is one hour,
the algorithm on the PC might calculate the entire test drive in just a few seconds. Then a
measurement result exists, which corresponds to a test of one hour duration. Based on the
data analysis, the user makes decisions about parameterization and the iteration cycle is
repeated.
CANapeApplication as EXE or DLL on PCParameterization
Set values in
via XCP
workspace
Start
Start
Send measurement
Calculate model
data
Receive new
Send measurement
measurement data
values from the model
Analyze the
End model calculation
new data
New software version
Figure 74:
Process flow with
virtual ECUsTo shorten the iteration cycles, the algorithm is always stimulated with the same data. That
makes the results with different parameters much more comparable, because the results
are only influenced by the parameters that differ.
This process can of course be automated. The integrated script language of CANape per
forms an analysis of the measurement results, from which parameter calibration settings
are derived and automatically executed. It is also possible to have the process controlled by
an external optimization tool such as MATLAB over the CANape automation interface.
5 Example of an XCP Implementation
105
5 Example of an XCP Implementation
106
5 Example of an XCP Implementation
To make it possible for an ECU to communicate over XCP, it is necessary to integrate an XCP
driver in the ECU’s application. The example described below is of the XCP driver which you
can download free of charge at the Download Center of the Vector website (www.vector.
com/xcpdriver). This packet also contains some sample implementations for various trans
port layers and target platforms. The driver consists of the protocolLayer with the basic
functionality needed for measurement and calibration. It does not include features such as
Cold Start Measurement, Stimulation or flashing. You can purchase a full implementation
as a product that is integrated in the Vector CANbedded or AUTOSAR environment.
The XCP protocol layer is placed over the XCP transport layer, which in turn is based on the
actual bus communication. The implementation of the XCP protocol layer only consists of a
single C file and a few H files (xcpBasix.c, xcpBasic.h, xcp_def.h and xcp_cfg.h). The examples
include implementations for various transport layers, e.g. Ethernet and RS232. In the case of
CAN, the transport layer is normally very simple and the various XCP message types are
mapped directly to CAN messages. There are then separate fixed identifiers for the Tx and
Rx directions.
The software interface between the transport and protocol layers is very simple. It contains
just a few functions:
> When the Slave receives an XCP message over the bus, it first arrives in the communica
tion driver, which routes the message to the XCP transport layer. The transport layer
informs the protocol layer about the message with the function call XcpCommand().
> If the XCP protocol layer wishes to send a message (e.g. a response to an XCP command
from the Master or a DAQ message), the message is routed to the transport layer by a call
of the ApplXcpSend() function.
> The transport layer informs the protocol layer that the message was successfully sent by
the function call XcpSendCallBack().
5 Example of an XCP Implementation
107
Applicationointer
etP
vent
ackground
cpG
cpE
cpInit
cpB
pplX
X
X
X
A
XCP Protocol Layerand
end
alback
pplication – XCP Transport Layer Interface
m
A
cpS
om
endC
pplX
cpC
A
cpS
X
X
XCP Transport LayerPhysical LayerFigure 75:
Incorporating Busthe XCP Slave
in the ECU codeThe interface between the application and the protocol layer can only be implemented via
four functions:
> The application activates the XCP driver with the help of XcpInit(). This call is made once
in the starting process.
> With XcpEvent(), the application informs the XCP driver that a certain event has occurred
(e.g. “End of a computational cycle reached”).
> The call XcpBackground() lets the XCP driver execute certain activities in background (e.g.
calculation of a checksum).
> Since the addresses in A2L files are always defined as 40bit values (32bit address, 8bit
address extension), the XCP driver uses the function ApplXcpGetPointer() to obtain a
pointer from a A2Lconformant address.
These interfaces are sufficient to integrate basic functionalities for measurement and cali
bration. Other interfaces are only needed for extended functions such as page switching,
identification or seed & key. They are described in detail in documentation for the driver.
108
5 Example of an XCP Implementation
5.1 Description of Functionsvoid XcpInit (void)Task:
Initialize the XCP driver.
Description:
The application activates the XCP driver with XcpInit(). This command must be executed
exactly once before any sort of XCP driver function may be called.
void XcpEvent (BYTE event)Task:
The application informs the XCP driver about which event occurred. A unique event number
is assigned to each event here.
Description:
In setting up the measurement configuration in the measurement and calibration tool, the
user selects which measured values should be synchronously acquired with which events. The
information on measured values and events originates from the A2L. The desired measure
ment configuration is communicated to the XCP driver in the form of DAQ lists.
Example of an event definition in an engine controller:
XcpEvent (1);
// Event 1 stands for the 10ms task
XcpEvent (2);
// Event 2 stands for the 100ms task
XcpEvent (5);
// Event 5 stands for the 1ms task
XcpEvent (8);
// Event 8 is used for ignition angle synchronous measurements
BYTE XcpBackground (void)Task:
Execute background activities of the XCP driver.
Description:
This function should be called periodically in a background or idle task. It is used by the
XCP driver, for example, to compute the checksum, because the computation of a longer
checksum in XcpCommand() could take an unacceptably long time. With each call of
XcpBackground(), a partial checksum of 256 bytes is computed. The duration of a checksum
computation therefore depends on the call frequency of XcpBackground(). There are no
other requirements for the call frequency or periodicity. The return value 1 indicates that a
checksum computation is currently running.
5.1 Description of Functions
109
void XcpCommand (DWORD* pCommand)Task:
Interpret an XCP command.
Description:
This function must be called each time the transport layer receives a XCP frame. The para
meter is a pointer to the frame.
void ApplXcpSend (BYTE len, BYTE *msg)Task:
Transfer a frame to be sent to the transport layer.
Description:
With this call, the protocol layer sends a message to the transport layer for transmission to
the Master. The call XcpSendCallBack implements a handshake method between the proto
col and transport layers.
BYTE XcpSendCallBack (void)Task:
The protocol layer uses this callback to inform the transport layer that the last message
that was transferred to ApplXcpSend() was successfully transmitted.
Description:
The protocol layer does not call an ApplXcpSend() command until XcpSendCallBack() indi
cates that the prior message was successfully transmitted. XcpSendCallBack() returns the
value 0 (FALSE) if the XCP driver is in idle. If there are more frames to be sent, ApplX
cpSend() is called directly from XcpSendCallBack().
BYTE *ApplXcpGetPointer (BYTE addr_ext, DWORD addr)Task:
Convert an A2Lconformant address to a pointer.
Description:
The function maps the 40bit A2Lconformant addressing (32bit address + 8bit address
extension) that is sent by the XCP Master to a valid pointer. The address extension can be
used, for example, to distinguish different address areas or memory types.
110
5 Example of an XCP Implementation
5.2 Parameterization of the DriverIn many respects, the XCP driver is scalable and parameterizable to properly handle the
wide variety of functional content, transport protocols and target platforms. All settings are
made in the parameter file xcp_cfg.h. In the simplest case, they appear as follows:
/* Define protocol parameters */
#define kXcpMaxCTO 8 /* Maximum CTO Message Length */
#define kXcpMaxDTO 8 /* Maximum DTO Message Length */
#define C_CPUTYPE_BIGENDIAN /* byte order Motorola */
/* Enable memory checksum */
#define XCP_ENABLE_CHECKSUM
#define kXcpChecksumMethod XCP_CHECKSUM_TYPE_ADD14
/* Enable calibration */
#define XCP_ENABLE_CALIBRATION
#define XCP_ENABLE_SHORT_UPLOAD
/* Enable data acquisition */
#define XCP_ENABLE_DAQ
#define kXcpDaqMemSize (512) /* Memory space reserved for DAQ */
#define XCP_ENABLE_SEND_QUEUE
For a CAN transport layer, the appropriate CTO and DTO parameters of eight bytes are set.
The driver must know whether it is running on a platform with Motorola or Intel byte order,
in this case a MotorolaCPU (Big Endian). The remaining parameters activate the function
alities: measurement, calibration and checksum computation. The algorithm for checksum
computation is configured (here summing of all bytes into a DWORD) and the parameter of
the available memory is indicated for the measurement (here 512 bytes). The memory is pri
marily needed to store the DAQ lists and to buffer the data during the measurement. The
parameter therefore determines the maximum possible number of measurement signals. In
the driver documentation you will find more detailed information on estimating the neces
sary parameters.
6 Protocol Development Overview
111
6 Protocol Development Overview
112
6 Protocol Development Overview
The following overview shows some of the essential developments of the XCP protocol,
which was standardized in 2003.
6.1. XCP Version 1.1 (2008)> Description of the same XCP interface using two different physical interfaces within the
same A2L (e.g. “XCP on Vehicle CAN” and “XCP on Calibration CAN”)
> The new command WRITE_DAQ_MULTIPLE makes it possible to accelerate configuration
of the Slave. Two ODTs appearing in succession in a DAQ list can be communicated in a
single step.
> High time synchronization via “TIMESTAMP_EVENT.” Timestamp information is communi
cated by the Slave. The trigger can be initiated via an external synchronization cable.
> Compression of embedded A2L files
All expansions are optional. XCP 1.1 is thus compatible with XCP 1.0.
6.2. XCP Version 1.2 (2013)> Parameters in the A2L for the definition of the required ECU resources via XCPDAQ mea
surement configurations (e.g. RAM usage, CPU execution time and required transfer band
width for CAN or Ethernet). The XCP Master can access the parameters, calculate
resource usage for the measurement and warn the user if overshooting occurs.
> Prioritization control by the Master for transfer of the measurement data via CAN. The
objective here is to not disturb the necessary communication flow of the vehicle CAN to
the greatest degree possible.
> Calculation of the required bandwidth and limits for the transfer of data via TCP or UDP
> Description of XCP on CAN FD
All expansions are optional. XCP 1.2 is thus compatible with XCP 1.1.
6.3. XCP Version 1.3 (2015)
113
6.3. XCP Version 1.3 (2015)> Improvement of the time correlation of XCP Slaves using multicast solutions found on the
same network
> Time synchronization between XCP Slave timestamp and external clock, e.g. via IEEE 1588
> Checking of the bypassing data flow and error handling
All expansions are optional. XCP 1.3 is thus compatible with XCP 1.2.
114
The Authors
The Authors Andreas PatzerMr. Patzer graduated in Electrical Engineering from the Technical University of
Karlsruhe. In his studies he specialized in measurement and control engineering
and information and industrial engineering. In 2003, he joined Vector Informatik
GmbH in Stuttgart. Andreas Patzer has supported XCP projects from the very
start, since XCP was standardized by ASAM e.V. in the same year he was hired.
He currently manages the Customer Relations and Services area as a team
leader for the Measurement & Calibration product line.
The Authors
115
Rainer ZaiserMr. Zaiser has a degree in Electrical Engineering from the University of
Stuttgart. After graduating, he came directly to Vector Informatik GmbH in
autumn 1988, where he has helped to create many of the standards that have
become established in the automotive industry such as DBC, MDF, CCP, A2L
and to a large extent XCP. From the start, he headed up the Measurement &
Calibration and Network Interfaces product lines.
116
Table of Abbreviations and Acronyms
Table of Abbreviations and Acronyms A2L
File extension for an ASAM 2MC language file
AML
ASAM 2 Meta Language
ASAM
Association for Standardisation of Automation and Measuring Systems
BYP
Bypassing
CAL
Calibration
CAN
Controller Area Network
CCP
CAN Calibration Protocol
CMD
Command
CS
Checksum
CTO
Command Transfer Object
CTR
Counter
DAQ
Data Acquisition, Data Acquisition Packet
DTO
Data Transfer Object
ECU
Electronic Control Unit
ERR
Error Packet
EV
Event Packet
FIBEX
Field Bus Exchange Format
LEN
Length
MCD
Measurement Calibration and Diagnostics
MTA
Memory Transfer Address
ODT
Object Descriptor Table
PAG
Paging
PGM
Programming
PHY
Physical Layer respectively description of the chip connecting a link layer
device to a physical medium, for example Ethernet PHY
PID
Packet Identifier
PTP
Precision Time Protocol
RES
Command Response Packet
SERV
Service Request Packet
SPI
Serial Peripheral Interface
STD
Standard
STIM
Data Stimulation Packet
TCP/IP
Transfer Control Protocol / Internet Protocol
TS
Timestamp
UDP/IP
Unified Data Protocol / Internet Protocol
USB
Universal Serial Bus
XCP
Universal Measurement and Calibration Protocol
Download
Sending of data from Master to Slave
Upload
Sending of data from Slave to Master
Literature & Web Addresses
117
LiteratureXCP is specified by ASAM (Association for Standardisation of Automation and Measuring
Systems).
You will find details on the protocol and on ASAM at:
www.asam.netWeb AddressesStandardization committees:
> ASAM, XCP protocolspecific documents, A2L specification,
www.asam.netSupplier of development software:
> MathWorks, information on MATLAB, Simulink and Simulink Coder,
www.mathworks.com > Vector Informatik GmbH, demo version of CANape, free of charge and openly available
XCP driver (basic version), comprehensive information on the topics of ECU calibration,
testing and simulation,
www.vector.com
118
Table of Figures
Table of Figures Figure 1: Fundamental communication with a runtime environment ..........................................8
Figure 2: The Interface Model of ASAM............................................................................................... 9
Figure 3: An XCP Master can simultaneously communicate with multiple Slaves ..................10
Figure 4: Subdivision of the XCP protocol into protocol layer and transport layer ................14
Figure 5: XCP Slaves can be used in many different runtime environments ............................15
Figure 6: XCP packet ..............................................................................................................................19
Figure 7: Overview of XCP Packet Identifier (PID) .........................................................................19
Figure 8: XCP communication model with CTO/DTO ....................................................................20
Figure 9: Message identification .........................................................................................................21
Figure 10: Timestamp ............................................................................................................................21
Figure 11: Data field in the XCP packet ............................................................................................22
Figure 12: The three modes of the XCP protocol: Standard, Block and Interleaved mode ...24
Figure 13: Overview of the CTO packet structure ..........................................................................25
Figure 14: Trace example from a calibration process .....................................................................30
Figure 15: Transfer of a parameter set file to an ECU’s RAM .....................................................31
Figure 16: Hex window ..........................................................................................................................32
Figure 17: Address information of the parameter “Triangle” from the A2L file ......................33
Figure 18: Polling communication in the CANape Trace window ................................................34
Figure 19: Events in the ECU ...............................................................................................................35
Figure 20: Event definition in an A2L .................................................................................................35
Figure 21: Allocation of “Triangle” to possible events in the A2L ................................................36
Figure 22: Selecting events (measurement mode) for each measurement parameter .........36
Figure 23: Excerpt from the CANape Trace window of a DAQ measurement .........................37
Figure 24: ODT: Allocation of RAM addresses to DAQ DTO .........................................................38
Figure 25: DAQ list with three ODTs ..................................................................................................39
Figure 26: Static DAQ lists ...................................................................................................................40
Figure 27: Dynamic DAQ lists ..............................................................................................................41
Figure 28: Event for DAQ and STIM ...................................................................................................42
Figure 29: Structure of the XCP packet for DTO transmissions..................................................43
Figure 30: Identification field with absolute ODT numbers ..........................................................44
Figure 31: ID field with relative ODT and absolute DAQ numbers (one byte) .........................44
Figure 32: ID field with relative ODT and absolute DAQ numbers (two bytes) ......................44
Figure 33: ID field with relative ODT and absolute DAQ numbers as well as fill byte
(total of four bytes) ............................................................................................................45
Figure 34: XCP Slave with freerunning clock .................................................................................46
Figure 35: The clock of the XCP Slave is synchronized with the grandmaster clock .............47
Figure 36: Definition of which bus nodes send which messages .................................................49
Figure 37: Representation of a CAN network ..................................................................................50
Figure 38: Example of XCPonCAN communication .....................................................................51
Figure 39: Representation of an XCPonCAN message ...............................................................51
Figure 40: Illustration of a CAN FD frame ........................................................................................52
Figure 41: Nodes K and L are redundantly interconnected ...........................................................54
Figure 42: Communication by slot definition ...................................................................................54
Figure 43: Representation of a FlexRay communication matrix..................................................55
Figure 44: Representation of the FlexRay LPDUs ...........................................................................56
Table of Figures
119
Figure 45: Allocation of XCP communication to LPDUs ................................................................57
Figure 46: XCP packet with TCP/IP or UDP/IP ................................................................................58
Figure 47: XCPonSxI packet ..............................................................................................................59
Figure 48: Memory representation .....................................................................................................61
Figure 49: Representation of driver settings for the flash area ..................................................63
Figure 50: Representation of the block transfer mode ..................................................................66
Figure 51: Parameters in a calibration window ...............................................................................72
Figure 52: Signal response over time .................................................................................................72
Figure 53: Initial parameter setting in RAM .....................................................................................82
Figure 54: Initial situation after booting ...........................................................................................86
Figure 55: Pointer change and copying to RAM ..............................................................................87
Figure 56: Pointer table for individual parameters .........................................................................87
Figure 57: Double pointer concept ......................................................................................................89
Figure 58: Application areas and application cases .......................................................................92
Figure 59: Plants and controllers ........................................................................................................92
Figure 60: Model in the Loop in Simulink ..........................................................................................93
Figure 61: CANape as measurement and calibration tool with Simulink models ...................93
Figure 62: Software in the Loop with Simulink environment .......................................................94
Figure 63: CANape as SIL development platform ..........................................................................94
Figure 64: HIL solution ...........................................................................................................................95
Figure 65: HIL with CANape as measurement and calibration tool ...........................................95
Figure 66: CANoe as HIL system .........................................................................................................96
Figure 67: CANoe as HIL system with XCP access to the ECU ...................................................96
Figure 68: CANape as HIL solution .....................................................................................................97
Figure 69: RCP solution .........................................................................................................................97
Figure 70: Basic principle of bypassing ..............................................................................................99
Figure 71: Bypassing flow .....................................................................................................................99
Figure 72: Bypassing with realtime bypassing hardware and fast ECU access ................. 100
Figure 73: Short calibration cycles with virtual ECUs ................................................................. 101
Figure 74: Process flow with virtual ECUs ..................................................................................... 102
Figure 75: Incorporating the XCP Slave in the ECU code .......................................................... 107
120
Appendix – XCP Solutions at Vector
Appendix – XCP Solutions at VectorVector made a significant effort in giving shape to the XCP standard. Its extensive know
how and vast experience were utilized to provide comprehensive XCP support:
Tools
> The primary use area of
CANape is in optimal parameterization (calibration) of electronic
control units (ECUs). During the system’s runtime, you calibrate parameter values and
simultaneously acquire measured signals. The physical interface between CANape and the
ECU is over XCP (for all standardized transport protocols) or CCP.
> Complete tool chain for generating and managing the necessary A2L description files
(
ASAP2 Tool-Set and
CANape with the
ASAP2 Editor).
> You use
CANoe.XCP to access internal ECU values for testing and analysis tasks.
ECU Interfaces
The
VX1000 measurement and calibration hardware offers the option of equipping ECUs
with an XCPonEthernet interface. This involves connecting a Plug on Device (POD) to the
ECU for direct access to the controller, e.g. over DAP, JTAG, Nexus, etc. The POD transmits
the data to a base module, which operates as an XCP Slave and provides the data to the
XCP Master on the PC over XCP on Ethernet. This makes it unnecessary to have an XCP
Slave in the ECU. The user benefits from a high measurement data throughput rate of up to
50 MByte/s and short measurement intervals of less than 15 µs.
Embedded Software
Communication modules with separate transport layers for CAN, FlexRay and Ethernet:
>
XCP Basic – free download at www.vector.com/xcpdriver, only contains basic XCP func
tions. Configuration of the XCP protocol and modification of the transport layer are per
formed manually in the source code. You need to integrate XCP Basic in your project
yourself.
>
XCP Professional – contains useful extensions to the ASAM specification and enables tool
based configuration. Available for Vector CANbedded basic software.
>
MICROSAR XCP – contains the functional features of XCP Professional and is based on
AUTOSAR specifications. Available for Vector MICROSAR basic software.
Services
>
Consultation for using XCP in your projects
>
Integration of XCP in your ECU
Training
> You can learn about the underlying mechanisms and models of the protocol in the
“XCP Fundamentals Seminar”.
> In the
“CANape with XCP on FlexRay Workshop” you learn about FlexRay fundamentals
and the special aspects of XCP on FlexRay are explained, in particular dynamic bandwidth
management.
Special XCP Support by CANape
121
Special XCP Support by CANape
CANape was the first MCD tool to support the XCP 1.0 specification and was also the first
XCP on FlexRay Master on the market.
A special technical feature of XCP on FlexRay is dynamic bandwidth management. Here,
CANape identifies the available bandwidth provided for XCP in the FlexRay ClusterP and it
allocates this bandwidth to the momentary application data traffic dynamically and very
efficiently. The available bandwidth is thereby optimally used for XCP communication.
Moreover, CANape has a DLL interface. It enables support of XCP on any desired (user
defined) transport layer. This lets you integrate any desired test instrumentation or proprie
tary protocols in CANape. A code generator supports you in creating the XCPspecific share
of such a driver.
122
Index
IndexAFA2L
9, 10, 25, 35, 40, 42, 56, 57, 62, 63, 68, FIBEX
55 – 57
71 – 76, 94, 108, 109, 116
Flash memory
16, 17, 61 – 64, 67
Address extension
29, 33, 38, 107, 109
FLX_CHANNEL
56
AML
25, 74, 116
FLX_LPDU_ID
56
ASAM
7 – 9, 60, 116
FLX_SLOT_ID
56
ASAP2 ToolSet
76
Fullpassing
98
BGBandwith optimization
34
GET_CAL_PAGE
25, 62
Bus load
34
GET_DAQ_EVENT_INFO
65, 77
BYP
116
GET_DAQ_LIST_INFO
77
Bypassing
45, 98, 100
GET_DAQ_PROCESSOR_INFO
45, 65, 77
GET_DAQ_RESOLUTION_INFO
65, 77
CGrandmaster clock
47, 48
CAN
7, 8, 14, 24, 29, 33, 38, 49, 50, 51, 55,
75, 116
HCAN FD
52
HIL
92, 95 – 97
CCP
7, 8, 40, 49, 116
CMD
25, 56, 116
ICTO
21, 22, 25, 116
IEEE 1588
47
CTR
58, 59, 116
IF_DATA
25
CYCLE_REPETITION
56
KDCommands
25
DAQ
22, 32 – 45, 65, 67, 77, 99, 100, 106, Compile
76, 80, 82, 94
108, 116
DAQ_KEY_BYTE
45
LDBC
49
Linking
80, 94
Double Pointer Concept
88
LPDU
56
DOWNLOAD
30, 31, 66
DTO
21, 22, 33, 37, 116
M
Maturity level
31
EMIL
93
ECU
9, 74, 98, 99, 116
MTA
30, 116
ECU description file A2L
72 – 77
Multicast 46,
113
EEPROM
16, 31, 67
ERR
25, 28, 116
OEthernet 57 – 59
ODT
37 – 41, 43, 44, 65, 77, 116
EV
29, 116
OFFSET
56
Event
35, 38 – 40, 42,65, 67, 77, 108
Index
123
P
PAG
116
Page
61 – 63
Page switching
62, 63
Parameter
85
PGM
116
PID
8, 19, 21, 25, 43, 116
Polling
33, 34, 36
PTP
47
R
RAM
16 – 18, 30, 31, 37, 39, 63, 67, 80, 82,
85, 86, 88
Reboot
32
RES
21, 28, 56, 116
S
Sector
61 – 63
Segment
61 – 63
SEGMENT_NUMBER
62
SERV
29, 116
SET_CAL_PAGE
25, 62
SET_MTA
30
SHORT_UPLOAD
30, 33, 66
SIL
92, 94
Single Pointer Concept
86
STIM
33, 42, 43, 45, 65, 77, 100, 116
Stimulation
29, 68, 101
T
Task
108
TCP/IP
57, 58, 116
U
UDP/IP
57, 58, 116
USB
60, 116
V
Virtual ECU
101
Volatile 81, 82
VX1000
100
Get More InformationVisit our Website for:
> News
> Products
> Demo Software
> Support
> Trainings Classes
> Addresses
16
/20
0 | 12
www.vector.comV3.
Document Outline
