This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Universal Measurement and Calibration Protocol (XCP)

1: AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPro
2: AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPro_ind
3: AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPros
4: TechnicalReference_Xcp
5: TechnicalReference_Xcp_ind
6: TechnicalReference_Xcps
7: UserManual_AUTOSAR_Calibration
8: UserManual_AUTOSAR_Calibration_ind
9: UserManual_AUTOSAR_Calibrations
10: Xcp Peer Review Checklists
11: XCP_ReferenceBook_V2.0_EN
12: XCP_ReferenceBook_V2.0_EN_ind
13: XCP_ReferenceBook_V2.0_ENs

Universal Measurement and Calibration Protocol (XCP)

Component Documentation

1 - AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPro

How to add CAN XCP messages in DaVinciConfiguratorPro

2 - AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPro_ind

Outline
Page 1
Page 2
Page 3
Page 4

3 - AN-ISC-8-1169_How_to_add_XCP_PDUs_in_DaVinciConfiguratorPros

1.0  Overview
The DaVinci Configurator Pro workflow allows adding XCP PDUs in two ways:
•  XCP PDUs are defined in the SystemDescription or DBC/FIBEX file that has been provided by the vehicle
manufacturer. Such files can be created or modified with Vector tools such as the AUTOSAR Network
Explorer or CANdb++. The ECUC configuration (including the XCP PDUs) can be derived from such input
formats. The XCP PDUs will have to be added each time a new version is received from the vehicle
manufacturer.
•  XCP PDUs can be created within DaVinci Configurator Pro by configuring the affected modules directly.
These messages are independent of PDUs defined by the input formats provided by the vehicle
manufacturer. During a database update the added PDUs will not be removed.

This document describes the second approach: Adding XCP PDUs directly to the ECUC configuration.

1.1  BSW Module Configuration
This document assumes that CAN based communication (except XCP) is configured and operational.
The names and the detailed properties are meant to be examples and can be modified as required. A general
description how XCP is configured can be found in the technical reference of that module.

1.2  ECUC Configuration
Navigate to /MICROSAR/EcuC/EcucPduCollection
•  Add a new (global) PDU for XCP message transmission (Tx) and message reception (Rx)
•  Configure the PDU length to 8 bytes for both PDUs

Figure 1 – Enter PDU Information for Rx.

Figure 2 – Enter PDU Information for Tx
2
Copyright © 2014 - Vector Informatik GmbH
Contact Information: www.vector.com or +49-711-80 670-0

How to add CAN XCP messages in DaVinciConfiguratorPro

1.3  CANIF Configuration
Navigate to /MICROSAR/CanIf/CanIfInitCfg/CanIfRxPduCfg
•  Add a new CANIF Rx PDU (CanIfRxPduCfg)
•  Configure the CAN message:

CanIfRxPduCanId
The CAN ID that shall be use as Xcp Request ID
CanIfRxPduCanIdType
Type of CAN message (e.g. standard or extended addressing)
CanIfRxPduHrhIdRef
Hardware receive handle used to receive this message. This reference
defines indirectly the channel the XCP message is received on.
CanIfRxPduRef
Reference to the global Rx PDU defined in the ECUC module (s. 1.2)
CanIfRxPduUserRxIndicationUL
Set this parameter to XCP
CanIfRxPduUserRxIndicationName

Will be set to Xcp_CanIfRxIndication by the configuration tool
Figure 3 – Configure CAN Rx Message

Navigate to /MICROSAR/CanIf/CanIfInitCfg/CanIfTxPduCfg
•  Add a new CANIF Tx PDU (CanIfTxPduCfg)
•  Configure the CAN message

CanIfTxPduBufferRef
Buffering strategy. For XCP the existing default buffer (0 byte in size)
can typically be reused.
CanIfTxPduCanId
The CAN ID that shall be use as Xcp Response ID
CanIfTxPduCanIdType
Type of CAN message (e.g. standard or extended addressing)
CanIfTxPduDlc
Set this parameter to 8 bytes (non CAN-FD)
CanIfTxPduRef

Reference to the global Tx PDU defined in the ECUC module (s. 1.2)
Figure 4 – Configure CAN Tx Message
CanIfTxPduType
Set this parameter to STATIC
CanIfTxPduUserTxConfirmationUL
Set this parameter to XCP
CanIfTxPduUserTxConfirmationName
This parameter will be set to Xcp_CanIfTxConfirmation by the
configuration tool

3
Application Note AN-ISC-8-1169

How to add CAN XCP messages in DaVinciConfiguratorPro

1.4  XCP Configuration
Navigate to the XCP settings in the basic editor
•  Create one Rx and one Tx XCP PDU by adding choice containers (right click on the blue/yellow container,
select Choose) below the XcpPdus node.

Figure 5 – XCP Module in Basic Editor

•  Configure the parameter Rx Pdu Ref and Tx Pdu Ref (screenshot looks the same for Tx) by selecting the
global PDU that has been configured in the ECUC module (done in 1.2).

Figure 6 – Configuration of Rx Pdu Ref

Figure 7 – Configuration of Tx Pdu Ref
•  Within the XcpGeneral container, enable the flag XcpOnCanEnabled

2.0  Additional Resources
MICROSAR Technical References
-  TechnicalReference_Asr_CanIf.pdf
-  TechnicalReference_Asr_CanXcp.pdf
-  TechnicalReference_Asr_Xcp.pdf
-  XCP_ReferenceBook_<Version/Language>.pdf
3.0  Contacts
For a full list with all Vector locations and addresses worldwide, please visit http://vector.com/contact/.

4
Application Note AN-ISC-8-1169

Document Outline

4 - TechnicalReference_Xcp

Technical Reference

5 - TechnicalReference_Xcp_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
Page 87
Page 88
Page 89
Page 90
Page 91
Page 92
Page 93
Page 94

6 - TechnicalReference_Xcps

XCP Protocol Layer
Technical Reference

Version 2.05.00

Version:
2.05.00
Status:
Released

Technical Reference XCP Protocol Layer

1  History
Date
Version  Remarks
2005-01-17  1.00.00  ESCAN00009143: Initial draft
Warning Text added
2005-06-22  1.01.00  FAQ extended: ESCAN00012356, ESCAN00012314
ESCAN00012617: Add service to retrieve XCP state
2005-12-20  1.02.00  ESCAN00013883: Revise Resume Mode
2006-03-09  1.03.00  ESCAN00015608: Support command
TRANSPORT_LAYER_CMD
ESCAN00015609: Support XCP on FlexRay Transport Layer
2006-04-24  1.04.00  ESCAN00015913: Correct filenames
Data page banking support of application callback template
added
2006-05-08  1.05.00  ESCAN00016263: Describe support of reflected CRC16 CCITT
ESCAN00016159: Add demo disclaimer to XCP Basic
2006-05-29  1.06.00  ESCAN00016226: Support XCP on LIN Transport Layer
2006-07-20  1.07.00  ESCAN00012636: Add configuration with GENy
ESCAN00016956: Support AUTOSAR CRC module
2006-10-26  1.08.00  ESCAN00018115: DPRAM Support only available in XCP Basic
ESCAN00017948: Add paging support
ESCAN00017221: Documentation of reentrant capability of all
functions
2007-01-18  1.09.00  ESCAN00018809: Support data paging on Star12X / Cosmic
2007-05-07  1.10.00  Description of new features added
2007-09-14  1.11.00  Segment freeze mode now supported
2008-07-23  1.12.00  ESCAN00028586: Support of Program_Start callback
ESCAN00017955: Support MIN_ST_PGM
ESCAN00017952: Open Interface for command processing
2008-09-10  1.13.00  Additional pending return value of call backs added
MIN_ST configuration added
2008-12-01  1.14.00  ESCAN00018157: SERV_RESET is not supported
ESCAN00032344: Update of XCP Basic Limitations
2009-05-14  1.15.00  ESCAN00033909: New features implemented: Prog Write
Protection, Timestamps, Calibration activation
2009-07-30  1.15.01  Fixed some editorial errors
2009-11-13  1.16.00  Added AUTOSAR Compiler Abstraction
2010-04-30  1.16.01  Fixed some editorial errors
2010-07-27  1.16.02  Fixed some editorial errors
2010-08-19  1.17.00  ESCAN00044693: New callbacks XcpCalibrationWrite and
XcpCalibrationRead
ESCAN00042867: Support Multiple Transport Layers
2016, Vector Informatik GmbH
Version: 2.05.00
2 / 94

Technical Reference XCP Protocol Layer

2010-12-10  1.18.00  ESCAN00045981: Add support to read out FR Parameters
2011-07-20  1.19.00  ESCAN00049542: Describe IDT_VECTOR_MAPNAMES format
in TechRef
ESCAN00043487: XCP shall support user selectable behaviour
of Send Queue overrun
2011-08-04

ESCAN00052564: Adapt ReadCcConfig Parameter to ASR3.2.1
2012-02-20  1.19.01  ESCAN00055214: DAQ Lists can be extended after
START_STOP_SYNCH
2012-09-03  1.19.02  ESCAN00061159: Provide an API to detect XCP state and usage
2012-11-08  1.19.03  Added Option for AMD Runtime Measurement
2011-03-23  2.00.00  ESCAN00049471: Create branch for AUTOSAR 4
2013-02-11  2.01.01  Editorial Changes
2013-07-08  2.02.00  ESCAN00068035: Xcp_SetTransmissionMode not supported
ESCAN00070127: AR4-322/AR3_2552: Support of Vx1000
System
ESCAN00070082: The API ApplXcpDaqResumeStore has a
wrong description
ESCAN00069019: Mapping to critical sections not described in
detail for Protocol Layer
ESCAN00068639: Describe data consistency on ODT Level
ESCAN00067332: Document the usage of the
Xcp_MainFunction/XcpBackground
2013-12-04  2.03.00  ESCAN00072401: Support custom CRC Cbk
ESCAN00072326: Support Generic GET_ID
2014-08-15  2.03.01  ESCAN00077231: AR3-2679: Description BCD-coded return-
value of Xcp_GetVersionInfo() in TechRef
ESCAN00077813: Specify supported ASAM Version
2015-02-02  2.03.02  ESCAN00080981: SET_CAL_PAGE is limited to synchronous
operation
2015-06-09  2.04.00  ESCAN00082215: FEAT-1450: Basic MultiCore XCP
2016-02-18  2.04.01  ESCAN00087492: New API
ApplXcpMeasurementRead/ApplXcpCalibrationWrite not
documented
ESCAN00087496: Return code description of ApplXcp call-backs
incomplete
2016-10-04  2.05.00  Replaced Xcp_Control API by variable.
ESCAN00091747: FEAT-1980: Add Multi Client / Multi
Connection support
ESCAN00092229: Support API to modify Protection State

2016, Vector Informatik GmbH
Version: 2.05.00
3 / 94

Technical Reference XCP Protocol Layer

Please note
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.

Note for XCP Basic
Please note, that the demo and example programs only show special aspects of the

software. With regard to the fact that these programs are meant for demonstration
purposes only, Vector Informatik’s liability shall be expressly excluded in cases of
ordinary negligence, to the extent admissible by law or statute.

2016, Vector Informatik GmbH
Version: 2.05.00
4 / 94

Technical Reference XCP Protocol Layer

Illustrations
Figure 3-1
Data consistency ...................................................................................... 23

2016, Vector Informatik GmbH
Version: 2.05.00
10 / 94

Technical Reference XCP Protocol Layer

2  Overview
This  document  describes  the  features,  API,  configuration  and  integration  of  the  XCP
Protocol Layer. Both XCP versions: XCP Professional and XCP Basic are covered by this
document. Chapters that are only relevant for XCP Professional are marked.
This document does not cover the XCP Transport Layers for CAN, FlexRay and LIN, which
are available at Vector Informatik.
Please refer to [IV] for further information about XCP on CAN and the integration of XCP
on CAN with the Vector CANbedded software components. Further information about XCP
on  FlexRay  Transport  Layer  and  XCP  on  LIN  Transport  Layer  can  be  found  in  its
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.
Referred functions are always shown in the single channel mode.

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.

2.1
Abbreviations and Items used in this paper

Abbreviations
Complete expression
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
2016, Vector Informatik GmbH
Version: 2.05.00
11 / 94

Technical Reference XCP Protocol Layer

CMD
Command
CTO
Command Transfer Object
DAQ
Synchronous Data Acquistion
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
Programming
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
UDP/IP
Unified Data Protocol / Internet Protocol
USB
Universal Serial Bus
XCP
Universal Measurement and Calibration Protocol
VI
Vector Informatik GmbH

Also refer to ‘AN-AND-1-108 Glossary of CAN Protocol Terminology.pdf’, which can be
found in the download area of http://www.vector-informatik.de.
2016, Vector Informatik GmbH
Version: 2.05.00
12 / 94

Technical Reference XCP Protocol Layer

2.2
Naming Conventions
The names of the access functions provided by the XCP Protocol Layer always start with a
prefix that includes the characters Xcp. The characters Xcp are surrounded by an
abbreviation which refers to the service or to the layer which requests a XCP service. The
designation of the main services is listed below:

Naming conventions
Xcp_…
It is mandatory to use all functions beginning with Xcp…
These services are called by either the data link layer or the application.
They are e.g. used for the initialization of the XCP Protocol Layer and for the
cyclic background task.
XcpAppl_... The functions, starting with ApplXcp… are functions that are provided
either by any XCP Transport Layer or the application and are called by the
XCP Protocol Layer.
These services are user callback functions that are application specific and have
to be implemented depending on the application.

2016, Vector Informatik GmbH
Version: 2.05.00
13 / 94

Technical Reference XCP Protocol Layer

3  Functional Description
3.1
Overview of the Functional Scope
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.
3.2
Communication Mode Info
In order to gather information about the XCP Slave device, e.g. the implementation version
number  of  the  XCP  Protocol  Layer  and  supported  communications  models,  the
communication mode info can be enabled by the switch XCP_ENABLE_COMM_MODE_INFO.
3.3
Block Transfer Communication Model (XCP Professional only)
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.
In Slave Block Transfer Mode the slave can respond subsequent (there is no limitation) to
a request without additional requests in between.
Refer to chapter 6.8.1 for configuration details.
3.4
Slave Device Identification
3.4.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.
Refer  to  chapter  6.8.4.1  (Identification  by  ASAM-MC2  Filename  without  Path  and
Extension) for configuration details.
2016, Vector Informatik GmbH
Version: 2.05.00
14 / 94

Technical Reference XCP Protocol Layer

3.4.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. The following function
uint32 XcpAppl_GetIdData( MTABYTEPTR *pData, uint8 id )
(6.5.2)
has to set a pointer to the identification information based on the requested id and return
the length of this information.
Refer to chapter 6.8.4.2 (Automatic Session Configuration with MAP Filenames) for an
example implementation.

3.4.3
Identification of FlexRay Parameters
If the “Virtual FlexRay Parameters” feature is enabled, the parameters can be read out in a
platform independent way. They will be provided as virtual measurement values that can
be read at fixed memory locations with a configurable Address Extension.
To calculate the memory address for each parameter please read the Technical Reference
and the AUTOSAR specification of the FlexRay Driver. Each FlexRay parameter is defined
with a unique ID to be used as parameter for the API call. Use this ID and multiply it with
four to get the address where this variable can be measured at.
If this parameter is enabled the API:

Std_ReturnType
FrIf_ReadCCConfig(
uint8
ClusterIdx,
uint8
FrIf_CCLLParamIndex,  P2VAR(uint32,  AUTOMATIC,  FRIF_APPL_DATA)
FrIf_CCLLParamValue )
will be called. The FlexRay parameters can be measured from CAN and FlexRay but the
API is only provided if the FlexRay Interface is present.
3.5
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.
The seed & key functionality can be enabled with the switch XCP_ENABLE_SEED_KEY and
disabled with XCP_DISABLE_SEED_KEY in order to save ROM. Also refer to chapter 6.8.1.
The application callback function
uint8  XcpAppl_GetSeed(  uint8  Xcp_Channel,  MEMORY_ROM  uint8
resourceMask, BYTEPTR seed )
(6.5.3)
returns a seed that is transferred to the MCS. The callback function
uint8  XcpAppl_Unlock(  uint8  Xcp_Channel,  MEMORY_ROM  uint8  *key,
MEMORY_ROM uint8 length )
(6.5.4)
has to verify a received key and if appropriate return the resource that shall be unlocked.
The service:
2016, Vector Informatik GmbH
Version: 2.05.00
15 / 94

Technical Reference XCP Protocol Layer

uint8  Xcp_ModifyProtectionStatus(  uint8  Xcp_Channel,  uint8
andState, uint8 orState )
(6.2.13)
can be used to modify the protection state by software.

Annotation for the usage of CANape
The calculation of the key is done in a DLL named SEEDKEY1.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.
Example Implementation for SEEDKEY1.DLL
The function call of ASAP1A_XCP_ComputeKeyFromSeed() is standardized by the ASAM
committee.

Example
FILE SEEDKEY1.H

#ifndef _SEEDKEY_H_

#define _SEEDKEY_H_
#ifndef DllImport
#define DllImport __declspec(dllimport)
#endif
#ifndef DllExport
#define DllExport __declspec(dllexport)
#endif
#ifdef SEEDKEYAPI_IMPL
#define SEEDKEYAPI DllExport __cdecl
#else
#define SEEDKEYAPI DllImport __cdecl
#endif
#ifdef __cplusplus
extern "C" {
#endif

BOOL SEEDKEYAPI ASAP1A_XCP_ComputeKeyFromSeed( BYTE *seed,
  unsigned short sizeSeed,
  BYTE *key,
  unsigned short maxSizeKey,
  unsigned short *sizeKey
  );
#ifdef __cplusplus
}
#endif
#endif

FILE SEEDKEY1.C
#include <windows.h>
#define SEEDKEYAPI_IMPL
#include "SeedKey1.h"

extern "C" {
BOOL SEEDKEYAPI ASAP1A_XCP_ComputeKeyFromSeed( BYTE *seed,
  unsigned short sizeSeed,
2016, Vector Informatik GmbH
Version: 2.05.00
16 / 94

Technical Reference XCP Protocol Layer

  BYTE *key,
  unsigned short maxSizeKey,
  unsigned short *sizeKey
  )
{ // in that example sizeSeed == 4 is expected only
  if( sizeSeed != 4 ) return FALSE;
  if( maxSizeKey < 4 ) return FALSE;
  *((unsigned long*)key) *= 3;
  *((unsigned long*)key) &= 0x55555555;
  *((unsigned long*)key) *= 5;
  *sizeKey = 4;
  return TRUE;
  }
}

3.6
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.
XCP Professional allows the usage of the AUTOSAR CRC Module [VII]. If the AUTOSAR
CRC Module is used also the XCP CRC32 algorithm can be used.
Also refer to 6.8.2.1 ‘Table of Checksum Calculation Methods’.
If checksum calculation is enabled the background task has to be called cyclically.
3.6.1
Custom CRC calculation
The Protocol Layer also allows the calculation of the CRC by the application. For this the
call-back:
uint8  XcpAppl_CalculateChecksum(  uint8  Xcp_Channel,  ROMBYTEPTR
pMemArea, BYTEPTR pRes, uint32 length )
is  called.  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 every case the response frame has to be assembled.
3.7
MainFunction
The Xcp provides a MainFunction:
void Xcp_MainFunction( void )
(6.2.5)
which 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.

2016, Vector Informatik GmbH
Version: 2.05.00
17 / 94

Technical Reference XCP Protocol Layer

3.8
Memory Protection (XCP Professional only)
If XCP_ENABLE_WRITE_PROTECTION is defined write access of specific RAM areas can
be checked with the function
uint8 XcpAppl_CheckWriteAccess( MTABYTEPTR addr, uint8 size )(6.5.7)
It should only be used, if write protection of memory areas is required.
If XCP_ENABLE_READ_PROTECTION is defined read access of specific RAM areas can be
checked with the function
uint8 XcpAppl_CheckReadAccess( MTABYTEPTR addr, uint8 size )(6.5.8)
It should only be used, if read protection of memory areas is required.
While  the  first  two  functions  are  used  during  polling,  the  following  function  is  used  for
DAQ/STIM access:
uint8 XcpAppl_CheckDAQAccess( DAQBYTEPTR addr, uint8 size ) (6.5.9)
These  functions  can  be  used  to  protect  memory  areas  that  are  not  allowed  to  be
accessed, e.g. memory mapped registers or the xcp memory itself.
3.9
Memory Access by Application
There are two APIs available that allow memory access by application. Those APIs can be
enabled by setting XCP_ENABLE_CALIBRATION_MEM_ACCESS_BY_APPL. Please note that these
API are only used for polling access. DAQ/STIM still uses direct memory access.
uint8
XcpAppl_CalibrationWrite(
P2VAR(void,
AUTOMATIC,
XCP_APPL_DATA) dst, P2CONST(void, AUTOMATIC, XCP_APPL_DATA) src,
uint8 len )
(6.5.33)
uint8
XcpAppl_MeasurementRead(
P2VAR(void,
AUTOMATIC,
XCP_APPL_DATA) dst, P2CONST(void, AUTOMATIC, XCP_APPL_DATA) src,
uint8 len )
(6.5.32)
If
the
option
XCP_ENABLE_DAQ_MEM_ACCESS_BY_APPL
is
set
the
function
XcpAppl_MeasurementRead is also called for DAQ measurement.
3.9.1
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. See 3.21.1 for further information.
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  XCP_ENABLE_SEND_EVENT.  The
transmission is done by the service
void Xcp_SendEvent( uint8 evc, ROMBYTEPTR c, uint8 len )
(6.2.6)
2016, Vector Informatik GmbH
Version: 2.05.00
18 / 94

Technical Reference XCP Protocol Layer

The event codes can be found in the following table.
Event
Code  Description
EV_RESUME_MODE
0x00  The slave indicates that it is starting in RESUME mode.
EV_CLEAR_DAQ
0x01  The slave indicates that the DAQ configuration in non-
volatile memory has been cleared.
EV_STORE_DAQ
0x02  The slave indicates that the DAQ configuration has been
stored into non-volatile memory.
EV_STORE_CAL
0x03  The slave indicates that the calibration data has been
stored.
EV_CMD_PENDING
0x05  The slave requests the master to restart the time-out
detection.
EV_DAQ_OVERLOAD
0x06  The slave indicates an overload situation when
transferring DAQ lists.
EV_SESSION_TERMINATED  0x07  The slave indicates to the master that it autonomously
decided to disconnect the current XCP session.
EV_USER
0xFE  User-defined event.
EV_TRANSPORT
0xFF  Transport layer specific event.

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 due to these packets are not being acknowledged.
The service request messages can be sent by the following functions
void Xcp_PutChar ( const uint8 c )
(6.2.7)
void Xcp_Print ( const uint8 *str )
(6.2.8)
Refer to 6.8.1 for the configuration of the service request message.
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
XCP_ENABLE_USER_COMMAND  and  upon  reception  of  the  user  command  the  following
callback function is called by the XCP command processor:
uint8 XcpAppl_UserService ( uint8 Xcp_Channel, ROMBYTEPTR pCmd
)
(6.5.11)
3.13  Transport Layer Command
The transport layer commands are received by the XCP Protocol Layer and processed by
the  XCP Transport  Layer. The  XCP  Protocol  Layer  transmits  the  XCP  response  packets
(RES) or XCP error packets (ERR).
2016, Vector Informatik GmbH
Version: 2.05.00
19 / 94

Technical Reference XCP Protocol Layer

The transport layer command is enabled by setting XCP_ENABLE_TL_COMMAND.
Upon reception of any transport layer command the following callback function is called by
the XCP command processor:
uint8 ApplXcpTLService ( ROMBYTEPTR pCmd )
(6.4.5)

3.14  Synchronous Data Transfer
3.14.1  Synchronous Data Acquisition (DAQ)
The  synchronous  data  transfer  can  be  enabled  with  the  compiler  switch
XCP_ENABLE_DAQ. 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  cyclically  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,  which  is defined  in  the  MCS.  Note  that
the event channel numbers are given by the GenTool when the Event Info feature is used.
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.
The data acquisition mode can be used in multiple configurations that are described within
the next chapters.
Annotation for the usage of CANape
It is recommended to enable both data acquisition plug & play mechanisms to detect the
DAQ settings.
3.14.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:
XcpDaqTimestampType XcpAppl_GetTimestamp ( void )                         (6.5.24)
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
2016, Vector Informatik GmbH
Version: 2.05.00
20 / 94

Technical Reference XCP Protocol Layer

  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 (e.g. GENy) accordingly.
For the configuration of the DAQ time stamped mode refer to chapter 6.8.6 (Configuration
of the DAQ Time Stamped Mode).
3.14.3  Power-Up Data Transfer
Power-up data  transfer  (also  called  resume mode)  allows  automatic  data  transfer  (DAQ,
STIM)  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.
uint8 XcpAppl_DaqResume ( uint8 Xcp_Channel, tXcpDaq * daq ) (6.5.20)
void XcpAppl_DaqResumeStore ( uint8 Xcp_Channel, const tXcpDaq
* daq )
(6.5.21)
void XcpAppl_DaqResumeClear ( uint8 Xcp_Channel )
(6.5.22)
uint8 XcpAppl_CalResumeStore ( uint8 Xcp_Channel )
(6.5.23)
To  use  the  resume  mode  the  compiler  switches  XCP_ENBALE_DAQ  and
XCP_ENABLE_RESUME_MODE have to be defined.
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  Master  Tool  the  before
mentioned call-back XcpAppl_DaqResumeStore is called by the MainFunction.
void Xcp_MainFunction( void )
(6.2.5)
Annotation for the usage of CANape
Start the resume mode with the menu command Measurement | Start and push the button
“Measure offline” on the dialog box.
3.14.4  Send Queue
The send queue is used to store measurement values until they can be transmitted on the
bus. This  is  required  if  the  used Transport  Layer  does  not  perform  buffering  on  its  own.
Vector Transport Layers do not buffer any data and therefore this feature should be used.
The  send  queue  size  can  be  indirectly  configured  in  the  GenTool.  It  is  defined  by  the
parameter “Memory Size” – the memory size used by the dynamic DAQ lists. As the DAQ
lists are created during runtime by the tool no detailed calculation is possible. A worst case
analysis can be made and the parameter should be chosen such that enough space is left
for the send queue.
Furthermore  the  behaviour  of  the  send  queue  in  case  of  an  overrun  condition  can  be
influenced. There are two possible options:
1.  Throw away oldest element
2016, Vector Informatik GmbH
Version: 2.05.00
21 / 94

Technical Reference XCP Protocol Layer

 The oldest odt in the send queue is discarded and the new measurement value is
inserted. The send queue behaves as a ring buffer.
2.  Throw away latest element
  The  latest  measurement  values  are  discarded.  The  send  queue  behaves  like  a
linear buffer.
The  GenTool  option  “Replace  First  Element”  determines  the  default  behaviour.  The
behaviour
can
be
changed
during
runtime
by
modifying
the
variable
xcp.Daq.SendQueueBehaviour. If this variable is zero linear mode is selected, if this variable
is one the ring buffer mode is selected. This variable can be modified by the Master Tool.

3.14.5  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 the compiler switches XCP_ENBALE_DAQ and XCP_ENABLE_STIM
have to be defined.
3.14.6  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.14.7  Data Acquisition Plug & Play Mechanisms
The XCP Protocol Layer comprises two plug & play mechanisms for data acquisition:
>  general information on the DAQ processor
(enabled with XCP_ENABLE_DAQ_PROCESSOR_INFO)
>  general information on DAQ processing resolution
(enabled with XCP_ENABLE_DAQ_RESOLUTION_INFO)
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
>  information on the time stamp mode
2016, Vector Informatik GmbH
Version: 2.05.00
22 / 94

Technical Reference XCP Protocol Layer

3.14.8  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.
Please refer to chapter 6.8.5 (Configuration of the Event Channel Plug & Play Mechanism)
for details about the configuration of this plug & play mechanism.
Annotation for the usage of CANape
If the plug & play mechanism is not built-in, you must open the dialog XCP Device Setup
with the menu command Tools|Driver parameters. Go to the Event tab. Make one entry for
each event channel. An event channel is an Xcp_Event(x) function call in ECU source
code.
3.14.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-1 Data consistency

2016, Vector Informatik GmbH
Version: 2.05.00
23 / 94

Technical Reference XCP Protocol Layer

3.15  The Online Data Calibration Model
3.15.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 XCP_ENABLE_CALIBRATION_PAGE definition.
The following application callback functions have to be implemented:
uint8 XcpAppl_GetCalPage ( uint8 Xcp_Channel, uint8 segment,
uint8 mode )
(6.5.25)
uint8 XcpAppl_SetCalPage ( uint8 Xcp_Channel, uint8 segment,
uint8 page, uint8 mode )
(6.5.26)

Annotation for the usage 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.15.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
Also refer to chapter 6.8.8 (Configuration of the Page Switching Plug & Play Mechanism)
and to the XCP Specification [II].
The  page  switching  plug  &  play  mechanism  is  enabled  with  the  switch
XCP_ENABLE_PAGE_INFO.
3.15.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 XCP_ENABLE_PAGE_COPY has to be set.
For  calibration  data  page  copying  the  following  application  callback  function  has  to  be
provided by the application:
uint8 XcpAppl_CopyCalPage( uint8 Xcp_Channel, uint8 srcSeg,
uint8 srcPage, uint8 destSeg, uint8
destPage )
(6.5.27)
3.15.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
compiler
switch
XCP_ENABLE_PAGE_FREEZE has to be set.
For freeze mode handling the following application callback functions have to be provided
by the application:
void XcpAppl_SetFreezeMode( uint8 segment, uint8 mode )
(6.5.28)
uint8 XcpAppl_GetFreezeMode( uint8 segment )
(6.5.29)
2016, Vector Informatik GmbH
Version: 2.05.00
24 / 94

Technical Reference XCP Protocol Layer

3.16  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.16.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.
uint8 XcpAppl_ProgramStart( void )
(6.5.17)
uint8 XcpAppl_FlashClear( MTABYTEPTR a, uint32 size )
(6.5.18)
uint8 XcpAppl_FlashProgram( ROMBYTEPTR data,
  MTABYTEPTR a, uint8 size )
(6.5.19)
The flash programming is enabled with the switch XCP_ENABLE_PROGRAM.
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.16.1.1  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:
>  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
Also  refer  to  chapter  6.8.7  (Configuration  of  the  Flash  Programming  Plug  &  Play
Mechanism) and to the XCP Specification [II].
The  flash  programming  plug  &  play  mechanism  is  enabled  with  the  switch
XCP_ENABLE_PROGRAM_INFO.

1 Command not supported
2016, Vector Informatik GmbH
Version: 2.05.00
25 / 94

Technical Reference XCP Protocol Layer

3.16.2  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
uint8 XcpAppl_DisableNormalOperation( MTABYTEPTR a, uint16 size
)
(6.5.14)
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
XCP_ENABLE_BOOTLOADER_DOWNLOAD.
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.3  Flash Programming Write Protection
If  XCP_ENABLE_PROGRAMMING_WRITE_PROTECTION  is  defined  write  access  of  specific
FLASH areas can be checked with the function
uint8 XcpAppl_CheckProgramAccess
  ( MTABYTEPTR addr, uint32 size )
(6.5.10)
It should only be used, if write protection of flash areas is required.
3.17  EEPROM Access
For  uploading  data  from  the  ECU  to  a  MCS  the  XCP  commands  SHORT_UPLOAD  and
UPLOAD  are  used. The  switch  XCP_ENABLE_READ_EEPROM  allows  EEPROM  access  for
these commands.
Before reading from an address it is checked within the following callback function whether
EEPROM or RAM is accessed:
uint8 XcpAppl_CheckReadEEPROM
( MTABYTEPTR addr, uint8 size, BYTEPTR data )
(6.5.5)
The EEPROM access is directly performed within this function.
2016, Vector Informatik GmbH
Version: 2.05.00
26 / 94

Technical Reference XCP Protocol Layer

For  downloading  data  from  the  MCS  to  the  ECU  the  XCP  commands
SHORT_DOWNLOAD, DOWNLOAD, DOWNLOAD_NEXT and DOWNLOAD_MAX can be
used.  The  switch  XCP_ENABLE_WRITE_EEPROM  allows  the  EEPROM  access  for  these
commands.
Also  before  writing  to  an  address  within  the  following  callback  function  it  is  checked
whether EEPROM or RAM is accessed
uint8 XcpAppl_CheckWriteEEPROM
( uint8 Xcp_Channel, MTABYTEPTR addr, uint8 size,
ROMBYTEPTR data )
(6.5.6)
3.18  Parameter Check
As  long  as  the  XCP  Protocol  Layer  is  not  thoroughly  tested  together  with  the  XCP
Transport Layer and the application, the parameter check should be enabled. This is done
by setting the compiler switch XCP_ENABLE_PARAMETER_CHECK.
The parameter check may be removed in order to save code space.
3.19  Performance Optimizations
The XCP Protocol Layer is a platform comprehensive higher software layer and therefore
platform  specific  optimizations  are  not  implemented.  However  it  is  possible  to  apply
platform specific optimizations.
The following memory access functions can be overwritten by either macros or functions:
void Xcp_MemCpy( DAQBYTEPTR dest,
ROMDAQBYTEPTR src, uint16 n )
(6.6.1)
void Xcp_MemSet( BYTEPTR p, uint16 n, uint8 b )
(6.6.2)
static void Xcp_MemClr( BYTEPTR p, uint16 n )
(6.6.3)
It  is  recommended  to  use  DMA  access  as  far  as  possible  for  faster  execution  of  these
services.
3.20  Interrupt Locks / Exclusive Areas
The
functions
Xcp_Event,
Xcp_SendCallBack,
Xcp_MainFunction
and
Xcp_Command are not reentrant. If one of these functions may interrupt one of the others,
they must be protected against each other. See also 3.14.9.
For this purpose the Xcp Protocol Layer makes use of  three exclusive areas. The SchM
must provide the following sections:
  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:
2016, Vector Informatik GmbH
Version: 2.05.00
27 / 94

Technical Reference XCP Protocol Layer

3.20.1  XCP_EXCLUSIVE_AREA_0
Is  used  by  functions  Xcp_SendCallBack,  Xcp_MainFunction  and  Xcp_Command  to
protect these non-reentrant functions.
3.20.2  XCP_EXCLUSIVE_AREA_1
Is used by Xcp_Event during DAQ measurement.
3.20.3  XCP_EXCLUSIVE_AREA_2
Is used by Xcp_Event during STIM measurement.
3.21  Basic Multi Core support
3.21.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 to do
the same running from another core.
With this option disabled, 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 Master Tools perform an optimization by grouping measurement values. This
option  must  be  disabled,  otherwise  they  do  not  represent  unique  data  types
anymore.
3.22  Accessing internal data
The function
void Xcp_GetXcpDataPointer (P2VAR(tXcpData, AUTOMATIC,
XCP_APPL_DATA) *pXcpData )
(6.2.11)
provides  access  to  the  internal  data  structure  of  the  XCP  module.  By  means  of  this
function the internal data can be preset to a certain value. This can be used to process a
measurement  further  that  has  been  started  in  application  mode  but  is  finished  in  boot
mode.
As the whole data can be accessed, it must be handled with care.
3.23  En- / Disabling the XCP module
The variable Xcp_ControlState
can be used to en- or disable the XCP module during run time. Thus the XCP functionality
can be controlled by the application.
Furthermore  two  macros  are  available:  XCP_ACTIVATE  and  XCP_DEACTIVATE.  They
can be used to control the protocol and transport layer together, i.e. enabling  or disabling
2016, Vector Informatik GmbH
Version: 2.05.00
28 / 94

Technical Reference XCP Protocol Layer

them  as  a  whole.  It  is  recommended  to  use  these  macros.  It  is  also  recommended  to
perform a Xcp_Disconnect() API call to bring the Xcp in a save state before it is disabled.
3.24  XCP measurement during the follow up 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:
SessionStatusType Xcp_GetSessionStatus ( void )
(6.3.3)

An example implementation that is called cyclically could look like the following example:

Example
{

  SessionStatusType sessionState;

  sessionState = Xcp_GetSessionStatus();
  if( 0 != (sessionState & SS_CONNECTED) )
  {
  /* Is the xcp actively used? */
  if( 0 != (sessionState & (SS_DAQ | SS_POLLING)) )
  {
  /* Yes, reaload timer */
  swTimer = XCP_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.
2016, Vector Informatik GmbH
Version: 2.05.00
29 / 94

Technical Reference XCP Protocol Layer

4  Integration into the Application
This  chapter  describes  the  steps  for  the  integration  of  the  XCP  Protocol  Layer  into  an
application environment of an ECU.
4.1
Files of XCP Professional
The XCP Protocol Layer consists of the following files.
Files of the XCP Protocol Layer
Xcp.c
XCP Professional source code.
This file must not be changed by the user!

Xcp.h
API of XCP Professional.
This file must not be changed by the user!

_xcp_appl.c  Template that contains the application callback functions of the XCP
Protocol Layer. It is just an example and has to be customized.

v_def.h
General Vector definitions of memory qualifiers and types.
This file must not be changed by the application!

Additionally the following files are generated by the generation tool. If no generation tool or
if CANgen is used the XPC Protocol Layer has to be customized manually. In this case the
following files will be available as template.
Files generated by GENy
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.

Note that all files of XCP Professional must not be changed manually!

4.2
Version changes
Changes and the release versions of the XCP Protocol Layer are listed at the beginning of
the header and source code.

4.3
Compiler Abstraction and Memory Mapping
The  objects  (e.g.  variables,  functions,  constants)  are  declared  by  compiler  independent
definitions  –  the  compiler  abstraction  definitions.  Each  compiler  abstraction  definition  is
assigned to a memory section.
The  following  table  contains  the  memory  section  names  and  the  compiler  abstraction
definitions defined for XCP, and illustrates their assignment among each other.
2016, Vector Informatik GmbH
Version: 2.05.00
30 / 94

Technical Reference XCP Protocol Layer

Compiler Abstraction
Definitions

A

A
T
AT
T

A
T
D

_DA
NS
_DA
L_
Q
A
P
DE
Memory Mapping
T

P
_CO
_DA
_M
_A
_CO
Sections
CP
CP
CP
CP
CP
X
X
X
X
X
XCP_START_SEC_CONST_16BIT


XCP_START_SEC_CONST_8BIT


XCP_START_SEC_VAR_NOINIT_UNSPECIFIED



XCP_START_SEC_VAR_NOINIT_8BIT



XCP_START_SEC_CODE


XCP_START_SEC_VAR_INIT_UNSPECIFIED_SAFE



Table 4-1   Compiler abstraction and memory mapping
Please  see  the  document:  “AUTOSAR_SWS_CompilerAbstraction.pdf”  for  details  about
how to use these definitions.

4.4
Support of Vx1000 Integration
The XcpProf provides basic support for the Vx1000 Hardware which can be enabled in the
configuration tool. If enabled the code size is increased, yet the same API calls as used for
the XcpProf are reused for the Vx which minimizes integration effort.
When  the  option  is  enabled  the  sources  provided  with  your  Vx1000  hardware  must  be
integrated. The  XcpProf  includes  the Vx1000.h header  and makes  use of  the  respective
macros.
If the Vx hardware is attached prior to ECU Initialization the XcpProf itself is deactivated,
hence  no  access  via  the  bus  interface  is  possible  anymore.  If  you  want  to  perform
measurement  &  calibration  via  the  bus  interface  again,  detach  the  Vx  hardware  and
perform an ECU reset.

2016, Vector Informatik GmbH
Version: 2.05.00
31 / 94

Technical Reference XCP Protocol Layer

5 Feature List
This general feature list describes the overall feature set of the XCP Protocol Layer.
Description of the XCP functionality
Functions
Initialization
Initialization
Xcp_Init
ApplXcpInit
Task
Background task
Xcp_MainFunction
XCP Command Processor
Command Processor
Xcp_Command
Transmission and Confirmation of XCP Packets
<Bus>Xcp_Send
Xcp_SendCallBack
Transmission of Response packets
Xcp_SendCrm
Transmission of XCP Packets
XcpAppl_SendStall
<Bus>Xcp_SendFlush
XCP Commands
Get Identification
XcpAppl_GetIdData
Seed & Key
XcpAppl_GetSeed
XcpAppl_Unlock
Short Download
-
Modify Bits
-
Write DAQ Multiple
XcpAppl_CheckDAQAccess
Transport Layer Command
<Bus>Xcp_TLService
Open Command Interface
XcpAppl_OpenCmdIf
User command
XcpAppl_UserService
Data Acquisition (DAQ)
Synchronous Data Acquisition and Stimulation
Xcp_Event
XcpAppl_CheckDAQAccess
DAQ Timestamp
XcpAppl_GetTimestamp
Resume Mode
XcpAppl_DaqResume
XcpAppl_DaqResumeStore
XcpAppl_DaqResumeClear
XcpAppl_CalResumeStore
Online Data Calibration
Calibration page switching
XcpAppl_GetCalPage
XcpAppl_SetCalPage
Copy calibration page
XcpAppl_CopyCalPage
Freeze Mode
XcpAppl_SetFreezeMode
XcpAppl_GetFreezeMode
Boot loader Download
2016, Vector Informatik GmbH
Version: 2.05.00
32 / 94

Technical Reference XCP Protocol Layer

Disable normal operation of ECU
XcpAppl_DisableNormalOper
ation
Start of the boot loader
XcpAppl_StartBootLoader
Flash Programming
Reset of ECU
XcpAppl_Reset
Clear flash memory
XcpAppl_FlashClear
Prepare flash programming
XcpAppl_ProgramStart
Program flash memory
XcpAppl_FlashProgram
Special Features
Interrupt Control
ApplXcpInterruptEnable
ApplXcpInterruptDisable
Event Codes
Xcp_SendEvent
Service Request Packets
Xcp_Putchar
Xcp_Print
Disconnect XCP
Xcp_Disconnect
Pointer conversion
XcpAppl_GetPointer
EEPROM access
XcpAppl_CheckReadEEPROM
XcpAppl_CheckWriteEEPROM
Write protection
XcpAppl_CheckWriteAccess
Read protection
XcpAppl_CheckReadAccess
Overwriteable macros
Xcp_MemCpy
Xcp_MemSet
Xcp_MemClr
Xcp_SendDto
Access to internal data
Xcp_GetXcpDataPointer
En-/Disable Calibration
-
Programming Write Protection
XcpAppl_CheckProgramAcces
s
Session Status
Xcp_GetSessionStatus

2016, Vector Informatik GmbH
Version: 2.05.00
33 / 94

Technical Reference XCP Protocol Layer

6  Description of the API
The XCP Protocol Layer application programming interface consists of services, which are
realized  by  function  calls.  These  services  are  called  wherever  they  are  required.  They
transfer  information  to-  or  take  over  information  from  the  XCP  Protocol  Layer.  This
information  is  stored  in  the  XCP  Protocol  Layer  until  it  is  not  required  anymore,
respectively until it is changed by other operations.
Examples  for  calling  the  services  of  the  XCP  Protocol  Layer  can  be  found  in  the
description of the services.

6.1
Version of the Source Code
The  source  code  version  of  the  XCP  Protocol  Layer  is  provided  by  three  BCD  coded
constants:
CONST(uint8, XCP_CONST) kXcpMainVersion =
(uint8)(CP_XCP_VERSION >> 8);
CONST(uint8, XCP_CONST)  kXcpSubVersion =
(uint8)(CP_XCP_ VERSION);
CONST(uint8, XCP_CONST) kXcpReleaseVersion =
(uint8)(CP_XCP_RELEASE_VERSION);

Example
Version 1.00.00 is registered as:

kXcpMainVersion = 0x01;
kXcpSubVersion = 0x00;
kXcpReleaseVersion = 0x00;

These constants are declared as external and can be read by the application at any time.
Alternatively the Version can be obtained with the GetVersionInfo API if enabled:
void  Xcp_GetVersionInfo (P2VAR(Std_VersionInfoType, AUTOMATIC,
XCP_APPL_DATA) XcpVerInfoPtr)
(6.2.12)

2016, Vector Informatik GmbH
Version: 2.05.00
34 / 94

Technical Reference XCP Protocol Layer

6.2
XCP Services called by the Application
The following XCP services that are called by the application are all not reentrant. If they
are called within interrupt context at least the CAN-Interrupts have to be disabled.

6.2.1
Xcp_InitMemory: Initialization of the XCP Protocol Layer Memory
Xcp_InitMemory
Prototype
Single Channel
Single Receive Channel  void Xcp_InitMemory ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
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
>  Call context: Task and interrupt level
>  This service function has to be called after the initialization of XCP Transport Layer.
>  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
before.

6.2.2
Xcp_Init: Initialization of the XCP Protocol Layer
Xcp_Init
Prototype
Single Channel
Single Receive Channel  void Xcp_Init  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
2016, Vector Informatik GmbH
Version: 2.05.00
35 / 94

Technical Reference XCP Protocol Layer

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.
Particularities and Limitations
>  Call context: Task and interrupt level
>  This service function has to be called after the initialization of XCP Transport Layer.
>  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
before.

6.2.3
Xcp_Event: Handling of a data acquisition event channel
Xcp_Event
Prototype
Single Channel
Single Receive Channel  uint8 Xcp_Event  ( uint8 event )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
event
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_NO :    Inactive (DAQ not running, Event not configured)
XCP_EVENT_DAQ :   DAQ active */
XCP_EVENT_DAQ_OVERRUN :  DAQ queue overflow
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 (0); /* 10ms cycle */
xcp_Event (1); /* 100ms cycle */
xcp_Event (2); /* Crank synchronous cycle */
2016, Vector Informatik GmbH
Version: 2.05.00
36 / 94

Technical Reference XCP Protocol Layer

Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  Data acquisition has to be enabled: XCP_ENABLE_DAQ has to be defined
>  Call context: Task and interrupt level (not reentrant)

6.2.4
Xcp_StimEventStatus: Check data stimulation events
Xcp_StimEventStatus
Prototype
Single Channel
Single Receive Channel  uint8 Xcp_StimEventStatus  ( uint8 event, uint8 action )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
event
Event channel number
action
STIM_CHECK_ODT_BUFFER : check ODT buffer
STIM_RESET_ODT_BUFFER : reset ODT buffer
Return code
uint8
0 : stimulation data not available
1 : new stimulation data is available
Functional Description
Check if data stimulation (STIM) event can perform or delete the buffers.

Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  Data acquisition has to be enabled: XCP_ENABLE_STIM has to be defined
>  Call context: Task and interrupt level (not reentrant)

6.2.5
Xcp_MainFunction: Background calculation of checksum
Xcp_MainFunction
Prototype
Single Channel
Single Receive Channel  void Xcp_MainFunction  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
2016, Vector Informatik GmbH
Version: 2.05.00
37 / 94

Technical Reference XCP Protocol Layer

Return code
uint8
0 : background calculation finished
1 : background calculation is still in progress
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 Xcp_MainFunction.
Therefore Xcp_MainFunction should be called periodically whenever the ECU’s CPU is idle.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly
>  Call context: Task level

6.2.6
Xcp_SendEvent: Transmission of event codes
Xcp_SendEvent
Prototype
Single Channel
Single Receive Channel  void Xcp_SendEvent  ( uint8 Xcp_Channel, uint8 evc, ROMBYTEPTR
c, uint8 len )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
evc
event code
c
pointer to event data
len
event data length
Return code
-
-
Functional Description
Transmission of event codes via event packets (EV).
Please refer to chapter 3.10 Event Codes.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  Data acquisition has to be enabled: XCP_ENABLE_SEND_EVENT has to be defined
>  Call context: Task and interrupt level

6.2.7
Xcp_Putchar: Put a char into a service request packet
Xcp_Putchar
Prototype
Single Channel
2016, Vector Informatik GmbH
Version: 2.05.00
38 / 94

Technical Reference XCP Protocol Layer

Single Receive Channel  void Xcp_Putchar  ( uint8 Xcp_Channel, const uint8 c )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
c
character that is put in a service request packet
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 out in the service request packet.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  The switch XCP_ENABLE_SERV_TEXT_PUTCHAR has to be defined
>  Call context: Task and interrupt level (not reentrant)

6.2.8
Xcp_Print: Transmission of a service request packet
Xcp_Print
Prototype
Single Channel
Single Receive Channel  void Xcp_Print  ( uint8 Xcp_Channel, P2CONST(uint8, AUTOMATIC,
XCP_APPL_DATA) str )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
str
pointer to a string that is terminated by 0x00
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
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  The switch XCP_ENABLE_SERV_TEXT_PRINT has to be defined
>  Call context: Task and interrupt level (not reentrant)

2016, Vector Informatik GmbH
Version: 2.05.00
39 / 94

Technical Reference XCP Protocol Layer

6.2.9
Xcp_Disconnect: Disconnect from XCP master
Xcp_Disconnect
Prototype
Single Channel
Single Receive Channel  void Xcp_Disconnect  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
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
>  The XCP Protocol Layer has been initialized correctly and XCP is in connected state.
>  Call context: Task and interrupt level (not reentrant)

6.2.10  Xcp_SendCrm: Transmit response or error packet
Xcp_SendCrm
Prototype
Single Channel
Single Receive Channel  void Xcp_SendCrm  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
Functional Description
Transmission of a command response packet (RES), or error packet (ERR) if no other packet is
pending.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly, XCP is in connected state and a
command packet (CMD) has been received.
>  Call context: Task and interrupt level (not reentrant)
2016, Vector Informatik GmbH
Version: 2.05.00
40 / 94

Technical Reference XCP Protocol Layer

6.2.11  Xcp_GetXcpDataPointer: Request internal data pointer
Xcp_GetXcpDataPointer
Prototype
Single Channel
Single Receive Channel  void Xcp_GetXcpDataPointer ( tXcpData ** pXcpData )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
pXcpData
pointer to store the pointer to the module internal data
Return code
-
-
Functional Description
With this function the pointer to the module internal data can be received. With this pointer the
internal variable can be set to a certain configuration (e.g. after entering a boot mode where no
connection shall be established again). As this pointer allows the access to all internal data it must
be handled with care.
Particularities and Limitations
>  The switch XCP_ENABLE_GET_XCP_DATA_POINTER has to be defined

6.2.12  Xcp_GetVersionInfo: Request module version information
Xcp_GetVersionInfo
Prototype
Single Channel
Single Receive Channel  void Xcp_GetVersionInfo (P2VAR(Std_VersionInfoType, AUTOMATIC,
XCP_APPL_DATA) XcpVerInfoPtr)
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
XcpVerInfoPtr
Pointer to the location where the Version information shall be stored.
Return code
-
-
Functional Description
Xcp_GetVersionInfo() returns version information, vendor ID and AUTOSAR module ID of the
component. The versions are BCD-coded.
2016, Vector Informatik GmbH
Version: 2.05.00
41 / 94

Technical Reference XCP Protocol Layer

Particularities and Limitations
  The switch XCP_ENABLE_VERSION_INFO_API has to be defined
>  Call context: task level (Re-entrant)

6.2.13  Xcp_ModifyProtectionStatus: Influence seed&key behaviour
Xcp_ModifyProtectionStatus
Prototype
Single Channel
Single Receive Channel  void Xcp_ModifyProtectionStatus ( uint8 Xcp_Channel, uint8
andState, uint8 orState )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
andState
The following flags: RM_CAL_PAG, RM_DAQ, RM_STIM and
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: RM_CAL_PAG, RM_DAQ, RM_STIM and
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
  The switch XCP_ENABLE_VERSION_INFO_API has to be defined
>  Call context: task level (Re-entrant)

6.3
XCP Protocol Layer Functions, called by the XCP Transport Layer
For  using  the  following  functions  there  are  some  limitations  which  have  to  be  taken  into
consideration – especially when using an operation system like, i.e. OSEK OS:
>  The ISR level for the transmission and reception of CAN messages has to be the same.
>  Interrupts must be mutually
>  No nested calls of these functions are allowed. (i.e. these functions are not reentrant)
2016, Vector Informatik GmbH
Version: 2.05.00
42 / 94

Technical Reference XCP Protocol Layer

All functions provided by the application must match the required interfaces. This can be
ensured by including the header file in the modules which provide the required functions. If
these interfaces do not match unexpected run-time behavior may occur.

6.3.1
Xcp_Command: Evaluation of XCP packets and command interpreter
Xcp_Command
Prototype
Single Channel
Single Receive Channel  void Xcp_Command  ( uint8 Xcp_Channel, P2CONST(uint32,
AUTOMATIC, XCP_APPL_DATA) pCommand )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
pCommand
Pointer to the XCP protocol message, which must be extracted from
the XCP protocol packet.
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
>  The XCP Protocol Layer has to be initialized correctly.
>  Call context: Task and interrupt level (not reentrant)

6.3.2
Xcp_SendCallBack: Confirmation of the successful transmission of a XCP
packet
Xcp_SendCallBack
Prototype
Single Channel
Single Receive Channel  uint8 Xcp_SendCallBack  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
2016, Vector Informatik GmbH
Version: 2.05.00
43 / 94

Technical Reference XCP Protocol Layer

Return code
uint8
0 :  if the XCP Protocol Layer is idle (no transmit messages are
pending)
Functional Description
The XCP Protocol Layer does not call <Bus>Xcp_Send again, until Xcp_SendCallBack has
confirmed the successful transmission of the previous message. Xcp_SendCallBack transmits
pending data acquisition messages by calling <Bus>Xcp_Send again.
Note that if Xcp_SendCallBack is called from inside <Bus>Xcp_Send a recursion occurs, which
assumes enough space on the call stack.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly.
>  Call context: Task and interrupt level (not reentrant)

6.3.3
Xcp_GetSessionStatus: Get session state of XCP
Xcp_GetSessionStatus
Prototype
Single Channel
Single Receive Channel
SessionStatusType Xcp_GetSessionStatus  ( uint8
Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
SS_CONNECTED
XCP is connected
SS_DAQ
DAQ measurement is running
SS_POLLING
Polling is running (depending on polling rate this flag is not
always set)
Functional Description
This service can be used to get the session state of the XCP Protocol Layer. The session state is
returned as bit mask where the individual bits can be tested.
E.g. this service is used by the XCP on CAN Transport Layer to determine the connection state in
case multiple CAN channels are used and can be used by the application to prevent an ECU
shutdown.
Particularities and Limitations
>  The XCP Protocol Layer has to be initialized correctly.
>  Call context: Task and interrupt level (not reentrant)
>  Enabled/Disabled by XCP_xxx_GET_SESSION_STATUS_API

2016, Vector Informatik GmbH
Version: 2.05.00
44 / 94

Technical Reference XCP Protocol Layer

6.3.4
Xcp_SetActiveTl: Set the active Transport Layer
Xcp_SetActiveTl
Prototype
Single Channel
Single Receive Channel  void Xcp_SetActiveTl  ( uint8 Xcp_Channel, uint8 MaxCto, uint8
MaxDto, uint8 ActiveTl )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
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
Set the active Transport Layer the XCP Protocol Layer uses.
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
>  The XCP Protocol Layer has to be initialized correctly.
>  Call context: Task and interrupt level (not reentrant)

6.3.5
Xcp_GetActiveTl: Get the currently active Transport Layer
Xcp_GetActiveTl
Prototype
Single Channel
Single Receive Channel  uint8 Xcp_GetActiveTl  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
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
2016, Vector Informatik GmbH
Version: 2.05.00
45 / 94

Technical Reference XCP Protocol Layer

Functional Description
Get the active Transport Layer the XCP Protocol Layer uses.
This service is used by the XCP Transport Layers to get the currently active Transport Layer used
by the XCP Protocol Layer
Particularities and Limitations
>  The XCP Protocol Layer has to be initialized correctly.
>  Call context: Task and interrupt level (not reentrant)

6.4
XCP Transport Layer 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
component’s header.

6.4.1
<Bus>Xcp_Send: Request for the transmission of a DTO or CTO message
<Bus>Xcp_Send
Prototype
Single Channel
Single Receive Channel  void <Bus>Xcp_Send ( uint8 Xcp_Channel, uint8 len, ROMBYTEPTR
msg )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
len
Length of message data
msg
Pointer to message
Return code
uint8
0 : if the XCP Protocol Layer is idle (no transmit messages are
pending)
Functional Description
Requests for the transmission of a command transfer object (CTO) or data transfer object (DTO).
Xcp_SendCallBack must be called after the successful transmission of any XCP message. The
XCP Protocol Layer will not request further transmissions, until Xcp_SendCallBack has been
called.
Particularities and Limitations
>  Call context: Task and interrupt level (not reentrant)
>  <Bus>Xcp_Send is not defined as macro

6.4.2
<Bus>Xcp_SendFlush: Flush transmit buffer
<Bus>Xcp_SendFlush
2016, Vector Informatik GmbH
Version: 2.05.00
46 / 94

Technical Reference XCP Protocol Layer

Prototype
Single Channel
Single Receive Channel  void <Bus>Xcp_SendFlush  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
Functional Description
Flush the transmit buffer.
Particularities and Limitations
-

6.4.3
XcpAppl_InterruptEnable: Enable interrupts
XcpAppl_InterruptEnable
Prototype
Single Channel
Single Receive Channel  void XcpAppl_InterruptEnable  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
Functional Description
Enabling of the global interrupts.

Particularities and Limitations
>  XCP is initialized correctly
>  Call context: Task and interrupt level
>  This function is reentrant!
>  The function XcpAppl_InterruptEnable can be overwritten by the macro
XcpAppl_InterruptEnable.

2016, Vector Informatik GmbH
Version: 2.05.00
47 / 94

Technical Reference XCP Protocol Layer

6.4.4
XcpAppl_InterruptDisable: Disable interrupts
XcpAppl_InterruptDisable
Prototype
Single Channel
Single Receive Channel  void XcpAppl_InterruptDisable  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
Functional Description
Disabling of the global interrupts.

Particularities and Limitations
>  XCP is initialized correctly
>  Call context: Task and interrupt level
>  This function is reentrant!
>  The function XcpAppl_InterruptDisable can be overwritten by the macro
XcpAppl_InterruptDisable.

6.4.5
<Bus>Xcp_TLService: Transport Layer specific commands
<Bus>Xcp_TLService
Prototype
Single Channel
Single Receive Channel  uint8 <Bus>Xcp_TLService  ( uint8 Xcp_Channel, ROMBYTEPTR
pCmd )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
pCmd
Pointer to COMMAND that has been received by the XCP Slave.
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
2016, Vector Informatik GmbH
Version: 2.05.00
48 / 94

Technical Reference XCP Protocol Layer

Functional Description
Transport Layer specific command that is processed within the XCP Transport Layer.

Particularities and Limitations
>  XCP is initialized correctly
>  Call context: Task and interrupt level
>  The switch XCP_ENABLE_TL_COMMAND has to be defined

6.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 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.
6.5.1
XcpAppl_GetPointer: Pointer conversion
XcpAppl_GetPointer
Prototype
Single Channel
Single Receive Channel  MTABYTEPTR XcpAppl_GetPointer  ( uint8 addr_ext, uint32 addr )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
addr_ext
8 bit address extension
addr
32 bit address
Return code
MTABYTEPTR
Pointer to the address specified by the parameters
2016, Vector Informatik GmbH
Version: 2.05.00
49 / 94

Technical Reference XCP Protocol Layer

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 for memory transfers like DOWNLOAD and UPLOAD.
Example:
The following code shows an example of a typical implementation of XcpAppl_GetPointer:
MTABYTEPTR XcpAppl_GetPointer( uint8 addr_ext, uint32 addr )
{
  return (MTABYTEPTR)addr;
}
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  This function can be overwritten by defining XcpAppl_GetPointer as macro.

6.5.2
XcpAppl_GetIdData: Get Identification
XcpAppl_GetIdData
Prototype
Single Channel
Single Receive Channel  uint32 XcpAppl_GetIdData  ( MTABYTEPTR *pData, uint8 id )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
pData
Returns a pointer to a pointer of MAP file names
id
Identification of the requested information/identification
Return code
uint32
length of the MAP file names
Functional Description
Returns a pointer to a pointer of MAP file names.
Refer to chapter 3.4.2 (XCP Generic Identification).
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_GET_ID_GENERIC has to be defined

6.5.3
XcpAppl_GetSeed: Generate a seed
XcpAppl_GetSeed
2016, Vector Informatik GmbH
Version: 2.05.00
50 / 94

Technical Reference XCP Protocol Layer

Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_GetSeed  ( uint8 Xcp_Channel, const uint8 resource,
P2VAR(uint8, AUTOMATIC, XCP_APPL_DATA) seed )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
Resource
Resource for which the seed has to be generated
XCP Professional and XPC Basic
RM_CAL_PAG :   to unlock the resource calibration/paging
RM_DAQ :
to unlock the resource data acquisition
XCP Professional only
RM_STIM :
to unlock the resource stimulation
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
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_SEED_KEY has to be defined

6.5.4
XcpAppl_Unlock: Valid key and unlock resource
XcpAppl_Unlock
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_Unlock  ( uint8 Xcp_Channel, P2CONST(uint8,
AUTOMATIC, XCP_APPL_DATA) key, const uint8 length )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
key
Pointer to the key.
2016, Vector Informatik GmbH
Version: 2.05.00
51 / 94

Technical Reference XCP Protocol Layer

length
Length of the key.
Return code
uint8
XCP Professional and XPC Basic
0 :
if the key is not valid
RM_CAL_PAG :   to unlock the resource calibration/paging
RM_DAQ :
to unlock the resource data acquisition
XCP Professional only
RM_STIM :
to unlock the resource stimulation
RM_PGM :
to unlock the resource programming
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
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_SEED_KEY has to be defined

6.5.5
XcpAppl_CheckReadEEPROM: Check read access from EEPROM
XcpAppl_CheckReadEEPROM
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CheckReadEEPROM  ( MTABYTEPTR addr,

uint8 size,

BYTEPTR data )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
addr
Address that is checked
size
Number of bytes
data
Pointer to data
(if the address is on the EEPROM the data is written here)
Return code
uint8
XCP_CMD_OK :
EEPROM read
XCP_CMD_DENIED :  This is not EEPROM
XCP_CMD_PENDING :  EEPROM read in progress, call Xcp_SendCrm

when done
Functional Description
Checks whether the address lies within the EEPROM memory or in the RAM area.
If the area is within the EEPROM area size data byte are read from addr and written to data.
2016, Vector Informatik GmbH
Version: 2.05.00
52 / 94

Technical Reference XCP Protocol Layer

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_READ_EEPROM has to be defined

6.5.6
XcpAppl_CheckWriteEEPROM: Check write access to the EEPROM
XcpAppl_CheckWriteEEPROM
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CheckWriteEEPROM  ( uint8 Xcp_Channel,
MTABYTEPTR addr, uint8 size,
ROMBYTEPTR data)
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
addr
Address that is checked
size
number of bytes
data
pointer to data
(if addr is on the EEPROM this data is written to addr)
Return code
uint8
XCP_CMD_OK :
EEPROM written
XCP_CMD_DENIED :  This is not EEPROM
XCP_CMD_PENDING :  EEPROM write in progress, call XcpSendCrm

when done
Functional Description
Checks whether the address addr is within the EEPROM memory. If not, the function returns
XCP_CMD_DENIED. If it lies within, EEPROM programming is performed. The function may return
during programming with XCP_CMD_PENDING or may wait until the programming sequence has
finished and then returns with XCP_CMD_OK.
If the programming sequence has finished, the Xcp_SendCrm function must be called.
Xcp_SendCrm is an internal function of the XCP Protocol Layer.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_WRITE_EEPROM has to be defined

6.5.7
XcpAppl_CheckWriteAccess: Check address for valid write access
XcpAppl_CheckWriteAccess
Prototype
Single Channel
2016, Vector Informatik GmbH
Version: 2.05.00
53 / 94

Technical Reference XCP Protocol Layer

Single Receive Channel  uint8 XcpAppl_CheckWriteAccess  ( MTABYTEPTR address,

uint8 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
address
address
size
number of bytes
Return code
uint8
XCP_CMD_DENIED :   if access is denied
XCP_CMD_OK :
if access is granted
Functional Description
Check addresses for valid write access. A write access is enabled with the
XCP_ENABLE_WRITE_PROTECTION, it should be only used, if write protection of memory
areas is required
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_WRITE_PROTECTION has to be defined
>  Can be overwritten by the macro XcpAppl_CheckWriteAccess

6.5.8
XcpAppl_CheckReadAccess: Check address for valid read access
XcpAppl_CheckReadAccess
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CheckReadAccess  ( MTABYTEPTR address,

uint8 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
address
address
size
number of bytes
Return code
uint8
XCP_CMD_DENIED :  if access is denied
XCP_CMD_OK :
if access is granted
Functional Description
Check addresses for valid read access. A read access is enabled with the
XCP_ENABLE_READ_PROTECTION, it should be only used, if read protection of memory areas
is required
2016, Vector Informatik GmbH
Version: 2.05.00
54 / 94

Technical Reference XCP Protocol Layer

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_READ_PROTECTION has to be defined
>  Can be overwritten by the macro XcpAppl_CheckReadAccess

6.5.9
XcpAppl_CheckDAQAccess: Check address for valid read or write access
XcpAppl_CheckDAQAccess
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CheckDAQAccess  ( DAQBYTEPTR address,

uint8 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
address
address
size
number of bytes
Return code
uint8
XCP_CMD_DENIED :  if access is denied
XCP_CMD_OK :
if access is granted
Functional Description
Check addresses for valid read or write access. This callback is called when a WRITE_DAQ
command is performed. Therefore it is not possible to know whether this is a read or write
access. Out of this reason this unified function is called.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_READ_PROTECTION or XCP_ENABLE_WRITE_PROTECTION has to
be defined

6.5.10  XcpAppl_CheckProgramAccess: Check address for valid write access
XcpAppl_CheckProgramAccess
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CheckProgramAccess  ( MTABYTEPTR address,

      uint32 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
address
address
2016, Vector Informatik GmbH
Version: 2.05.00
55 / 94

Technical Reference XCP Protocol Layer

size
number of bytes
Return code
uint8
XCP_CMD_DENIED :  if access is denied
XCP_CMD_OK :
if access is granted
Functional Description
Check addresses for valid write access. A write access is enabled with the
XCP_ENABLE_PROGRAMMING_WRITE_PROTECTION, it should be only used, if write protection
of memory areas is required
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_PROGRAMMING_WRITE_PROTECTION has to be defined
>  Can be overwritten by the macro XcpAppl_CheckWriteAccess

6.5.11  XcpAppl_UserService: User defined command
XcpAppl_UserService
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_UserService ( uint8 Xcp_Channel, ROMBYTEPTR
pCmd )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
pCmd
Pointer to XCP command packet
Return code
uint8
XCP_CMD_OK :
positive response
XCP_CMD_PENDING :  Call XcpSendCrm() when done
XCP_CMD_SYNTAX :  negative response
Functional Description
Application specific user command.
Please refer to 3.12 User Defined Command.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_USER_COMMAND has to be defined

6.5.12  XcpAppl_OpenCmdIf: XCP command extension interface
XcpAppl_OpenCmdIf
Prototype
2016, Vector Informatik GmbH
Version: 2.05.00
56 / 94

Technical Reference XCP Protocol Layer

Single Channel
Single Receive Channel  uint8 XcpAppl_OpenCmdIf  ( uint8 Xcp_Channel, ROMBYTEPTR
pCmd
BYTEPTR pRes, BYTEPTR pLength )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
pCmd
Pointer to COMMAND that has been received by the XCP Slave.
pRes
Pointer to response buffer that will be sent by the XCP Slave.
pLength
Number of bytes that will be sent in the response.
Return code
uint8
XCP_CMD_OK :         Done
XCP_CMD_PENDING :   Call Xcp_SendCrm() when done
XCP_CMD_ERROR :      Error
Functional Description
Call back that can be used to extend the XCP commands of the XCP protocol layer.

Particularities and Limitations
>  XCP is initialized correctly
>  Call context: Task and interrupt level
>  The switch XCP_ENABLE_OPENCMDIF has to be defined

6.5.13  XcpAppl_SendStall: Resolve a transmit stall condition
XcpAppl_SendStall
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_SendStall  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
uint8
0 :     if not successful
> 0 :  successful
Functional Description
Resolve a transmit stall condition in Xcp_Putchar or Xcp_SendEvent.
2016, Vector Informatik GmbH
Version: 2.05.00
57 / 94

Technical Reference XCP Protocol Layer

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_SEND_EVENT or XCP_ENABLE_SERV_TEXT_PUTCHAR and
XCP_ENABLE_SEND_QUEUE are defined
>  The function can be overwritten by the macro XcpAppl_SendStall()

6.5.14  XcpAppl_DisableNormalOperation: Disable normal operation of the ECU
XcpAppl_DisableNormalOperation
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_DisableNormalOperation  ( MTABYTEPTR a,

uint16 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
a
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
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
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_BOOTLOADER_DOWNLAOD has to be defined

6.5.15  XcpAppl_StartBootLoader: Start of boot loader
XcpAppl_StartBootLoader
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_StartBootLoader  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
2016, Vector Informatik GmbH
Version: 2.05.00
58 / 94

Technical Reference XCP Protocol Layer

Return code
uint8
This function should not return.
XCP_CMD_OK :
positive response
XCP_CMD_BUSY :  negative response
Functional Description
Start of the boot loader.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_BOOTLOADER_DOWNLAOD has to be defined

6.5.16  XcpAppl_Reset: Perform ECU reset
XcpAppl_Reset
Prototype
Single Channel
Single Receive Channel  void XcpAppl_Reset  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
-
-
Functional Description
Perform an ECU reset after reprogramming of the application.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_PROGRAM has to be defined

6.5.17  XcpAppl_ProgramStart: Prepare flash programming
XcpAppl_ProgramStart
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_ProgramStart  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
2016, Vector Informatik GmbH
Version: 2.05.00
59 / 94

Technical Reference XCP Protocol Layer

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
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_PROGRAM has to be defined

6.5.18  XcpAppl_FlashClear: Clear flash memory
XcpAppl_FlashClear
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_FlashClear  ( MTABYTEPTR address,

uint32 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
address
Address
size
Size
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.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_PROGRAM has to be defined

6.5.19  XcpAppl_FlashProgram: Program flash memory
XcpAppl_FlashProgram
2016, Vector Informatik GmbH
Version: 2.05.00
60 / 94

Technical Reference XCP Protocol Layer

Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_FlashProgram  ( ROMBYTEPTR data,

MTABYTEPTR address,

uint8 size )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
data
Pointer to data
address
Address
size
Size
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
>  XCP is initialized correctly and in connected state
>  The switch XCP_ENABLE_PROGRAM has to be defined

6.5.20  XcpAppl_DaqResume: Resume automatic data transfer
XcpAppl_DaqResume
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_DaqResume  ( uint8 Xcp_Channel, tXcpDaq * daq )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
daq
Pointer to dynamic DAQ list structure
Return code
uint8
0 :
No resume mode data available
>0 :
Resume mode initialization ok
2016, Vector Informatik GmbH
Version: 2.05.00
61 / 94

Technical Reference XCP Protocol Layer

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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_RESUME are defined

6.5.21  XcpAppl_DaqResumeStore: Store DAQ lists for resume mode
XcpAppl_DaqResumeStore
Prototype
Single Channel
Single Receive Channel  void XcpAppl_DaqResumeStore  (uint8 Xcp_Channel,
P2CONST(tXcpDaq, AUTOMATIC, XCP_APPL_DATA) daq , uint16
size, uint8 measurementStart)
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
daq
Pointer to dynamic DAQ list structure.
size
Size of DAQ data that needs to be stored
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.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_RESUME are defined

6.5.22  XcpAppl_DaqResumeClear: Clear stored DAQ lists
XcpAppl_DaqResumeClear
Prototype
Single Channel
2016, Vector Informatik GmbH
Version: 2.05.00
62 / 94

Technical Reference XCP Protocol Layer

Single Receive Channel  void XcpAppl_DaqResumeClear  ( uint8 Xcp_Channel  )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_RESUME are defined

6.5.23  XcpAppl_CalResumeStore: Store Calibration data for resume mode
XcpAppl_CalResumeStore
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CalResumeStore  ( uint8 Xcp_Channel )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
Return code
uint8
0 :    Storing not yet finished (STORE_CAL_REQ flag kept)
>0 :  Storing finished (STORE_CAL_REQ flag cleared)
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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_RESUME are defined

2016, Vector Informatik GmbH
Version: 2.05.00
63 / 94

Technical Reference XCP Protocol Layer

6.5.24  XcpAppl_GetTimestamp: Returns the current timestamp
XcpAppl_GetTimestamp
Prototype
Single Channel
Single Receive Channel  XcpDaqTimestampType XcpAppl_GetTimestamp  ( void )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
-
-
Return code
XcpDaqTimestampType timestamp
Functional Description
Returns the current timestamp.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_TIMESTAMP are defined
>  The parameter kXcpDaqTimestampSize defines the timestamp size. It can either be
DAQ_TIMESTAMP_BYTE, DAQ_TIMESTAMP_WORD, DAQ_TIMESTAMP_DWORD

6.5.25  XcpAppl_GetCalPage: Get calibration page
XcpAppl_GetCalPage
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_GetCalPage  ( uint8 Xcp_Channel, uint8 segment,
uint8 mode )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
segment
Logical data segment number
mode
Access mode
The access mode can be one of the following values:
CAL_ECU : ECU access
CAL_XCP : XCP access
Return code
uint8
Logical data page number
2016, Vector Informatik GmbH
Version: 2.05.00
64 / 94

Technical Reference XCP Protocol Layer

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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_TIMESTAMP are defined

6.5.26  XcpAppl_SetCalPage: Set calibration page
XcpAppl_SetCalPage
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_SetCalPage  ( uint8 Xcp_Channel, uint8 segment,

uint8 page, uint8 mode )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
segment
Logical data segment number
Page
Logical data page number
mode
Access mode
CAL_ECU : the given page will be used by the slave device application
CAL_XCP : 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
CRC_OUT_OF_RANGE : segment out of range
( only one segment supported)
CRC_PAGE_NOT_VALID : Selected page not available
CRC_PAGE_MODE_NOT_VALID : Selected page mode not available
Functional Description
Set the access mode for a calibration data segment.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_DAQ and XCP_ENABLE_DAQ_TIMESTAMP are defined

2016, Vector Informatik GmbH
Version: 2.05.00
65 / 94

Technical Reference XCP Protocol Layer

6.5.27  XcpAppl_CopyCalPage: Copying of calibration data pages
XcpAppl_CopyCalPage
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_CopyCalPage  ( uint8 Xcp_Channel, uint8 srcSeg,
                            uint8 srcPage, uint8 destSeg, uint8 destPage )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
srcSeg
Source segment
srcPage
Source page
destSeg
Destination segment
destPage
Destination page
Return code
uint8
XCP_CMD_OK : Operation completed successfully
XCP_CMD_PENDING : Call XcpSendCrm() when done
CRC_PAGE_NOT_VALID : Page not available
CRC_SEGMENT_NOT_VALID :  Segment not available
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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_PAGE_COPY and XCP_ENABLE_DAQ_TIMEOUT are defined

6.5.28  XcpAppl_SetFreezeMode: Setting the freeze mode of a segment
XcpAppl_SetFreezeMode
Prototype
Single Channel
Single Receive Channel  void XcpAppl_SetFreezeMode ( uint8 segment, uint8 mode )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
segment
Segment to set freeze mode
2016, Vector Informatik GmbH
Version: 2.05.00
66 / 94

Technical Reference XCP Protocol Layer

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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_PAGE_FREEZE is defined

6.5.29  XcpAppl_GetFreezeMode: Reading the freeze mode of a segment
XcpAppl_GetFreezeMode
Prototype
Single Channel
Single Receive Channel  uint8 XcpAppl_GetFreezeMode ( uint8 segment )
Multi Channel
Indexed
not supported
Code replicated
not supported
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
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_PAGE_FREEZE is defined

6.5.30  XcpAppl_Read: Read a single byte from memory
XcpAppl_Read
Prototype
Single Channel
Single Channel
uint8 XcpAppl_Read  ( uint32 addr )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
addr
32 Bit address
2016, Vector Informatik GmbH
Version: 2.05.00
67 / 94

Technical Reference XCP Protocol Layer

Return code
uint8
Pointer to the address specified by the parameters
Functional Description
Read a single byte from the memory.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_MEM_ACCESS_BY_APPL is defined

6.5.31  XcpAppl_Write: Write a single byte to RAM
XcpAppl_Write
Prototype
Single Channel
Single Channel
void XcpAppl_Write  ( uint32 addr, uint8 data )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
addr
32 Bit address
data
data to be written to memory
Return code
-
-
Functional Description
Write a single byte to RAM.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_MEM_ACCESS_BY_APPL is defined

6.5.32  XcpAppl_MeasurementRead: Read multiple bytes from memory
XcpAppl_MeasurementRead
Prototype
Single Channel
Single Channel
uint8 XcpAppl_MeasurementRead  ( P2VAR(void, AUTOMATIC,
XCP_APPL_DATA) dst, P2CONST(void, AUTOMATIC,
XCP_APPL_DATA) src, uint8 len )
Multi Channel
Indexed
not supported
Code replicated
not supported
2016, Vector Informatik GmbH
Version: 2.05.00
68 / 94

Technical Reference XCP Protocol Layer

Parameter
dst
Address pointer
len
Number of bytes to read
src
Pointer to data
Return code
uint8
XCP_CMD_OK if read operation was successful otherwise return
protection code, e.g. XCP_CMD_DENIED
Functional Description
Read multiple bytes from memory. This service is used in MultiCore use case for type safe read
operation.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_CALIBRATION_MEM_ACCESS_BY_APPL or
XCP_ENABLE_TYPESAVE_COPY is defined

6.5.33  XcpAppl_CalibrationWrite: Write multiple bytes to memory
XcpAppl_CalibrationWrite
Prototype
Single Channel
Single Channel
uint8 XcpAppl_CalibrationWrite  ( P2VAR(void, AUTOMATIC,
XCP_APPL_DATA) dst, P2CONST(void, AUTOMATIC,
XCP_APPL_DATA) src, uint8 len )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
dst
Address pointer
len
Number of bytes to write
src
Pointer to data
Return code
uint8
Protection code, XCP_CMD_OK if write operation was successful
Functional Description
Write multiple bytes to memory. This service is used in MultiCore use case for type safe write
operation.

Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_CALIBRATION_MEM_ACCESS_BY_APPL or
XCP_ENABLE_TYPESAVE_COPY is defined
2016, Vector Informatik GmbH
Version: 2.05.00
69 / 94

Technical Reference XCP Protocol Layer

6.5.34  XcpAppl_ReadChecksumValue: Read checksum value
XcpAppl_ReadChecksumValue
Prototype
Single Channel
Single Channel
tXcpChecksumAddType XcpAppl_ReadChecksumValue  ( uint32
addr )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Addr
Address pointer
Return code
tXcpChecksumAddType New value for checksum calculation
Functional Description
This function is used to access checksum values when no direct access to memory is allowed.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_CALIBRATION_MEM_ACCESS_BY_APPL is defined

6.5.35  XcpAppl_CalculateChecksum: Custom checksum calculation
XcpAppl_CalculateChecksum
Prototype
Single Channel
Single Channel
uint8 XcpAppl_CalculateChecksum  ( uint8 Xcp_Channel,
ROMBYTEPTR pMemArea, BYTEPTR pRes, uint32 length )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
Xcp_Channel
A channel parameter, used when the multi client feature is active.
Please use the macro XCP_CHANNEL_IDX to get the channel index.
pMemArea
Address pointer
pRes
Pointer to response string
Length
Length of mem area, used for checksum calculation
2016, Vector Informatik GmbH
Version: 2.05.00
70 / 94

Technical Reference XCP Protocol Layer

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.
Particularities and Limitations
>  XCP is initialized correctly and in connected state
>  The switches XCP_ENABLE_CHECKSUM and XCP_ENABLE_CUSTOM_CRC is defined

6.6
XCP Protocol Layer Functions that can be overwritten
The following functions are defined within the XCP Protocol Layer and can be overwritten
for optimization purposes.
Note: All services within this chapter are called from task or interrupt level. All services are
not reentrant.

6.6.1
Xcp_MemCpy: Copying of a memory range
Xcp_MemCpy
Prototype
Single Channel
Single Receive Channel  void Xcp_MemCpy  ( DAQBYTEPTR dest,
ROMDAQBYTEPTR src, uint8 n )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
dest
pointer to destination address
src
pointer to source address
n
number of data bytes to copy
Return code
-
-
2016, Vector Informatik GmbH
Version: 2.05.00
71 / 94

Technical Reference XCP Protocol Layer

Functional Description
General memory copy function that copies a memory range from source to destination.
This function is used in the inner loop of Xcp_Event for data acquisition sampling.
This function is already defined in the XCP Protocol Layer, but can be overwritten by a macro or
function for optimization purposes. E.g. it would be possible to use DMA for faster execution.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly.
>  This function can be overwritten Xcp_MemCpy is defined.

6.6.2
Xcp_MemSet: Initialization of a memory range
Xcp_MemSet
Prototype
Single Channel
Single Receive Channel  void Xcp_MemSet  ( BYTEPTR p, uint16 n, uint8 b )
Multi Channel
Indexed
not supported
Code replicated
not supported
Parameter
p
pointer to start address
n
number of data bytes
b
data byte to initialize with
Return code
-
-
Functional Description
Initialization of n bytes starting from address p with b.
This function is already defined in the XCP Protocol Layer, but can be overwritten by a macro or
function for optimization purposes. E.g. it would be possible to use DMA for faster execution.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly.
>  This function can be overwritten if Xcp_MemSet is defined.

6.6.3
Xcp_MemClr: Clear a memory range
Xcp_MemClr
Prototype
Single Channel
Single Receive Channel  static void Xcp_MemClr  ( BYTEPTR p, uint16 n )
Multi Channel
Indexed
not supported
Code replicated
not supported
2016, Vector Informatik GmbH
Version: 2.05.00
72 / 94

Technical Reference XCP Protocol Layer

Parameter
p
pointer to start address
n
number of data bytes
Return code
-
-
Functional Description
Initialize n data bytes starting from address p with 0x00.
This function is already defined in the XCP Protocol Layer, but can be overwritten by a macro or
function for optimization purposes. E.g. it would be possible to use DMA for faster execution.
Particularities and Limitations
>  The XCP Protocol Layer has been initialized correctly.
>  This function can be overwritten if Xcp_MemClr is defined.

6.7
AUTOSAR CRC Module Services called by the XCP Protocol Layer (XCP
Professional Only)
The  following  services  of  the  AUTOSAR  CRC  Module  are  called  by  the  XCP  Protocol
Layer:
Crc_CalculateCRC16(…)
Crc_CalculateCRC32(…)
A  detailed  description  of  the API  can  be  found  in  the  software  specification  of  the  CRC
Module [VII].

6.7.1.1
Generated a2l files
The  GenTool  also  generates  multiple  a2l  files  which  can  be  used  in  the  Master  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)
  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
  ...
2016, Vector Informatik GmbH
Version: 2.05.00
73 / 94

Technical Reference XCP Protocol Layer

/end DAQ
/include CanXCPAsr.a2l
/end IF_DATA
...
/include bsw.a2l
...

2016, Vector Informatik GmbH
Version: 2.05.00
74 / 94

Technical Reference XCP Protocol Layer

6.8
Configuration without Generation Tool
The  configuration  of  the  configuration  switches  and  constants  is  done  in  the  file
Xcp_Cfg.h.
6.8.1
Compiler Switches
Compiler switches are used to enable/disable optional functionalities in order to save code
space and RAM.
In  the  following  table  you  will  find  a  complete  list  of  all  configuration  switches,  used  to
control the functional units. The default values are bold.
Configuration switches
Value
Description
XCP_xxx_DAQ
ENABLE, DISABLE  Enables/disables
synchronous data
acquisition.
XCP_xxx_DAQ_PRESCALER
ENABLE, DISABLE  Enables/disables the
DAQ prescaler.
XCP_xxx_DAQ_OVERRUN_INDICATION
ENABLE, DISABLE  Enables/disables the
DAQ overrun
detection.
XCP_xxx_DAQ_HDR_ODT_DAQ2
ENABLE, DISABLE  The 2 Byte DAQ/ODT
XCP Packet
identification is used
instead of the PID.
Enabled: Relative
ODT number,
absolute list number
(BYTE)
Disabled: Absolute
ODT number
XCP_xxx_DAQ_PROCESSOR_INFO
ENABLE, DISABLE  Plug & play
mechanism for the
data acquisition
processor.
XCP_xxx_DAQ_RESOLUTION_INFO
ENABLE, DISABLE  Plug & play
mechanism for the
data acquisition
resolution.
XCP_xxx_DAQ_EVENT_INFO
ENABLE, DISABLE  Plug & play
mechanism for the
event definitions.
XCP_xxx_DAQ_TIMESTAMP
ENABLE, DISABLE  DAQ timestamps

2 The XCP Protocol allows three identification field types for DTOs: ‘absolute ODT number’, ‘relative ODT
number and absolute DAQ list number’, ‘empty identification field’ (not supported)
2016, Vector Informatik GmbH
Version: 2.05.00
75 / 94

Technical Reference XCP Protocol Layer

XCP_xxx_DAQ_TIMESTAMP_FIXED
ENABLE, DISABLE  Slave always sends
DTO Packets in time
stamped mode.
Otherwise are
timestamps used
individual by each
DAQ-list.
kXcpDaqTimestampSize
DAQ_TIMESTAMP_BYTE,  The size of
DAQ_TIMESTAMP_WORD,  timestamps which can
DAQ_TIMESTAMP_DWORD either be 1Byte,
2Bytes or 4Bytes.
XCP_xxx_SEED_KEY
ENABLE, DISABLE  Seed & key access
protection
XCP_xxx_CHECKSUM
ENABLE, DISABLE  Calculation of
checksum
XCP_xxx_CUSTOM_CRC
ENABLE, DISABLE  Enable call-back for
custom CRC
calculation
XCP_xxx_CRC16CCITT_REFLECTED
ENABLE, DISABLE  Enable/disable
reflected CRC16
CCITT checksum
calculation algorithm.
Also refer to 6.8.2.1
‘Table of Checksum
Calculation Methods’.
XCP_xxx_AUTOSAR_CRC_MODULE
ENABLE, DISABLE  Usage of CRC
algorithms of
AUTOSAR CRC
module.
XCP_xxx_PARAMETER_CHECK
ENABLE, DISABLE  Parameter check
XCP_xxx_SEND_QUEUE
ENABLE, DISABLE  Transmission send
queue
(shall be used in
conjunction with
synchronous data
acquisition and
stimulation).
XCP_xxx_SEND_EVENT
ENABLE, DISABLE  Transmission of event
packets (EV)
XCP_xxx_USER_COMMAND
ENABLE, DISABLE  User defined
command
XCP_xxx_GET_ID_GENERIC
ENABLE, DISABLE  ECU identification
XCP_xxx_TL_COMMAND
ENABLE, DISABLE  Transport Layer
command
XCP_xxx_COMM_MODE_INFO
ENABLE, DISABLE  Communication mode
info
XCP_xxx_CALIBRATION_PAGE
ENABLE, DISABLE  Calibration data page
switching
2016, Vector Informatik GmbH
Version: 2.05.00
76 / 94

Technical Reference XCP Protocol Layer

XCP_xxx_PAGE_INFO
ENABLE, DISABLE  Calibration data page
plug & play
mechanism
XCP_xxx_PAGE_COPY
ENABLE, DISABLE  Calibration data page
copying
XCP_xxx_PAGE_FREEZE
ENABLE, DISABLE  Segment freeze mode
handling
XCP_xxx_DPRAM3
ENABLE, DISABLE  Supports the usage of
dual port RAM
XCP_xxx_BLOCK_UPLOAD
ENABLE, DISABLE  Enables/disables the
slave block transfer.
XCP_xxx_BLOCK_DOWNLOAD
ENABLE, DISABLE  Enables/disables the
master block transfer.
XCP_xxx_WRITE_PROTECTION
ENABLE, DISABLE  Write access to RAM
XCP_xxx_READ_PROTECTION
ENABLE, DISABLE  Read access to RAM
XCP_xxx_READ_EEPROM
ENABLE, DISABLE  Read access to
EEPROM
XCP_xxx_WRITE_EEPROM
ENABLE, DISABLE  Write access to
EEPROM
XCP_xxx_PROGRAMMING_WRITE_PROTECTION ENABLE, DISABLE  Write access to flash
XCP_xxx_PROGRAM
ENABLE, DISABLE  Flash programming
XCP_xxx_PROGRAM_INFO
ENABLE, DISABLE  Flash programming
plug & play
mechanism
XCP_xxx_BOOTLOADER_DOWNLOAD
ENABLE, DISABLE  Flash programming
with a flash kernel
XCP_xxx_STIM
ENABLE, DISABLE  Enables/disables data
stimulation.
(also
XCP_ENABLE_DAQ
has to be defined in
order to use data
stimulation)
XCP_xxx_DAQ_RESUME
ENABLE, DISABLE  Data acquisition
resume mode.
XCP_xxx_SERV_TEXT
ENABLE, DISABLE  Transmission of
service request codes
XCP_xxx_SERV_TEXT_PUTCHAR
ENABLE, DISABLE  Putchar function for
the transmission of
service request
messages
XCP_xxx_SERV_TEXT_PRINTF
ENABLE, DISABLE  Print function for the
transmission of
service request
messages

3 Not supported by XCP Professional
2016, Vector Informatik GmbH
Version: 2.05.00
77 / 94

Technical Reference XCP Protocol Layer

XCP_xxx_MEM_ACCESS_BY_APPL
ENABLE, DISABLE  Memory access by
application
XCP_xxx_MODEL_PAGED
ENABLE, DISABLE  Support for paging /
banking
XCP_xxx_SHORT_DOWNLOAD
ENABLE, DISABLE  Support for
SHORT_DOWNLOAD
command
XCP_xxx_MODIFY_BITS
ENABLE, DISABLE  Support for
MODIFY_BITS
command
XCP_xxx_WRITE_DAQ_MULTIPLE
ENABLE, DISABLE  Write DAQ multiple
command
XCP_xxx_GET_XCP_DATA_POINTER
ENABLE, DISABLE  Enable API for
internal data access
XCP_xxx_CONTROL
ENABLE, DISABLE  Enable functionality to
en- / disable XCP
module
XCP_xxx_DEV_ERROR_DETECT
ENABLE, DISABLE  Enable Development
Error check
XCP_xxx_READCCCONFIG
ENABLE, DISABLE  Enable Read of
FlexRay Parameters
XCP_ADDR_EXT_READCCCONFIG
0x00…0xff
Address  Extension to
be used for FlexRay
Parameters
XCP_xxx_VECTOR_GENERICMEASUREMENT
ENABLE, DISABLE  Support for Generic
Measurement feature
XCP_xxx_GET_SESSION_STATUS_API
ENABLE, DISABLE  Enable API to acquire
the current session
status

6.8.2
Configuration of Constant Definitions
The configuration of constant definitions is done as described below.
The default values are bold.
Constant definitions
Range
Default  Description
kXcpMaxCTOMax
8..255
8
Maximum length of XCP command transfer
objects (CTO).
The length of the CTO can be variable.
However it has to be configured according to the
used XCP Transport Layer.
2016, Vector Informatik GmbH
Version: 2.05.00
78 / 94

Technical Reference XCP Protocol Layer

kXcpMaxDTOMax
8..2554
8
Maximum length of XCP data transfer objects
(DTO).
The length of the DTO can be variable.
However it has to be configured according to the
used XCP Transport Layer.
kXcpDaqMemSize
0..
256
Define the amount of memory used for the DAQ
0xFFFF
lists and buffers.
Also refer to chapter 7 (Resource
Requirements).
kXcpSendQueueMinSize
1..0x7F  -
The minimum queue size required for DAQ. The
queue size is the unallocated memory reserved
by kXcpDaqMemSize.
kXcpMaxEvent
0..0xFF5  -
Number of available events in the slave (part of
event channel plug & play mechanism)
Also refer to chapter 6.8.5.
kXcpStimOdtCount
0..0xC0  0xC0
Maximum number of ODTs that may be used for
Synchronous Data Stimulation.
kXcpChecksumMethod
-
-
Checksum calculation method.
Refer to chapter 6.8.2.1 ‘Table of Checksum
Calculation Methods’ for valid values.
kXcpChecksumBlockSize  1 ..
256
Each call of Xcp_MainFunction calculates the
0xFFFF
checksum on the amount of bytes specified by
kXcpChecksumBlockSize.
XCP_TRANSPORT_LAYER_V
0..
-
Version of the XCP Transport Layer that is used.
ERSION
0xFFFF
(this version gets transferred to the MCS)
kXcpMaxSector
1..0xFF  -
Number of flash sectors
Also refer to chapter 6.8.7
kXcpMaxSegment
1
1
Number of memory segments
Also refer to chapter 6.8.8.
kXcpMaxPages
1..2
2
Number of pages
Also refer to chapter 6.8.8.
NUMBER_OF_TRANSPORTLA
1..
1
Number of used Transport Layers
YERS
XCP_TRANSPORT_LAYER_C
0..
0
Index of Transport Layer
AN
XCP_TRANSPORT_LAYER_F
0..
1
Index of Transport Layer
R
XCP_TRANSPORT_LAYER_E
0..
2
Index of Transport Layer
TH

6.8.2.1
Table of Checksum Calculation Methods
Constant
Checksum calculation method
XCP_CHECKSUM_TYPE_ADD11
Add BYTE into a BYTE checksum, ignore overflows.
XCP_CHECKSUM_TYPE_ADD12
Add BYTE into a WORD checksum, ignore overflows

4 Implementation specific range. The range is 8..0xFFFF according to XCP specification [I], [II].
5 Implementation specific range. The range is 0..0xFFFE according to XCP specification [I], [II].
2016, Vector Informatik GmbH
Version: 2.05.00
79 / 94

Technical Reference XCP Protocol Layer

XCP_CHECKSUM_TYPE_ADD14
Add BYTE into a DWORD checksum, ignore overflows
XCP_CHECKSUM_TYPE_ADD22
Add WORD into a WORD checksum, ignore overflows, block
size must be modulo 2
XCP_CHECKSUM_TYPE_ADD24
Add WORD into a DWORD checksum, ignore overflows,
block size must be modulo 2
XCP_CHECKSUM_TYPE_ADD44
Add DWORD into DWORD, ignore overflows, block size
must be modulo 4
XCP_CHECKSUM_TYPE_CRC16CCITT  CRC16 CCITT checksum calculation algorithm
Both the standard and the reflected algorithm are supported.
Please refer to chapter 9.6 ‘Reflected CRC16 CCITT
Checksum Calculation Algorithm’.
The CRC16 CCITT algorithm of the AUTOSAR CRC module
is only supported by XCP Professional.
XCP_CHECKSUM_TYPE_CRC32
CRC32 checksum calculation algorithm
The CRC32 algorithm is only supported in XCP Professional
if the AUTOSAR CRC module is used.

6.8.3
Configuration of the CPU Type
To provide platform independent code platform, the CPU type has to be defined.
Configuration switches
Value
Description
C_CPUTYPE_xxxENDIAN
LITTLE,  Definition whether the CPU is little endian (Intel
BIG
format) or big endian (Motorola format).
XCP_xxx_UNALIGNED_MEM_ACCESS  ENABLE,  Enables / disables unaligned memory access.
DISABLE  If XCP_DISBLE_UNALIGNED_MEM_ACCESS is
defined WORDs are located on WORD aligned and
DWORD are located on DWORD aligned addresses.

6.8.4
Configuration of Slave Device Identification
The configuration of the slave device identification and automatic session configuration is
described within this chapter. Only one of the following options can be used at one time.
6.8.4.1
Identification by ASAM-MC2 Filename without Path and Extension
If  the  slave  device  identification  is  done  by  identification  with  an  ASAM-MC2  filename
without path and extension the filename length has to be defined:
#define kXcpStationIdLength length
and the station ID itself has to be defined as string:
const uint8 kXcpStationId[] = “station ID”
The range of kXcpStationIdLength is 0..0xFF.
6.8.4.2
Automatic Session Configuration with MAP Filenames
The  automatic  session  configuration  by  transferring  MAP  filenames  is  a  Vector  specific
extension that works with CANape and can be enabled by the “XcpGetIdGeneric” attribute.
When this feature  is enabled the API as described in  3.4.2  XCP Generic Identification  is
enabled. This API will be called, should CANape request the MAP filename, and must be
2016, Vector Informatik GmbH
Version: 2.05.00
80 / 94

Technical Reference XCP Protocol Layer

implemented by the user accordingly. This feature must explicitly  be enabled in  CANape
as well!

Example


#define MAP_FORMAT 29
#define MAP_NAME   "xcpsim"

uint8 MapTest[500];
uint32 MapTestSize;

uint32 XcpAppl_GetIdData( MTABYTEPTR *pData, uint8 id )
{
  if( id == IDT_VECTOR_MAPNAMES )
  {
  MapTestSize =
sprintf((char*)MapTest,"%c%c%s.map",MAP_FORMAT,0,MAP_NAME);
  /* Result: MapTest = ”290xcpsim.map” */
  *pData = MapTest;
  return MapTestSize;
  }
  else
  {
  return 0; /* Id not available */
  }
}

‘MAP_FORMAT’ represents the format of the MAP file. (See table below)
‘0’ is a counter that is used as address extension. Please set this parameter to 0.
Table of MAP file formats:
  1 = "BorlandC 16 Bit" 29 = "Microsoft standard"
  2 = "M166" 30 = "ELF/DWARF 16 Bit"
  3 = "Watcom" 31 = "ELF/DWARF 32 Bit"
  4 = "HiTech HC05"    32 = "Fujitsu Softune 3..8(.mps)"
  6 = "IEEE" 33 = "Microware Hawk"
  7 = "Cosmic" 34 = "TI C6711"
  8 = "SDS" 35 = "Hitachi H8S"
  9 = "Fujitsu Softune 1(.mp1)" 36 = "IAR HC12"
  10 = "GNU" 37 = "Greenhill Multi 2000"
  11 = "Keil 16x" 38 = "LN308(MITSUBISHI) for M16C/80"
  12 = "BorlandC 32 Bit" 39 = "COFF settings auto detected"
  13 = "Keil 16x (static)" 40 = "NEC CC78K/0 v35"
  14 = "Keil 8051" 41 = "Microsoft extended"
  15 = "ISI" 42 = "ICCAVR"
  16 = "Hiware HC12" 43 = "Omf96 (.m96)"
  17 = "TI TMS470" 44 = "COFF/DWARF"
2016, Vector Informatik GmbH
Version: 2.05.00
81 / 94

Technical Reference XCP Protocol Layer

  18 = "Archimedes" 45 = "OMF96 Binary (Tasking C196)"
  19 = "COFF" 46 = "OMF166 Binary (Keil C166)"
  20 = "IAR" 47 = "Microware Hawk Plug&Play ASCII"
  21 = "VisualDSP" 48 = "UBROF Binary (IAR)"
  22 = "GNU 16x" 49 = "Renesas M32R/M32192 ASCII"
  23 = "GNU VxWorks" 50 = "OMF251 Binary (Keil C251)"
  24 = "GNU 68k" 51 = "Microsoft standard VC8"
  25 = "DiabData" 52 = "Microsoft VC8 Release Build (MATLAB DLL)"
  26 = "VisualDSP DOS" 53 = "Microsoft VC8 Debug Build (MATLAB DLL)"
  27 = "HEW SH7055" 54 = "Microsoft VC8 Debug file (pdb)"
  28 = "Metrowerks"

6.8.5
Configuration of the Event Channel Plug & Play Mechanism
The event channel plug & play mechanism is enabled with the switch
XCP_ENABLE_DAQ_EVENT_INFO
A prerequisite for the event channel plug & play mechanism is the general data acquisition
plug  &  play  mechanism.  If  the  mechanism  is  enabled  the  following  configurations  items
have to be defined as described below:
Constant
Range
Description
kXcpMaxEvent
0..0xFF6
Number of available events in the slave
(part of event channel plug & play mechanism)
If the event numbers do not start at 0 or are not
continuous this is the maximum used event channel
number plus 1.
kXcpEventName[]
kXcpMaxEvent  List with pointers to the event channel names that are
defined as strings.
kXcpEventNameLength[]  kXcpMaxEvent  Length of the event channel names without the
terminating char.
kXcpEventCycle[]
kXcpMaxEvent  Cycle time of the event channels in milliseconds.
kXcpEventDirection[]
kXcpMaxEvent  Direction of the event channels.
For XCP Basic valid values are:
-
kXcpEventDirectionDaq
For XCP Professional valid values are:
-
kXcpEventDirectionDaq
-
kXcpEventDirectionStim
-
kXcpEventDirectionDaqStim

Example

#define XCP_ENABLE_DAQ_EVENT_INFO
#define kXcpMaxEvent 3

CONST(uint8, XCP_CONST) kXcpEventName_0[] = "10ms";

6 Implementation specific range. The range is 0..0xFFFE according to XCP specification [I], [II].
2016, Vector Informatik GmbH
Version: 2.05.00
82 / 94

Technical Reference XCP Protocol Layer

CONST(uint8, XCP_CONST) kXcpEventName_1[] = "100ms DAQ";
CONST(uint8, XCP_CONST) kXcpEventName_2[] = "100ms STIM";
CONSTP2CONST(uint8, XCP_CONST, XCP_CONST) kXcpEventName[] =
{
  &kXcpEventName_0[0],
  &kXcpEventName_1[0],
  &kXcpEventName_2[0]
};

CONST(uint8, XCP_CONST) kXcpEventNameLength[] =
{
  4,
  9,
  10
};

CONST(uint8, XCP_CONST) kXcpEventCycle[] =
{
  10,
  100,
  100
};

CONST(uint8, XCP_CONST) kXcpEventDirection[] =
{
  kXcpEventDirectionDaq,
  kXcpEventDirectionDaq,
  kXcpEventDirectionStim
};

6.8.6
Configuration of the DAQ Time Stamped Mode
Transmission  of  DAQ  timestamps  is  enabled  with  XCP_ENABLE_DAQ_TIMESTAMP.  If
XCP_ENABLE_DAQ_TIMESTAMP_FIXED is defined all DTO Packets will be transmitted in
time stamped mode.
Constant
Range
Description
kXcpDaqTimestampSize
DAQ_TIMESTAMP_BYTE,
This parameter defines the
DAQ_TIMESTAMP_WORD,
size of timestamps. It can
DAQ_TIMESTAMP_DWORD
either be 1 byte, 2 bytes or 4
bytes.
XcpDaqTimestampType
uint8, uint16 or uint32
Type of the timestamp
depends on the parameter
kXcpDaqTimestampSize.
2016, Vector Informatik GmbH
Version: 2.05.00
83 / 94

Technical Reference XCP Protocol Layer

kXcpDaqTimestampUnit
DAQ_TIMESTAMP_UNIT_1NS
Unit of the timestamp
DAQ_TIMESTAMP_UNIT_10NS
(1 ns, 10 ns .. 1 s)
DAQ_TIMESTAMP_UNIT_100NS
DAQ_TIMESTAMP_UNIT_1US

DAQ_TIMESTAMP_UNIT_10US

DAQ_TIMESTAMP_UNIT_100US
DAQ_TIMESTAMP_UNIT_1MS
DAQ_TIMESTAMP_UNIT_10MS
DAQ_TIMESTAMP_UNIT_100MS
DAQ_TIMESTAMP_UNIT_1S
DAQ_TIMESTAMP_UNIT_1pS
DAQ_TIMESTAMP_UNIT_10pS
DAQ_TIMESTAMP_UNIT_100pS
kXcpDaqTimestampTicksPerUnit  0..0xFFFF
Time stamp ticks per unit

6.8.7
Configuration of the Flash Programming Plug & Play Mechanism
The flash programming plug & play mechanism is enabled with the switch
XCP_ENABLE_PROGRAM_INFO
If the plug & play mechanism is enabled the number of sectors and the start address and
end address of each sector has to be defined. The constants that have to be defined can
be found in the following table.
Constant
Range
Description
kXcpMaxSector
0..0xFF
Number of available flash sectors in the slave
kXcpSectorName[]
kXcpMaxSector  List with pointers to the Sector names that are
defined as strings.
kXcpSectorNameLength
kXcpMaxSector  Length of the Sector names without the terminating
char.
kXcpProgramSectorStart[]  kXcpMaxSector  List with the start addresses of the sectors
kXcpProgramSectorEnd[]
kXcpMaxSector  List with the end address of the sectors

Example

#define XCP_ENABLE_PROGRAM_INFO
#define kXcpMaxSector 2

CONST(XcpCharType, XCP_CONST) kXcpSectorName_0[] = "Sector0";
CONST(XcpCharType, XCP_CONST) kXcpSectorName_1[] = "Sector1";

CONSTP2CONST(XcpCharType, XCP_CONST, XCP_CONST) kXcpSectorName[] =
{
  &kXcpSectorName_0[0],
  &kXcpSectorName_1[0]
};
CONST(uint8, XCP_CONST) kXcpSectorNameLength[] =
{
2016, Vector Informatik GmbH
Version: 2.05.00
84 / 94

Technical Reference XCP Protocol Layer

  7U,
  7U
};
CONST(uint32, XCP_CONST) kXcpProgramSectorStart [] =
{
  (uint32)0x000000u,
  (uint32)0x010000u,
};
CONST(uint32, XCP_CONST) kXcpProgramSectorEnd [] =
{
  (uint32)0x00FFFFu,
  (uint32)0x01FFFFu,
};

6.8.8
Configuration of the Page Switching Plug & Play Mechanism
The page switching plug & play mechanism is enabled with the switch
XCP_ENABLE_PAGE_INFO
If  the  plug  &  play  mechanism  is  enabled  the  following  configurations  items  have  to  be
defined as described below:
Constant
Range
Description
kXcpMaxSegment
0x01
Number of memory segments
kXcpMaxPages
0x01..0x02
Number of pages

6.8.9
Configuration of the used Transport Layer
The XCP Protocol Layer uses a jump table to call respective  Transport Layer Functions.
This jump table has to contain certain Function names
Constant
Range
Description
Xcp_TlApi
Number of TL  Function Pointer table containing pointers to the
respective Transport Layer

Example

#define NUMBER_OF_TRANSPORTLAYERS 1
#define XCP_TRANSPORT_LAYER_CAN 0u

CONST(Xcp_TlApiType, XCP_CONST)
Xcp_TlApi[NUMBER_OF_TRANSPORTLAYERS] =
{
  {
  CanXcp_Send, /* ApplXcpSend */
  CanXcp_SendFlush /* ApplXcpSendFlush */
  #if defined ( XCP_ENABLE_TL_COMMAND )
  ,
  CanXcp_TLService /* ApplXcpTLService */
  #endif
  }
};
2016, Vector Informatik GmbH
Version: 2.05.00
85 / 94

Technical Reference XCP Protocol Layer

2016, Vector Informatik GmbH
Version: 2.05.00
86 / 94

Technical Reference XCP Protocol Layer

7  Resource Requirements
The  resource  requirements  of  the  XCP  Protocol  Layer  mainly  depend  on  the  micro
controller,  compiler  options  and  configuration.  Within  this  chapter  only  the  configuration
specific resource requirements are taken in consideration.

2016, Vector Informatik GmbH
Version: 2.05.00
87 / 94

Technical Reference XCP Protocol Layer

8  Limitations
8.1
General Limitations
The functional limitations of the XCP Professional Version are listed below:
>  Bit stimulation is not supported
>  Only dynamic DAQ list allocation supported
>  The interleaved communication model is not supported
>  Only default programming data format is supported
>  GET_SECTOR_INFO does not return sequence numbers
>  Program Verify and Program Format are not supported
>  DAQ numbers are limited to byte size
>  DAQ does not support address extension
>  DAQ-list and event channel prioritization is not supported
>  Event channels contain one DAQ-list
>  ODT optimization not supported
>  Assignments of CAN identifiers to DAQ lists is not supported
>  MAX_DTO is limited to 0xFF
>  The resume bits in DAQ lists are not set
>  STORE_DAQ, CLEAR_DAQ and STORE_CAL do not send an event message
>  Entering resume mode does not send an event message
>  Overload indication by an event is not supported
>  SERV_RESET is not supported
>  The following checksum types are not supported
>  XCP_CRC_16
>  XCP_CRC_32
>  XCP_USER_DEFINED
>  Maximum checksum block size is 0xFFFF
>  Page Info and Segment Info is not supported
>  Only one segment and two pages are supported
>  The seed size and key size must be equal or less MAX_CTO-2
>  Consistency only supported on ODT level
2016, Vector Informatik GmbH
Version: 2.05.00
88 / 94

Technical Reference XCP Protocol Layer

Planned:
>  User defined checksum calculations
>  CRC16 and CRC32
>  The AUTOSAR API Xcp_SetTransmissionMode is not supported

8.2
Limitations Regarding Platforms, Compilers and Memory Models
Even  though  the  XCP  is  a  Protocol  Layer  and  therefore  higher  software  layer,  it
manipulates memory addresses and directly access the memory with these addresses.
This  might  cause  issues  for  some  combinations  of  platforms,  compilers  and  memory
models.  The  following  list  provides  all  known  restrictions  on  platforms,  compilers  and
linkers:
>  CANoeOSEK Emulation is not supported

2016, Vector Informatik GmbH
Version: 2.05.00
89 / 94

Technical Reference XCP Protocol Layer

9  FAQ
9.1
Invalid Time Stamp Unit

FAQ
If using data acquisition CANape reports an error due to an invalid timestamp

unit.

If you are using CANape 5.5.x or an earlier version please define
#define XCP_ENABLE_CANAPE_5_5_X_SUPPORT
in your user config file.
9.2
Support of small and medium memory model

FAQ
How is the XCP Protocol Layer configured in order to access the whole memory

in the small and medium memory model?

By  default  The  XCP  Protocol  Layer  accesses  the  memory  with  a  default  pointer.  I.e.  in
small and medium memory model a near pointer is used. If the far memory (e.g. code or
read-only  sections)  needs  to  be  accessed  via  the  XCP  Protocol  the  memory  qualifiers
have to be defined as far pointers by the user within the user config file.
Two memory qualifiers are used to access the memory:
MTABYTEPTR
#define MTABYTEPTR P2VAR(uint8, AUTOMATIC, XCP_MTA_DATA)
This pointer is used to access memory for standard read and
write operations
DAQBYTEPTR
#define DAQBYTEPTR P2VAR(uint8, AUTOMATIC, XCP_DAQ_DATA)
This pointer is used to access memory for the Synchronous Data
Acquisition
Depending  on  the  use  case,  microcontroller,  memory  model  and  compiler  either
XCP_MEMORY_FAR  or  both  memory  qualifiers  (DAQBYTEPTR  and  MTABYTEPTR)  have  to
be defined by the user. Alternatively the AUTOSAR Compiler Abstraction can be used. In
this case the pointer classes
XCP_MTA_DATA and
XCP_DAQ_DATA
Have to be defined as “far” according to the used compiler.
2016, Vector Informatik GmbH
Version: 2.05.00
90 / 94

Technical Reference XCP Protocol Layer

9.3
Small memory model on ST10 / XC16X / C16X with Tasking Compiler

FAQ
How has XCP Protocol Layer to be configured in order to support small memory

model on the following microcontrollers: ST10, XC16X, C16X with Tasking
Compiler?

If  the  small memory model  is used  and the  two  least  significant  bits of  the  DPP  register
where the data of XCP is located is not equal the default DPP register value (i.e. the two
least significant bits of DPPx are unequal x, x=0..3) the configuration of the XCP Protocol
Layer has to be adapted in the user config file
Disable type casts from pointers to integers :
#define XCP_ENABLE_NO_P2INT_CAST
9.4
Data Page Banking on Star12X / Metrowerks

FAQ
How has the XCP Protocol Layer to be configured in order to support data page

banking on the Star12X with Metrowerks compiler?

In  order  to  use  data  page  banking  the  following  definition  has  to  be  added  to  the  user
config file:
#define XCP_MEMORY_MODEL_PAGED
If this option is enabled far pointers are used for memory access, and address conversions
are carried out in the in the application callback template  _xcp_appl.c. These address
conversions have to adapted to the used derivative.

Please note
The data page banking support is implemented in the template _xcp_appl.c for

the MC9S12XDP512. For other Star12X derivatives the template has to be
adapted.

9.5
Memory model banked on Star12X / Cosmic

FAQ
How has the XCP Protocol Layer to be configured in order to support the access

to far pages in the banked memory model on the Star12X with Cosmic compiler?

In order to access far pages or support data page banking the following definitions have to
be added to the user config file:
#define XCP_MEMORY_MODEL_PAGED
2016, Vector Informatik GmbH
Version: 2.05.00
91 / 94

Technical Reference XCP Protocol Layer

#define XCP_ENABLE_MEM_ACCESS_BY_APPL
If this option is enabled far pointers are used for memory access, and address conversions
are carried out in the in the application callback template  _xcp_appl.c. These address
conversions have to adapted to the used derivative.

Please note
The data page banking support is implemented in the template _xcp_appl.c for

the MC9S12XDP512. For other Star12X derivatives the template has to be
adapted.

9.6
Reflected CRC16 CCITT Checksum Calculation Algorithm

FAQ
How is the reflected CRC16 CCITT checksum calculation algorithm configured?

The  XCP  Protocol  Layer  supports  both  the  standard  CRC16  CCITT  algorithm  and  the
reflected  CRC16  CCITT  algorithm.  In  order  to  use  the  reflected  algorithm  the  following
definition has to be added to the user config file:
#define XCP_ENABLE_CRC16CCITT_REFLECTED

Please note
Up to CANape version 5.6.30.3 (SP3) the standard CRC16 CCITT algorithm is

not supported, but the reflected one.
However a user checksum calculation DLL can be used in order to use the
standard algorithm with former versions of CANape.

2016, Vector Informatik GmbH
Version: 2.05.00
92 / 94

Technical Reference XCP Protocol Layer

10  Bibliography
This manual refers to the following documents:
[I]  XCP -Part 1 - Overview
Version 1.1
[II]  XCP -Part 2- Protocol Layer Specification
Version 1.1
[III] XCP -Part 5- Example Communication Sequences
Version 1.1
[IV] Technical Reference XCP on CAN Transport Layer
Version 1.6
[V]  Technical Reference XCP on FlexRay Transport Layer
Version 1.9
[VI] Technical Reference XCP on LIN Transport Layer
Version 1.0
[VII]  AUTOSAR Specification of CRC Routines
Release 2.0.0 of 2006-04-28

2016, Vector Informatik GmbH
Version: 2.05.00
93 / 94

Technical Reference XCP Protocol Layer

11 Contact
Visit our website for more information on

> News
> Products
> Demo software
> Support
> Training data
> Addresses

www.vector-informatik.com

2016, Vector Informatik GmbH
Version: 2.05.00
94 / 94

Document Outline

7 - UserManual_AUTOSAR_Calibration

User Manual AUTOSAR Calibration

8 - UserManual_AUTOSAR_Calibration_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79

9 - 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 used. 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 in 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 reference 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 the 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]  5max. 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 the 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 (see 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 software
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
Software 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 Peer Review Checklists

Overview

Summary Sheet
Synergy Project
3rd Party Files

Sheet 1: Summary Sheet

Rev 1.0

19-Apr-17

Peer Review Summary Sheet

Synergy Project Name:

Windows User: Intended Use: Identify which component is being reviewed. This should match the component short name and the middle part of the Synergy project name Xcp

Revision / Baseline:

Windows User: Intended Use: Identify the implementation baseline name intended to be used for the changed component when changes are approved. Xcp_Vector_Autosar_03.00.00_0

Change Owner:

Windows User: Intended Use: Identify the developer who made the change(s) being reviewed Xin Liu

Work CR ID:

Windows User: Intended Use: Identify the Implementation Work CR whose work is being reviewed (may be more than one) 13576

3rd party delivery package identifier:

Intended Use: This is a reference to the identifier of the 3rd party delivery package(s) that the component was extracted/created from. Rationale: This will allow easier tracing back to 3rd party deliveries. CBD1500636_D01_Rh850 / CBD1601056_D00_Rh850

Windows User: Identifiy which type of 3rd party component this is so as to provide appropriate review checklist sheets Component Type:

Windows User: General section for summarizing review comments or review notes. Review Checklist Summary:

Comments:

Sheet 2: Synergy Project

Peer Review Meeting Log (Component Synergy Project Review)

Quality Check Items:

Rationale is required for all answers of No

New baseline version name from Summary Sheet follows

Yes

Comments:

naming convention for 3rd Party Software Components

Project contains necessary subprojects

N/A

Comments:

There are no subprojects

Project contains the correct version of subprojects

N/A

Comments:

There are no subprojects

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Xin Liu

Review Date :

07/11/17

Lead Peer Reviewer:

Bobby O'Steen

Approved by Reviewer(s):

Yes

Other Reviewer(s):

Sheet 3: 3rd Party Files

Peer Review Meeting Log (3rd Party File Review)

Quality Check Items:

Rationale is required for all answers of No

(e.g. component_bswmd.arxml) Component "autosar" folder contains autosar module description file from 3rd party delivery package

Yes

Comments:

(e.g. component_preo.arxml) Component "autosar" folder contains any relevant preconfiguration files from 3rd party delivery package(s)

Yes

Comments:

If needed as in the case with Renesas MCAL (e.g. MCALcomponent_bswmd_rec.arxml taken from Vector delivery) Component "autosar" folder contains any needed supplemental autosar module description file(s)

N/A

Comments:

Component "doc" folder contains all documentation related to this component from 3rd party delivery package

Yes

Comments:

Modifications from delivery to be reviewed (e.g. path changes) Component "generate" folder contains all external generation files from 3rd party delivery package

N/A

Comments:

Component "include" and "src" folder contains exact component files from 3rd party delivery package

Yes

Comments:

Component "make" folder contains any makefiles included from 3rd party delivery package

Yes

Comments:

1) All source and headers of component should be referenced in .gpj 2) Compiler settings may need to be tailored to source component (e.g. Renesas MCAL vs Vector BSWs) Component "tools" folder contains GHS project file with appropriate files referenced with appropriate compiler settings

Yes

Comments:

Should delete old existing files/directories from integration project and copy new ones into integration project May also contain logic for integrator user interaction if required. (e.g. selection of micro variant on MCAL) Component "tools" folder contains Integrate.bat with appropriate logic in it for integration into project

Yes

Comments:

For external generation and internal behavior definition for use with Vector Davinci tools. Typically only desired/needed for non-Vector developed components. This file should be copied as part of Integrate.bat. Components optionally contains settings xml file with appropriate contents

N/A

Comments:

General Notes / Comments:

LN: Intended Use: Identify who were the reviewers and if the reviewed changes have been approved. Rationale: Since this Form will be attached to the Change Request it will confirm the approval and provides feedback in case of audits. KMC: Group Review Level removed in Rev 4.0 since the design review is not checked in until approved, so it would always be DR4. Review Board:

Change Owner:

Xin Liu

Review Date :

07/11/17

Lead Peer Reviewer:

Bobby O'Steen

Approved by Reviewer(s):

Yes

Other Reviewer(s):

11 - XCP_ReferenceBook_V2.0_EN

XCP – The Standard Protocol for ECU Development

12 - XCP_ReferenceBook_V2.0_EN_ind

Outline
Page 1
Page 2
Page 3
Page 4
Page 5
Page 6
Page 7
Page 8
Page 9
Page 10
Page 11
Page 12
Page 13
Page 14
Page 15
Page 16
Page 17
Page 18
Page 19
Page 20
Page 21
Page 22
Page 23
Page 24
Page 25
Page 26
Page 27
Page 28
Page 29
Page 30
Page 31
Page 32
Page 33
Page 34
Page 35
Page 36
Page 37
Page 38
Page 39
Page 40
Page 41
Page 42
Page 43
Page 44
Page 45
Page 46
Page 47
Page 48
Page 49
Page 50
Page 51
Page 52
Page 53
Page 54
Page 55
Page 56
Page 57
Page 58
Page 59
Page 60
Page 61
Page 62
Page 63
Page 64
Page 65
Page 66
Page 67
Page 68
Page 69
Page 70
Page 71
Page 72
Page 73
Page 74
Page 75
Page 76
Page 77
Page 78
Page 79
Page 80
Page 81
Page 82
Page 83
Page 84
Page 85
Page 86
Page 87
Page 88
Page 89
Page 90
Page 91
Page 92
Page 93
Page 94
Page 95
Page 96
Page 97
Page 98
Page 99
Page 100
Page 101
Page 102
Page 103
Page 104
Page 105
Page 106
Page 107
Page 108
Page 109
Page 110
Page 111
Page 112
Page 113
Page 114
Page 115
Page 116

13 - XCP_ReferenceBook_V2.0_ENs

XCP – The Standard Protocol
for ECU Development
Fundamentals and Application Areas
Andreas Patzer | Rainer Zaiser

Andreas Patzer | Rainer Zaiser
XCP – The Standard Protocol for ECU Development

Date April 2014 | Reproduction only with expressed permission from
Vector Informatik GmbH, Ingersheimer Str. 24, 70499 Stuttgart, Germany
© 2014 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.

XCP –
The Standard Protocol
for ECU Development
Fundamentals and Application Areas
Andreas Patzer, Rainer Zaiser
Vector Informatik GmbH

Table of Contents
Introduction
7
1  Fundamentals of the XCP Protocol
13
1.1  XCP Protocol Layer
19

1.1.1  Identification Field
21

1.1.2  Time Stamp
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
41

1.3.4  XCP Packet Addressing for DAQ and STIM
42

1.3.5  Bypassing = DAQ + STIM
44
1.4  XCP Transport Layers
45

1.4.1 CAN
45

1.4.2  CAN FD
48

1.4.3 FlexRay
50

1.4.4 Ethernet
53

1.4.5 SxI
55

1.4.6 USB
55

1.4.7 LIN
55
1.5  XCP Services
56

1.5.1  Memory Page Swapping
56

1.5.2  Saving Memory Pages – Data Page Freezing
58

1.5.3  Flash Programming
58

1.5.4  Automatic Detection of the Slave
60

1.5.5  Block Transfer Mode for Upload, Download and Flashing
61

1.5.6  Cold Start Measurement (start of measurement during power-on)
62

1.5.7  Security Mechanisms with XCP
63

2  ECU Description File A2L
65
2.1  Setting Up an A2L File for an XCP Slave
68
2.2 Manually Creating an A2L File
69
2.3 A2L Contents versus ECU Implementation
70
3  Calibration Concepts
73
3.1  Parameters in Flash
74
3.2 Parameters in RAM
76
3.3 Flash Overlay
78
3.4 Dynamic Flash Overlay Allocation
79
3.5 RAM Pointer Based Calibration Concept per AUTOSAR
80

3.5.1 Single Pointer Concept
80

3.5.2 Double Pointer Concept
82
3.6 Flash Pointer Based Calibration Concept
83
4  Application Areas of XCP
85
4.1  MIL: Model in the Loop
87
4.2 SIL: Software in the Loop
88
4.3 HIL: Hardware in the Loop
89
4.4 RCP: Rapid Control Prototyping
91
4.5 Bypassing
92
4.6 Shortening Iteration Cycles with Virtual ECUs
95
5  Example of an XCP Implementation
99
5.1  Description of Functions
102
5.2 Parameterization of the Driver
104
The Authors
106
Table of Abbreviations and Acronyms
108
Literature
109
Web Addresses
109
Table of Figures
110
Appendix – XCP Solutions at Vector
112
Index
114

Introduction
7
Introduction
In optimal parameterization (calibration) of electronic ECUs, you calibrate parameter values
during the system runtime and simultaneously acquire measured signals. The physical connec-
tion 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 applica-
tion 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 vari-
able and interchangeable transport layer.
>   It was standardized by an ASAM working committee (Association for Standardisation of Auto-
mation and Measuring Systems). ASAM is an organization of automotive OEMs, suppliers 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 different
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 parameters.
Here, the protocol offers the ability to acquire measured values “event synchronous” to pro-
cesses 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 val-
ues) 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 functional-
ity 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 optimized. It does
not matter here whether a compiled code runs on a specific hardware or whether it is developed
in a model-based 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 noth-
ing other than read access to parameters so that they can be visualized and analyzed – and all
of this at model runtime or retrospectively after a time-limited test run has been completed. A
write access is needed if parameterizations are changed, e.g. if the proportional component of a

8
Introduction
PID controller is modified to adapt the algorithm behavior to the system under control. Regard-
less 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 time-based flow. Parameter sets are modified iter-
atively to optimize algorithms. To simplify the representation, the acquisition of data can be
externalized to an external PC-based tool, although it is understood here that runtime environ-
ments themselves can even offer analysis capabilities.
Runtime Environment
Application
Figure 1:
Communication
PC Tool
Fundamental
Operating System
communication
with a runtime
environment
The 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 different
producers and are based on different solution approaches. Different types of protocols, con-
figurations, measurement data formats, etc. make it a futile effort to try to exchange parame-
ter sets and results in all development steps. In the end, however, all of these solutions 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.” Suppliers, 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 calibration 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 measure-
ment and calibration tool’s interfaces to the XCP Slave, to the description file and the connec-
tion to a higher-level automation system.

Introduction
9
Upper Level
Automation System
ASAM MCD 3MC
Measurement and
ASAM
Calibration System
MCD 2MC
*.a2L
XCP Driver
ECU Description File
ASAM MCD 1MC
XCP Driver
ECU
Figure 2:
The Interface Model
of ASAM
Interface 1: “ASAM MCD-1 MC” between the ECU and the measurement and calibration system
This interface describes the physical and the protocol-specific parts. Strictly speaking, a dis-
tinction was made between interfaces ASAP1a and ASAP1b here. The ASAP1b interface, how-
ever, 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 manufacturer-
independent interface. For example, today all measurement and calibration hardware manufac-
turers offer systems (xETK, VX1000, etc.) which can be connected via the XCP on Ether net stan-
dard. 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 address-oriented 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 Master-Slave principle. The ECU is the Slave and the measurement and cali-
bration 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 Slaves
To 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, operated and
maintained. This would also eliminate the need for manual copying of configurations 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: every-
thing! 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: nei-
ther 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, including
how to create an A2L file and even more. With a cost-free demo version, which is available to you
in the Download Center of the Vector website at www.vector.com/canape_demo, you can see for
yourself.

Introduction
11

12

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 layer
Depending on the transport layer, one refers to XCP on CAN, XCP on Ethernet, etc. The extend-
ibility 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.1, which was approved in 2008.
Adherence to the following principles was given high priority in designing the protocol:
>  Minimal resource usage in the ECU
>  Efficient communication
>  Simple Slave implementation
>  Plug-and-play 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 sys-
tems with discrete time behavior, whose parameters only change at specific time intervals: 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 time-based process
flows in the ECU and the changing values. These are referred to as event-synchronous measure-
ments. The related mechanisms will be explained later in detail.
Write access lets the user optimize parameters of algorithms in the Slave. The accesses are
address-oriented, 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 model-based development environment to hardware-in-the-loop and
software-in-the-loop 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
XCP
Measurement/
Calibration
Master
Slave
PC
Hardware*
EXE/DLL
Slave
Figure 5:
HIL/SIL Systems
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 benefits
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 further course of this book.
Memory Fundamentals
Today, flash memories are usually integrated in the microcontroller chips for ECUs and are used
for long-term 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 writ-
ing 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 erasure
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 elec-
trons 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 architectural 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 con-
tents. While flash memory serves the purpose of long-term storage of the application, the RAM
is used to buffer computed data and other temporary information. Shutting off the power sup-
ply 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.
// Pseudo-code 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 memory location assigned
to the x parameters. Since this value always needs to be rewritten at runtime, the memory loca-
tion can only lie in RAM.
The parameter y is computed. The values a and b, as factor and offset, are included as informa-
tion 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 possible. 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 linker-
map file is generated by the Linker run and can exist in different formats. Common to all for-
mats, 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 algo-
rithm 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 fundamentals
Read and write accesses to memory contents are available with the mechanisms of the XCP pro-
tocol. The accesses are made in an address-oriented way. Read access enables measurement of
parameters from RAM, and write access enables calibration of the parameters in RAM. XCP per-
mits 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 calibra-
tion concept is addressed in chapter 3.

1.1 XCP Protocol Layer
19
1.1 XCP Protocol Layer
XCP data is exchanged between the Master and Slave in a message-based 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 Packet
XCP Tail
PID FILL
DAQ
TIMESTAMP
DATA
Identification
Timestamp
Data
Field
Field
Field
Figure 6: XCP packet
The 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 STIM
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 Master
XCP Driver
CTO
DTO
CMD
RES
ERR
EV
SERV
DAQ
STIM
Command / Response / Error / Event /
DAQ
STIM
Service Request Processor
Processor
Processor
Bypass
XCP Handler
PGM
CAL
DAQ
STIM
Resources
Figure 8:
XCP Slave
XCP communication
model with CTO/DTO
The 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 contact 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 syn-
chronous measurement and stimulation data.

1.1 XCP Protocol Layer
21
1.1.1 Identification Field
XCP Packet
PID FILL DAQ
TIMESTAMP
DATA
Figure 9:
Identification Field
Message
identification
When 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 chapter
1.3.4 “XCP Packet Addressing for DAQ and STIM”).
1.1.2 Time Stamp
XCP Packet
PID FILL DAQ
TIMESTAMP
DATA
Figure 10:
Time stamp
DTO packets use time stamps, but this is not possible in transmission of a CTO message. The
Slave uses the time stamp to supply time information with measured values. That is, the Mas-
ter 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 lon-
ger important, because the relationship between the measured value and the time point comes
directly from the Slave.
Transmission of a time stamp 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
DATA
Figure 11:
Data field
Data Field
in the XCP packet
Finally, 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 Structure
The Slave receives a command from the Master and must react to it with a positive or negative
response. The communication structure is always the same here:
Command (CMD):
Position
Type Description
0
BYTE
Command Packet Code CMD
1..MAX_CTO-1
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_CTO-1 here.
MAX_CTO indicates the maximum length of the CTO packets in bytes.
Positive response:
Position Type Description
0
BYTE
Command Positive Response Packet Code = RES 0xFF
1..MAX_CTO-1
BYTE
Command specific Parameters

1.2 Exchange of CTOs
23
Negative response:
Position
Type Description
0
BYTE
Error Packet Code = 0xFE
1
BYTE
Error code
2..MAX_CTO-1
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 positively to produce a continuous
point-to-point connection.
Master à Slave: Connect
Slave à Master: Positive response
Connect command:
Position Type Description
0
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 Description
0
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 communication-specific information to the Master when making the connection.
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 Mode
Block Mode
Interleaved Mode
Master
Slave Master
Slave
Master
Slave
Request k
Request k
Part1
Request k
Part2
MIN_ST
Part3
Request k+1
Response k
MAX_BS
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 mode
In 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 command 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 suf-
fices 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 Packet
PID
DATA
Data Field
Identification Field
Timestamp Field
empty for CTO
Figure 13: Overview of the CTO packet structure
The 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 com-
mand. 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 implementation 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 implemented in the Slave, the Slave must
acknowledge with ERR_CMD_UNKNOWN and no further 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 imple-
mented. 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 implemented. 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 Optional
CONNECT  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 Optional
DOWNLOAD  0xF0 No
DOWNLOAD_NEXT 0xEF
Yes
DOWNLOAD_MAX 0xEE
Yes
SHORT_DOWNLOAD 0xED
Yes
MODIFY_BITS 0xEC  Yes
Standard commands:
Command  PID Optional
SET_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 Optional
SET_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 Optional
CLEAR_DAQ_LIST 0xE3
No
GET_DAQ_LIST_INFO 0xD8
Yes
Periodic data exchange – dynamic configuration:
Command  PID Optional
FREE_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 Optional
PROGRAM_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 Description
0
BYTE
Packet Identifier = RES 0xFF
1..MAX_CTO-1
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 Description
0
BYTE
Packet Identifier = ERR 0xFE
1
BYTE
Error code
2..MAX_CTO-1
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 Description
0
BYTE
Packet Identifier = EV 0xFD
1
BYTE
Event code
2..MAX_CTO-1
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 noth-
ing 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 Description
0
BYTE
Packet Identifier = SERV 0xFC
1
BYTE
Service request code
2..MAX_CTO-1
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 Slave
To change a parameter in an XCP Slave, the XCP Master must send the parameter’s location 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 4-byte 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 cannot be transmit-
ted 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 necessary 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 the first message of the Master (highlighted in gray 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 termi-
nating 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 read-out value. This lets the user directly
recognize whether the calibration command was implemented. This command also gets a posi-
tive 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 automatically
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 rewritten.
This, in turn, can only be done as a block. Consequently, it is not simply a matter of writing 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 for-
mats 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 calibra-
tor 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 previous day, the calibra-
tor 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 flashing
Flashing 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 transferred to a C or
H file and be made into the new flash file with another compiler/linker run. However, depend-
ing 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 window
In 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 flashable 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 synchronous
measurement and calibration data. Data from the Slave are sent to the Master by DAQ – synchro-
nous 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. Trigger-
ing 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 transferred to the
application memory.
1.3.1 Measurement Methods: Polling versus DAQ
Before explaining how event-synchronous, 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 DTO-based 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 file
The 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 window
The XCP specification sets a requirement for polling: that the value of each measurement param-
eter must be polled individually. For each value to be measured via polling, two messages 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. How-
ever, 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 computing 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 Acquisition 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 val-
ues 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 parameters 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
Figure 19:
Read sensor X
Calculate Y = X
Events in the ECU
Let’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 event-synchronous measurement method. This is precisely what is implemented 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 measurement 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, time-equidistant event, rather in the case of
an engine controller, for example, it might be angle-synchronous. This makes the time inter-
val between two events dependent on the engine rpm. A singular event, such as activation 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 assign-
ments 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 measured
value to multiple events. Generally, a parameter is only modified within a single cycle (e.g. only
at 10-ms intervals) and not in multiple cycles (e.g. at 10-ms and 100-ms intervals).

Figure 21:
Allocation of
“Triangle” to possible
events in the A2L
Figure 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 configuration
by the user.

Figure 22: Selecting
events (measurement
mode) for each
measurement parameter
After 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 mea-
sured 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 con-
figuration 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 Mas-
ter 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 measurement
Figure 23 illustrates an example of command-response 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. After-
wards, 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 mea-
surement 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. Therefore, 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 important 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 communication model, this mes-
sage 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 DTO
Stated 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 asso-
ciated with a measurement. The XCP Slave begins to acquire the data. It combines the indi-
vidual objects into packets and sends them on the bus. The Master reads the bus message and
can interpret the individual data, because it has defined the allocation of individual 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 trans-
mit the measured values, then the Slave must be able to copy the data into the correct ODT and
the Master must be able to uniquely identify the received ODTs. If multiple measurement inter-
vals of the ECU are used, the relationship between ODT and measurement 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 number 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 ...
3 address, length
PID=2 0 1 2 3 ...
2 address, length
...
PID=1 0 1 2 3 ...
3 address, length
Figure 25:
...
PID=0 0 1 2 3 ...
DAQ list
with three ODTs
For 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.
DAQ lists are subdivided into the types: static, predefined and dynamic.
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 parameters 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 lists
In the above example, there is a DAQ list with the number 0, which is allocated to a 10-ms 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.

40
1 Fundamentals of the XCP protocol
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 application 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 avail-
able 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 practically
never used in ECUs due to the lack of flexibility for the user. It is different for analog measure-
ment systems which transmit their data by XCP: Flexibility is unnecessary here, since the physi-
cal structure of the measurement system remains the same over its life.
Dynamic DAQ lists:
A special aspect of the XCP protocol are the dynamic DAQ lists. It is not the absolute parameters
of the DAQ and ODT lists that are permanently defined in the ECU code here, but just the param-
eters of the memory area that can be used for the DAQ lists. The advantage is that the measure-
ment 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
DAQ
ALLOC_
ALLOC_ODT_ENTRY
ODT_ENTERIES_COUNT
T
ALLOC_OD
GRANULARITY_ODT_ENTRY_SIZE_DAQ
Figure 27:
ODT_COUNT
Dynamic DAQ lists
In 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.

1.3 Exchanging DTOs – Synchronous Data Exchange
41
1.3.3 STIM Calibration Method
The 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 STIM
If the Master sends data to the Slave by STIM, the XCP Slave must be informed of the location in
the packets at which the calibration parameters can be found. The same mechanisms are used
here as are used for the DAQ lists.

42
1 Fundamentals of the XCP protocol
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 pre-
sented 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 Packet
Identification Field Timestamp Field
Data Field
PID
PID DAQ
TS
PID
DAQ
TS
Figure 29:
Structure of the
PID FILL
DAQ
TIMESTAMP
DATA
XCP packet for DTO
transmissions
Transmission 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 trans-
formation step that utilizes a so-called “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.
DAQ list: 0
≤ PID ≤ k
DAQ list: k + 1  ≤ PID ≤ m
DAQ list: m + 1 ≤ PID ≤ n
etc.

1.3 Exchanging DTOs – Synchronous Data Exchange
43
In this case, the identification field is very simple:
Identification Field
PID
Figure 30:
Identification field
absolute ODT number
with absolute
ODT numbers
Transmission 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 Identi-
fication Field. However, there is still space left over in the number of bytes that is available for
the information:
Identification Field
PID DAQ
Figure 31:
ID field with
absolute DAQ List number
relative ODT and
relative ODT number
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
Figure 32:
ID field with
absolute DAQ list number
relative ODT and
relative ODT number
absolute DAQ
numbers (two bytes)

44
1 Fundamentals of the XCP protocol
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
Figure 33:
absolute DAQ list number
ID field with relative
for alignement
ODT and absolute DAQ
numbers as well as fill
relative ODT number
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 represents
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.4 XCP Transport Layers
45
1.4 XCP Transport Layers
A main requirement in designing the protocol was that it must support different transport lay-
ers. 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 E-Learning platform, as well as an introduction to AUTOSAR. For details see the website
www.vector-elearning.com.
1.4.1 CAN
XCP was developed as a successor protocol of the CAN Calibration Protocols (CCP) and must
therefore 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 already being used.
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:
Data
CAN
CAN
CAN
CAN
Frame
Node A
Node B
Node C
Node D
ID=0x12
Sender
Receiver
ID=0x34
Sender
Receiver
Receiver
ID=0x52
Receiver
Sender
ID=0x67
Receiver
Receiver
Sender
Receiver
ID=0xB4
Receiver
Sender
Figure 34:
Definition of which
ID=0x3A5
Sender
Receiver
Receiver
Receiver
bus nodes send
which messages
The message with ID 0x12 is sent by CAN node A and all other nodes on the bus receive this mes-
sage. 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 higher-
level layers need the message and they provide them via the Rx buffer. The CAN nodes are inter-
linked as follows:

46
1 Fundamentals of the XCP protocol
CAN Node A
CAN Node B
Host
Host
CAN Interface
CAN Interface
Tx
Rx
Tx
Rx
Buffer
Buffer
Buffer
Buffer
Acceptance
Acceptance
Test
Test
Send
Receive
Send
Receive
CAN
Receive
Send
Receive
Send
Acceptance
Acceptance
Test
Test
Rx
Tx
Rx
Tx
Buffer
Buffer
Buffer
Buffer
CAN Interface
CAN Interface
Host
Host
Figure 35:
Representation
CAN Node C
CAN Node D
of a CAN network
The 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 con-
tents change as well. Nonetheless, there is a relationship between the communication 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” communication. 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 mes-
sage from Master to Slave (direction Tx) and 555 for sending messages from the Slave to the
Master (direction Rx).

1.4 XCP Transport Layers
47
Figure 36: Example of XCP-on-CAN communication
In 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, how-
ever, 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 37: Representation of an XCP-on-CAN message
In CANape, you will find an XCP-on-CAN 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.

48
1 Fundamentals of the XCP protocol
1.4.2 CAN FD
CAN 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 networks while pre-
serving valuable experience gained from CAN development.
The XCP-on-CAN-FD specification was defined in the XCP-on-CAN description of the XCP stan-
dard, Version 1.2.0 (June 2013).

Figure 38: Illustration of a CAN FD frame
Despite the largely similar modes of operation, this protocol requires extensions and modifica-
tions 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
49
A recessive EDL bit (High level) distinguishes frames in extended CAN-FD format from those in
standard CAN format, because they are identified by a dominant EDL bit (low level). Similarly, 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 use-
ful data in the A2L file. This is fully transparent to the user, who gets a complete A2L parameter-
ization. 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.

50
1 Fundamentals of the XCP protocol
1.4.3 FlexRay
A basic idea in the development of FlexRay was to implement a redundant system with deter-
ministic time behavior. The connection redundancy was achieved by using two channels: chan-
nel A and channel B. If multiple FlexRay nodes (= ECUs) are redundantly interconnected 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 39: Nodes K and L are redundantly interconnected
Deterministic 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 combined 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 40: Communication by slot definition

1.4 XCP Transport Layers
51
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 description of the
FlexRay bus. FIBEX is an XML format and the XCP-on-FlexRay specification relates to FIBEX Ver-
sion 1.1.5 and FlexRay specification Version 2.1.
Cycles
Slot
ECU
Channel
0
1
2
3
4
5
6
...
63
A
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
B
b  [rep :  1 ]
b  [rep :  1 ]
b  [rep :  1 ]
b  [rep :  1 ]
b  [rep :  1 ]
b  [rep :  1 ]
b  [rep :  1 ]

b  [rep :  1 ]
A
c  [rep :  4 ]
x  [rep :  2 ]
y  [rep :  4 ]
x  [rep :  2 ]
c  [ c
rep :  4 ]
x  [rep :  2 ]
y  [rep :  4 ]

x  [rep :  2 ]
2
Node M
B

A
a  [rep :  1 ]
a  [rep :  1 ]
a  [rep :  1 ]
a  [rep :  1 ]
a  [rep :  1 ]
a  [rep :  1 ]
a  [rep :  1 ]

Static Segment
a  [rep :  1 ]
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 ]
5
B

A
6
Node 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  [r
ep :  2 ]
B

Dynamic Segment
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 41: Representation of a FlexRay communication matrix
Another format for describing bus communication has been defined as a result of the develop-
ment of AUTOSAR solutions: the AUTOSAR Description File, which is available in XML format. The
definition of XCP-on-FlexRay was taken into account in the AUTOSAR 4.0 specification. 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 specify
that a certain piece of information is only sent in the slot in every second pass.

52
1 Fundamentals of the XCP protocol
Instead of indicating the pure slot number, “FlexRay Data Link Layer Protocol Data Unit Identi-
fiers” (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
Cycle ID . . . . . . . . . .   .  . . ...
.
. . . . .
. .. .. .. .. .. .. .. .. ..
.. .. .. .. ..
.. . . . . . . . . .   .  . . . . . . .
. .. .. .. .. .. .. .. .. ..
.
...
. .. .. .. ..
... ...
... ...
...
Figure 42:
Representation of
Slot ID
the FlexRay LPDUs
Scheduling also has effects on the use of XCP on FlexRay, because it defines what is sent pre-
cisely. 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 Mas-
ter 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. XCP-on-FlexRay 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 function through
combination of the two files, i.e. by having an A2L file reference a FIBEX file.

1.4 XCP Transport Layers
53
Excerpt of an A2L with XCP-on-FlexRay 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
Cycle ID . . . . . . . . . .   .  . . ...
.
. . . . .
. .. . .
. . .. . .
. . .. .. ..
.. .. .. .. ..
.. . . . . . . . . .   .  . . . . . . .
. .. .. .. .. .. .. .. .. ..
.
...
. .. .. .. ..
... ...
... ...
Figure 43:
...
Allocation of
XCP communication
Slot ID
to LPDUs
You 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 XCP-on-FlexRay device in CANape.
The protocol is explained in detail in ASAM XCP on FlexRay Part 3 Transport Layer Specification.
You will find an XCP-on-FlexRay demo in CANape with the virtual ECU XCPsim. The demo requires
real Vector FlexRay hardware.
1.4.4 Ethernet
XCP 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 protection mech-
anism. 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 different resources
are available here compared to an ECU (CPU, memory, etc.).

54
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
LEN
CTR
(TCP/IP and UDP/IP)
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 44: XCP packet with TCP/IP or UDP/IP
The 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 protocol. If a packet
is lost, this is not recognized by the protocol layer. Packet loss is monitored by counter infor-
mation. 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 mea-
sured data is to be used as the basis for fast control, 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 con-
trol field.
You will find more detailed information on the protocol in ASAM XCP on Ethernet Part 3 Trans-
port 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 implemented by Simulink
models and the Simulink Coder.

1.4 XCP Transport Layers
55
1.4.5 SxI
SxI is a collective term for SPI or SCI. Since they are not buses, but instead are controller inter-
faces which are only suited for point-to-point 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 45: XCP-on-SxI packet
The 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 indi-
cates 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 information. 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 XCP-on-LIN standard. However, a solution exists from
Vector (XCP-on-LIN driver and CANape as XCP-on-LIN 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.

56
1 Fundamentals of the XCP protocol
1.5 XCP Services
This 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 Swapping
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 swapping memory segment pages from RAM and Flash. XCP describes a somewhat more gen-
eral, generic approach, in which a memory segment may contain multiple swappable 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 swapping, the concepts of sector, seg-
ment and page will be explained once again at this point.
XCP access
Segment 1
Segment 1
Segment 1
2
Page 0
Page 1
Page 2
Segmemt 1
Sector
ECU access
Segment 0
Page 0
1
Segmemt 0
Sector
0
Figure 46:
Sector
address
Memory
representation

1.5 XCP Services
57
From an XCP perspective, the memory of a Slave consists of a continuous memory that is
addressed with a 40-bit 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 memory can only
be erased a block at a time.
The logical structure is based on what are known as segments; they describe where calibration
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 segment 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 indi-
vidually 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. Similar to the nam-
ing 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 exam-
ple, the XCP Slave may not access a page, if this page is currently active for the ECU. As men-
tioned, 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 swapping. These two commands let the Master poll which pages
are currently being used and if necessary it can swap pages for the ECU and XCP access. The XCP
Master has full control over swapping of pages. The XCP Slave cannot initiate swapping by itself.
But naturally the Master must respect any restrictions of the Slave implementation.
What is the benefit of swapping?
First, swapping permits very quick changing of entire parameter sets – essentially a before-and-
after comparison. Second, the plant remains in a stable state, while the calibrator performs
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 parameter setting.

58
1 Fundamentals of the XCP protocol
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 nonvola-
tile 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 sections),
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 47:
Representation
of driver settings
for the flash area

1.5 XCP Services
59
Flashing can be implemented using what are referred to as “flash kernels”. A flash kernel is exe-
cutable code that is sent to the Slave’s RAM area before the actual flashing; the kernel then han-
dles 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 per-
manently 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)
>  Post-processing (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
process-specific elements, such as serial number handling with meta-data, 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 end-of-line 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 acknowl-
edged 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 available 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 non-
compressed and non-encrypted 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.

60
1 Fundamentals of the XCP protocol
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 protocol-specific 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 communication
options of the Slave, e.g. whether it supports block transfer or interleaved mode or which mini-
mum 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 memory 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: num-
ber 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: max-
imum number of parameters for an ODT for DAQ and for STIM, granularity of the ODT entries,
number of bytes in time stamp transmission, etc.
GET_DAQ_EVENT_INFO
When this command is used, the call is made once per ECU event. Information is transmitted
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.

1.5 XCP Services
61
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 reasons, 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
Figure 48:
Representation
Time
of the block
transfer mode
The 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.

62
1 Fundamentals of the XCP protocol
1.5.6 Cold Start Measurement (start of measurement during power-on)
Even with the capabilities of XCP described to this point, it would be impossible to implement
an event-driven 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 measurement 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 configuration 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 nonvolatile
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”.

1.5 XCP Services
63
1.5.7 Security Mechanisms with XCP
An unauthorized user should be prevented as much as possible from being able to make a con-
nection to an ECU. The “seed & key” method is available for checking whether or not a connec-
tion 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 algorithm to gen-
erate 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 communication 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 normally 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 implementa-
tion-specific and independent of the XCP specification.

64

2 ECU Description File A2L
65
2 ECU Description File A2L

66
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 differential compo-
nents, then the calibrator should be able to access these parameters with their symbolic names.
Let us take the following figure as an example:
Figure 49:
Parameters in
a calibration window
The user can conveniently modify values using symbolic names. Another example is provided by
viewing signal variables that are measured from the ECU:
Figure 50: Signal response over time

In 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 val-
ues. 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
67
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 visu-
alize a simple example of such a conversion rule in a sensor that has an 8-bit value. The numeric
values output by the sensor lie between 0 and 255, but you wish to see the value as a percent-
age value. Mapping of the sensor value [0 … 255] to [0 … 100 %] is performed with a conver-
sion 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 uti-
lize a proximity sensor such as a Hall sensor, which determines distance as a function of mag-
netic 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 compu-
tations. 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 controller’s runtime, rather
the map returns the result y to the input variable x. It may be necessary 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 val-
ues? 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 parame-
ters, the direct look at the physical values and access to complex elements such as characteris-
tic 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 cal-
ibration tool needs to communicate with the ECU.

68
2 ECU Description File A2L
2.1 Setting Up an A2L File for an XCP Slave
The A2L file is an ASCII-readable file, which describes the following with the help of keywords:
>  Interface-specific 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
READ_ONLY
BYTE_ORDER MSB_LAST
FORMAT “%.0”

2.2 Manually Creating an A2L File
69
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 File
The 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 linker-map 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 character-
istic maps etc.
Let us begin by creating an empty A2L and the communication parameters: If you wish to cre-
ate an A2L that describes an ECU with an XCP-on-CAN interface, for example, you create a new
device in CANape and select XCP on CAN as the interface. Then you can supplement this with
other communication-specific 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 defini-
tions of the actual measurement and calibration parameters.

70
2 ECU Description File A2L
In the A2L Editor (available as part of CANape or as a separate tool), the linker-map file is asso-
ciated 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 linker-map 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 gen-
erate an A2L from a C code, other tools are available for automatic processing.
On the Vector homepage you will find information on the “ASAP2 Tool-Set” with which you can
automate the generation of A2Ls from the source code in a batch process.
2.3 A2L Contents versus ECU Implementation
When an XCP Master tool reads in an A2L that does not fully match the ECU, misunderstandings
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 implemented 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
71
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, num-
ber 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 predefined
DAQ lists …

72

3 Calibration Concepts
73
3 Calibration Concepts

74
3 Calibration Concepts
ECU parameters are constant parameters that are adapted and optimized during the develop-
ment 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 capabilities
and resources of the microcontroller that is used.
Normally, parameters are stored in the production ECU’s flash memory. The underlying program
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 initially
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 simultaneously stored
in RAM? How are the parameters copied back into flash? Are changes to the parameters persis-
tent, i.e. are they preserved when the ECU is turned off?
A distinction is made between transparent and non-transparent calibration concepts. Transpar-
ent 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 Flash
The software developer defines in the source code whether a parameter is a variable or a con-
stant, 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 linking
of the code, memory space is provided in flash for the “factor” object. The object is allocated
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 linker-map file.
The simplest conceivable calibration concept involves modifying the value in C code, generating
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 subsequent 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
75
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 exam-
ple and therefore do not appear at all in the linker-map file. Usually, one does not want to leave
to chance where a constant is created in flash memory. The necessary means for accomplish-
ing this are almost always compiler-specific pragma instructions. To prevent the compiler from
embedding them in the code, it is generally sufficient to use the “volatile” attribute for con-
stant 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 microcontrollers
are able to program their flash themselves, which is necessary for the purposes of re-program-
ming 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 contrast to
flash memories, EEPROM memories can erase and program each memory cell individually. The
amount of available EEPROM memory is always considerably less than the available flash mem-
ory and it is usually limited to just a few kilobytes. EEPROM memory is often used to store pro-
grammable parameters in the service shop or to implement a persistence 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 param-
eters 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 conceiv-
able with this method.
In both cases, the relevant memory accesses would then be intercepted in the software com-
ponents 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.

76
3 Calibration Concepts
3.2 Parameters in RAM
The most frequently used approach to modifying parameters at runtime (“online calibration”) 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 compil-
ing and linking of the code, memory space is reserved for the object “factor” in RAM and the
associated RAM address appears in the linker-map 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 linker-map
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 start-up code of the compiler producer and the
application programmer does not need to be concerned with it. The application uses the val-
ues 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. Normally,
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
Figure 51:
Parameters
Initial parameter
setting in RAM
The calibration RAM does not need to consist of a fully contiguous RAM area. It may also be dis-
tributed into multiple areas or even in any desired way. Nonetheless, it offers significant advan-
tages 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 espe-
cially 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 parameters that were mod-
ified offline into the ECU during the transition from offline calibration to online calibration.

3.2 Parameters in RAM
77
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 loading process may be
time optimized by limiting the number of necessary transmissions to a minimum. It is advanta-
geous 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 differences between the cal-
ibration 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 val-
ues 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 ini-
tial values in flash. A prerequisite is that the RAM memory segment must be initialized by copy-
ing from an identically laid out memory segment in flash, as is the usual practice in most com-
pilers/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 param-
eter 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 param-
eters in the hex file.

78
3 Calibration Concepts
3.3 Flash Overlay
Many microcontrollers offer options for overlaying memory areas in flash with internal or exter-
nal 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 precisely serve
this purpose. In this case the parameters are created as parameters in flash just as in calibra-
tion 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 linker-map 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 lightning-quick swap-
ping 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 swapping with special
commands.
>  The memory pages might be swapped 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 application
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 down-
load 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
79
3.4 Dynamic Flash Overlay Allocation
The concepts for calibration RAM described so far are unproblematic if sufficient RAM is avail-
able for all parameters. But what if the total number of parameters does not fit into the avail-
able 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 transparent to the cal-
ibration 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 swapping 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 avail-
able RAM blocks can be used as efficiently as possible. The software developer 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 particular function are fully ready
for use.

80
3 Calibration Concepts
3.5 RAM Pointer Based Calibration Concept per AUTOSAR
This concept does not require 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 similar-
ity to the previous concept. The primary difference is that the substitution of flash for RAM is
not implemented by hardware mechanisms, but by software mechanisms instead. The calibra-
tion parameters are always referenced by pointers from the ECU software. Flash or RAM con-
tents are accessed by changing this pointer. The flash parameters 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 calibra-
tion tool can explicitly select the parameters to be modified by preselecting the desired param-
eters. The advantage of this is that resource utilization and loading are 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 Concept
The pointer table is located in RAM. When booting the ECU, all pointers indicate the parame-
ter 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
Figure 52:
Parameters
Initial situation
after booting
When 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 deter-
mines 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
81
FLASH
Pointertable
RAM
Figure 53:
Parameters
Pointer change and
copying to RAM
The 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 measurement. The dis-
advantage of this method is that an entry in a pointer table must be available for each parame-
ter 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 con-
tained in an ECU’s flash area. The RAM addresses and parameter values in RAM are also already
changed in the pointer table.
Parameter Flash
Pointertable
RAM
Addr.
Content
Addr.
Addr.
Content
P 0x0000100A  0x11
0x000A100A
0x000A100A 0x44
I
0x000012BC  0x22
0x000A100B
0x55
0x000A100B
D 0x00007234  0x33
0x000A100C
0x000A100C
0x66
Figure 54: Pointer table for individual parameters
Calibration concepts are very important, because RAM resources are scarce. Large RAM pointer
tables would make a concept self-defeating.
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 importance here.
With large structures only a few pointers are necessary. In turn, this means that with the deci-
sion 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.

82
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 cali-
bration 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 structure, 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 structure A.
However, since the space in RAM is inadequate for this, the user indeed has access to the param-
eters 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 Imple-
mentation” under <Installation DIR>\Samples\CAN\CAN MPC55xx\XCPDemo.
3.5.2 Double Pointer Concept
A disadvantage of the single pointer concept is that memory page swapping is not easy to imple-
ment. The calibration tool could simply describe the pointer table completely for page swap-
ping, but this is not feasible in a short period of time without resulting in temporary inconsis-
tencies and side effects. A tool-transparent implementation would double the memory space
requirement for the pointer table, because when swapping 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 consistent
swapping, 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.6 Flash Pointer Based Calibration Concept
83
Figure 55 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
Figure 55:
Tablepointer
Double pointer concept
The parameter values are initially accessed via the table pointer. If the table pointer indicates
the pointer table in RAM, the application essentially accesses the actual parameters via the con-
tents 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 pointer-based concept of AUTOSAR. Here
too, the application in the ECU accesses parameter data using a pointer table. However, this
pointer table is not located in RAM, but in flash instead. Changes to the pointer table can there-
fore only be made by flash programming. A tool-transparent implementation is not possible.
The advantage lies in the RAM memory that is saved since it no longer contains 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.

84

4 Application Areas of XCP
85
4 Application Areas of XCP

86
4 Application Areas of XCP
When ECU calibrators think about the use of XCP, they are usually fixated on use of the proto-
col in the ECU.
Simulink
Slave
Prototype or
ECU Hardware
Slave
XCP
Measurement/
Calibration
Master
Slave
PC
Hardware*
EXE/DLL
Slave
HIL/SIL Systems
Slave
Figure 56:
Application areas and
* Debug Interfaces, Memory Emulator, ...
application cases
In 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
Controlled Variable
Controller
Plant
(Set Value)
(Actual Value)
Figure 57: Plants and controllers
In 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
87
4.1 MIL: Model in the Loop
Simulink
Controller Model
Plant Model
Figure 58:
Model in the Loop
in Simulink
In 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 devel-
opment 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 windows, access to
characteristic curves and maps and much more.
Simulink
Controller Model
Plant Model
CANape
Figure 59:
CANape as
Simulink
measurement and
XCP Server
A2L
calibration tool with
Simulink models
Neither 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 developer uses the
Simulink Debugger in the model to step through the model, CANape still takes the time trans-
mitted via XCP as the reference time.

88
4 Application Areas of XCP
4.2 SIL: Software in the Loop
Simulink
Controller Model
Plant Model
Code generation
Figure 60:
Controller Model
Software in the
Windows DLL
Loop with Simulink
environment
In this development step, code is generated from the model of the controller, which is then
used in a PC-based runtime environment. Naturally, the controller may also have been devel-
oped without any sort of model-based 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 applica-
tion were already integrated in an ECU.
Simulink
Controller Model
Plant Model
Code generation
Controller Model
CANape
Windows DLL
A2L
Figure 61:
CANape as SIL
development platform

4.3 HIL: Hardware in the Loop
89
4.3 HIL: Hardware in the Loop
Many different kinds of HIL systems are available. They range from very simple, cost-effective
systems all the way to very large and expensive expansion stages. The following figure shows
the rough concept:
Controller Model
HIL Platform
I/O
Plant Model
Figure 62:
ECU
HIL solution
The controller algorithm runs in a microcontroller platform (e.g. the ECU), while the plant con-
tinues 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 Model
A2L
HIL Platform
I/O
CANape
Figure 63:
Plant Model
HIL with CANape
as measurement
ECU
and calibration tool
From CANape, the user has access to the algorithms in the ECU over XCP.

90
4 Application Areas of XCP
The Vector Tool CANoe is also used by many customers as a HIL system. With CANoe, a HIL sys-
tem might look like this:
CANoe RT User PC
Ethernet
CANoe RT Server
CAN
LIN
Plant Model
MOST
A2L
FlexRay
Digital I/O
Analog I/O
XCP
CANape
Figure 64:
ECU
CANoe as HIL system
The ability to access XCP data directly from CANoe for testing purposes results in the following
variant as well:
CANoe RT User PC
A2L
Ethernet
CANoe RT Server
CAN
LIN
Plant Model
XCP
MOST
FlexRay
Digital I/O
Analog I/O
Figure 65:
CANoe as HIL
system with XCP
ECU
access to the ECU
Here the model of the plant runs on the CANoe real-time 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.4 RCP: Rapid Control Prototyping
91
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
CANape
Plant Model
A2L
Windows DLL
XCP
Plant
A2L
XCP
ECU
Figure 66: CANape as HIL solution
4.4 RCP: Rapid Control Prototyping
In this development phase, the control algorithm runs on real-time hardware instead of an ECU.
This situation often occurs when the necessary ECU hardware is not yet available. Several plat-
forms come in question as suitable hardware: from simple evaluation boards all the way to spe-
cial automotive-level 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 Model
CANape
EVA Board
A2L
XCP
I/O
Plant
Figure 67: RCP solution
The 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.

92
4 Application Areas of XCP
In the literature, the RCP approach is frequently subdivided into two areas: fullpassing and
bypassing.
As depicted in Figure 67, the entire controller runs on separate real-time hardware. This method
is known as fullpassing, because the entire controller runs on the controller hardware. 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 software
(e.g. network management) are needed to enable functionality in a more complex network.
However, if a complete ECU is used for Rapid Control Prototyping instead of a general control-
ler 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 dis-
advantage lies in the high degree of complexity.
The concept of bypassing was developed to exploit the advantages of the ECU infrastructure
without being burdened by the disadvantages of high complexity.
4.5 Bypassing
In Figure 68, the ECU is connected to the plant. The necessary I/O and software components 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.

ECU
A2L
XCP
Bypassing Hardware
CANape
Bypassing
Hardware
A2L
XCP
I/O
Controller Model
ECU
Plant
Figure 68: Basic principle of bypassing

4.5 Bypassing
93
The 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 illustrates the sche-
matic flow:
Bypassing Hardware
Algorithm A1
2.
Bypassing
Coordinator
3.
1. XCP 4.
Algorithm A
ECU
Figure 69:
Bypassing flow
Depicted 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. In step 1, the bypassing coordinator accepts the data and in step 2 it passes the data to
algorithm A1. A1 is computed by the bypassing hardware and in step 3 the result is passed back
to the bypassing coordinator; in step 4, it is transmitted to the ECU by STIM. The data is written
to the “location” at which the next function block in the Slave expects its input variables. This
makes it possible to use the value computed by algorithm A1 and not from A in the ECU’s over-
all control process. This method permits using a combination of the rapid substitution of algo-
rithms on the bypassing hardware that incorporates the I/O and the ECU’s basic software.

94
4 Application Areas of XCP
Of course, the performance limits of an XCP-on-CAN driver also affect bypassing. If short bypass-
ing times are needed, access to the ECU by DAQ and STIM may also be performed via the con-
troller’s debugging or trace interfaces. The Vector VX1000 measurement and calibration hard-
ware converts the data into an XCP-on-Ethernet data stream from the controller interface. In
this process, up to one megabyte of data can be transported into the ECU.
XCP
Bypassing
Bypassing Hardware
CANape
Hardware
A2L
XCP
Measurement & Calibration
Hardware VX1000
Debugging and Trace Interface
I/O
Controller Model
ECU
Plant
Figure 70: Bypassing with real-time bypassing hardware and fast ECU access

4.6 Shortening Iteration Cycles with Virtual ECUs
95
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 connection to a real system
exists. It can run significantly faster – depending on the PC’s computing 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, exe-
cution 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 simultaneously measured out and
saved to a measurement file.
Para-
MDF
meter
test drive
Application
5. Analyze
1. Set parameters
2. Start
Simulink/
CANape
DLL
3. Send test drive data
4. Measurement data
Slave
Figure 71:
New
Short calibration
MDF
cycles with
virtual ECUs

96
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.

CANape
Application as EXE or DLL on PC
Parameterization
Set values in
via XCP
workspace
Start
Start
Send measurement
data
Calculate model
Receive new
Send measurement
measurement data
values from the model
Analyze the
End model calculation
new data
Figure 72:
New software version
Process flow
with virtual ECUs
To 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 performs 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 optimi-
zation tool such as MATLAB over the CANape automation interface.

4.6 Shortening Iteration Cycles with Virtual ECUs
97

98

5 Example of an XCP Implementation
99
5 Example of an XCP Implementation

100
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 down-
load free of charge at the Download Center of the Vector website (www.vector.com/xcp-driver).
This packet also contains some sample implementations for various transport layers and tar-
get platforms. The driver consists of the protocol-Layer 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 communication
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
101
Application
r
t
t
XcpEvent
XcpIni
XcpBackground
ApplXcpGetPointe
XCP Protocol Layer
ion - XCP Transpor
k
at
Layer Interface
d
Applic
ommand
ApplXcpSen
XcpC
XcpSendCallbac
XCP Transport Layer
Physical Layer
Figure 73:
Incorporating
Bus
the XCP Slave
in the ECU code
The 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 40-bit values (32-bit address, 8-bit
address extension), the XCP driver uses the function ApplXcpGetPointer() to obtain a pointer
from a A2L-conformant address.
These interfaces are sufficient to integrate basic functionalities for measurement and calibra-
tion. Other interfaces are only needed for extended functions such as page swapping, identifi-
cation or seed & key. They are described in detail in documentation for the driver.

102
5 Example of an XCP Implementation
5.1 Description of Functions
void 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 infor-
mation on measured values and events originates from the A2L. The desired measurement con-
figuration 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 10-ms task
XcpEvent (2);
// Event 2 stands for the 100-ms task
XcpEvent (5);
// Event 5 stands for the 1-ms 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
103
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 parameter
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 protocol 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() indicates
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, ApplXcpSend() is called
directly from XcpSendCallBack().
BYTE *ApplXcpGetPointer (BYTE addr_ext, DWORD addr)
Task:
Convert an A2L-conformant address to a pointer.
Description:
The function maps the 40-bit A2L-conformant addressing (32-bit address + 8-bit address exten-
sion) 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.

104
5 Example of an XCP Implementation
5.2 Parameterization of the Driver
In 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 Motorola-CPU (Big Endian). The remaining parameters activate the functionalities: mea-
surement, 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 mem-
ory is indicated for the measurement (here 512 bytes). The memory is primarily needed to store
the DAQ lists and to buffer the data during the measurement. The parameter therefore deter-
mines the maximum possible number of measurement signals. In the driver documentation you
will find more detailed information on estimating the necessary parameters.

5.2 Parameterization of the Driver
105

106
The Authors
The Authors

Andreas Patzer
Mr. 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
107

Rainer Zaiser
Mr. 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.

108
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
PID
Packet Identifier
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
Time Stamp
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
109
Literature
XCP 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.net
Web Addresses
Standardization committees:
>  ASAM, XCP protocol-specific documents, A2L specification, www.asam.net
Supplier 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

110
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: Time stamp
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
39
Figure 27: Dynamic DAQ lists
40
Figure 28: Event for DAQ and STIM
41
Figure 29: Structure of the XCP packet for DTO transmissions
42
Figure 30: Identification field with absolute ODT numbers
43
Figure 31: ID field with relative ODT and absolute DAQ numbers (one byte)
43
Figure 32: ID field with relative ODT and absolute DAQ numbers (two bytes)
43
Figure 33: ID field with relative ODT and absolute DAQ numbers as well as fill byte

(total of four bytes)
44
Figure 34: Definition of which bus nodes send which messages
45
Figure 35: Representation of a CAN network
46
Figure 36: Example of XCP-on-CAN communication
47
Figure 37: Representation of an XCP-on-CAN message
47
Figure 38: Illustration of a CAN FD frame
48
Figure 39: Nodes K and L are redundantly interconnected
50
Figure 40: Communication by slot definition
50
Figure 41: Representation of a FlexRay communication matrix
51
Figure 42: Representation of the FlexRay LPDUs
52
Figure 43: Allocation of XCP communication to LPDUs
53
Figure 44: XCP packet with TCP/IP or UDP/IP
54

Table of Figures
111
Figure 45: XCP-on-SxI packet
55
Figure 46: Memory representation
56
Figure 47: Representation of driver settings for the flash area
58
Figure 48: Representation of the block transfer mode
61
Figure 49: Parameters in a calibration window
66
Figure 50: Signal response over time
66
Figure 51: Initial parameter setting in RAM
76
Figure 52: Initial situation after booting
80
Figure 53: Pointer change and copying to RAM
81
Figure 54: Pointer table for individual parameters
81
Figure 55: Double pointer concept
83
Figure 56: Application areas and application cases
86
Figure 57: Plants and controllers
86
Figure 58: Model in the Loop in Simulink
87
Figure 59: CANape as measurement and calibration tool with Simulink models
87
Figure 60: Software in the Loop with Simulink environment
88
Figure 61: CANape as SIL development platform
88
Figure 62: HIL solution
89
Figure 63: HIL with CANape as measurement and calibration tool
89
Figure 64: CANoe as HIL system
90
Figure 65: CANoe as HIL system with XCP access to the ECU
90
Figure 66: CANape as HIL solution
91
Figure 67: RCP solution
91
Figure 68: Basic principle of bypassing
92
Figure 69: Bypassing flow
93
Figure 70: Bypassing with real-time bypassing hardware and fast ECU access
94
Figure 71: Short calibration cycles with virtual ECUs
95
Figure 72: Process flow with virtual ECUs
96
Figure 73: Incorporating the XCP Slave in the ECU code
101

112
Appendix – XCP Solutions at Vector
Appendix – XCP Solutions at Vector
Vector 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 simul-
taneously 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 that is also available as a stand-alone tool).
>   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 XCP-on-Ethernet 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 ben-
efits from a high measurement data throughput rate of up to 30 Mbyte/sec and short measure-
ment 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/xcp-driver, only contains basic XCP functions.
Configuration of the XCP protocol and modification of the transport layer are performed man-
ually 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 AUTO-
SAR 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 Funda-
mentals 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.

Appendix – XCP Solutions at Vector
113
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 proprietary pro-
tocols in CANape. A code generator supports you in creating the XCP-specific share of such a
driver.

114
Index
Index
A
F
A2L
9, 10, 25, 33, 35, 39, 40, 41, 52,  FIBEX
51, 52, 53

53, 57, 58, 63, 65, 66, 67, 68, 69,  Flash memory
16, 17, 56, 57, 58, 59, 62

70, 88, 102, 103, 108
FLX_CHANNEL
52
Address extension
29, 33, 38, 101, 103
FLX_LPDU_ID
52
AML
25, 68, 108
FLX_SLOT_ID
52
ASAM
7, 8, 9, 55, 108
Fullpassing
92
ASAP2 Tool-Set
70
G
B
GET_CAL_PAGE
25, 57
Bandwith optimization
34
GET_DAQ_PROCESSOR_INFO
44, 60, 71
Bus load
34
BYP
108
H
Bypassing
44, 92, 93, 94
HIL
86, 89, 90, 91
C
L
CAN
7, 8, 14, 24, 29, 33, 38, 45, 46, 47,  Linking
74, 88

51, 69, 94, 108
LPDU
52
CAN FD
48
CANape
95
M
CANoe
95
MIL
87
CANoe.XCP
95
MTA
30, 108
CCP
7, 8, 39, 45, 108
CMD
20, 25, 52, 108
O
Compiling
95
ODT
37, 38, 39, 40, 42, 43, 44, 60,
CTO
20, 21, 22, 25, 108

71, 108
CTR
54, 55, 108
OFFSET
52
CYCLE_REPETITION
52
P
D
PAG
108
DAQ
22, 32, 33, 34, 35, 36, 37, 38,  Page
95

39, 40, 41, 42, 43, 44, 60, 62, 71,  PGM
108

93, 94, 100, 102, 108
PID
8, 19, 21, 25, 42, 108
DBC
45
Polling
33, 34, 36
DOWNLOAD
30, 31, 61
DTO
20, 21, 22, 33, 37, 38, 42, 108
R
RAM
16, 17, 18, 30, 31, 37, 38, 39,
E

58, 62, 74, 76, 79, 80, 82
ECU
9, 68, 90, 92, 93, 108
Reboot
32
EEPROM
16, 31, 62
RES
20, 21, 28, 52, 108
ERR
20, 25, 28, 108
EV
29, 108
Event
35, 39, 41, 60, 62, 71, 102

Index
115
S
Segment
57, 58
SEGMENT_NUMBER
57
SERV
29, 108
SET_CAL_PAGE
25, 57
SHORT_UPLOAD
30, 33, 61
SIL
86, 88
STIM
33, 41, 42, 44, 60, 71, 93,

94, 95, 108
Stimulation
29, 63, 95
T
Task
102
TCP/IP
53, 54, 108
U
UDP/IP
53, 54, 108
USB
55, 108
V
VN8900
95
VX
94
VX1000
95

Get more Information!
Visit our Website for:
> News
> Products
> Demo Software
> Support
> Trainings Classes
> Addresses
www.vector.com
14
V 2.0 4/20