XCP

Version 1.1

Part 3 - XCP on CAN - Transport

Layer Specification
Part 3 – XCP on CAN – Transport Layer Specification

Association for Standardisation of

Automation and Measuring Systems
Dated: 31-03-2008
© ASAM e. V.
Part 3 - XCP on CAN - Transport Layer Specification

Status of Document

Date: 31-03-2008
Author: Roel Schuermans, Vector Informatik GmbH
Andreas Zeiser, Vector Informatik GmbH
Oliver Kitt, Vector Informatik GmbH
Hans-Georg Kunz, VDO Automotive AG
Hendirk Amsbeck, dSPACE GmbH
Bastian Kellers, dSPACE GmbH
Boris Ruoff, ETAS GmbH
Reiner Motz, Robert Bosch GmbH
Dirk Forwick, Robert Bosch GmbH
Version: Version 1.1
Doc-ID:
Status: Release
Type

Disclaimer of Warranty
Although this document was created with the utmost care it cannot be guaranteed that it is
completely free of errors or inconsistencies.
ASAM e.V. makes no representations or warranties with respect to the contents or use of
this documentation, and specifically disclaims any expressed or implied warranties of
merchantability or fitness for any particular purpose. Neither ASAM nor the author(s)
therefore accept any liability for damages or other consequences that arise from the use of
this document.
ASAM e.V. reserves the right to revise this publication and to make changes to its content,
at any time, without obligation to notify any person or entity of such revisions or changes.

2 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

Revision History
This revision history shows only major modifications between release versions.

Date Author Filename Comments

2008-03-31 R.Schuermans Released document

XCP Version 1.1 Release 3

Part 3 - XCP on CAN - Transport Layer Specification

4 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

Table of contents

0. Introduction 7
0.1 The XCP Protocol Family 7
0.2 Documentation Overview 8
0.3 Definitions and Abbreviations 9
0.4 Mapping between XCP Data Types and ASAM Data Types 10

1 The XCP Transport Layer for CAN 11

1.1 Addressing 11
1.2 Communication Model 12
1.2.1 Master Block Transfer with Incremental CAN-ID 12
1.3 Header and Tail 13
1.3.1 Header 13
1.3.2 Tail 14
1.4 The Limits of performance 15

2 Specific commands for XCP on CAN 16

2.1 Get Slave CAN identifiers 17
2.2 Get DAQ List CAN Identifier 19
2.3 Set DAQ List CAN Identifier 20

3 Specific events for XCP on CAN 21

4 Interface to ASAM MCD 2MC description file 22

4.1 ASAM MCD 2MC AML for XCP on CAN 22
4.2 IF_DATA example for XCP on CAN 24

XCP Version 1.1 Release 5

Part 3 - XCP on CAN - Transport Layer Specification

Table of diagrams:
Diagram 1 : Master Block Transfer with Incremental CAN-ID 12
Diagram 2 : Header and Tail for XCP on CAN 13
Diagram 3 : No XCP Tail if DLC = LEN (<= MAX_DLC) 14
Diagram 4 : XCP Tail if DLC = MAX_DLC (> LEN) 14
Diagram 5 : Typical use of GET_SLAVE_ID modes 18

6 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

0. INTRODUCTION

0.1 THE XCP PROTOCOL FAMILY

This document is based on experiences with the CAN Calibration Protocol (CCP) version 2.1 as
described in feedback from the companies Accurate Technologies Inc., Compact Dynamics GmbH,
DaimlerChrysler AG, dSPACE GmbH, ETAS GmbH, Kleinknecht Automotive GmbH, Robert Bosch
GmbH, Siemens VDO Automotive AG and Vector Informatik GmbH.
The XCP Specification documents describe an improved and generalized version of CCP.
The generalized protocol definition serves as standard for a protocol family and is called “XCP”
(Universal Measurement and Calibration Protocol).
The “X” generalizes the “various” transportation layers that are used by the members of the
protocol family e.g “XCP on CAN”, “XCP on TCP/IP”, “XCP on UDP/IP”, “XCP on USB” and so on.

XCP
CAN TCP/IP UDP/IP USB ...
XCP is not backwards compatible to an existing CCP implementation.

XCP Version 1.1 Release 7

Part 3 - XCP on CAN - Transport Layer Specification

0.2 DOCUMENTATION OVERVIEW

The XCP specification consists of 5 parts. Each part is a separate document and has the following
contents:

Part 1 “Overview” gives an overview over the XCP protocol family, the XCP features and the
fundamental protocol definitions.

Part 2 “Protocol Layer Specification” defines the generic protocol, which is independent from
the transportation layer used.

Part 3 “Transport Layer Specification” defines the way how the XCP protocol is transported by a
particular transportation layer like CAN, TCP/IP and UDP/IP.

This document describes the way how the XCP protocol is transported on CAN.

Part 4 “Interface Specification” defines the interfaces from an XCP master to an ASAM MCD
2MC description file and for calculating Seed & Key algorithms and checksums.

Part 5 “Example Communication Sequences” gives example sequences for typical actions
performed with XCP.

Everything not explicitly mentioned in this document, should be considered as implementation

specific.

8 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

0.3 DEFINITIONS AND ABBREVIATIONS

The following table gives an overview about the most commonly used definitions and
abbreviations throughout this document.

Abbreviation Description
A2L File Extension for an ASAM 2MC Language File
AML ASAM 2 Meta Language
ASAM Association for Standardization 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
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 Calibration Protocol

Table 1: Definitions and Abbreviations

XCP Version 1.1 Release 9

Part 3 - XCP on CAN - Transport Layer Specification

0.4 MAPPING BETWEEN XCP DATA TYPES AND ASAM DATA TYPES
The following table defines the mapping between data types used in this specification and
ASAM data types defined by the Project Data Harmonization Version 2.0 (ref.
www.asam.net).

XCP Data Type ASAM Data Type

BYTE A_UINT8
WORD A_UINT16
DWORD A_UINT32
DLONG A_UINT64

10 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

1 THE XCP TRANSPORT LAYER FOR CAN

1.1 ADDRESSING

The master can use GET_SLAVE_ID to detect all XCP slaves within a CAN network. The
master has to send GET_SLAVE_ID with the XCP Broadcast CAN identifier.

XCP on CAN uses at least two different CAN identifiers for each independent slave: one
identifier for the CMD and STIM packets and one identifier for the RES, ERR, EV, SERV and
DAQ packets.
The STIM CAN Identifiers may be the same as the CMD CAN Identifier or may be assigned
by the SET_DAQ_ID command.
The DAQ CAN Identifiers may be the same as the RES/ERR/EV/SERV CAN Identifier or
may be assigned by the SET_DAQ_ID command.

The assignment of CAN message identifiers to the XCP objects CMD/STIM and
RES/ERR/EV/SERV/DAQ is defined in the slave device description file (e.g. the ASAP2
format description file), which is used to configure the master device. It is recommended that
the bus priority of the message objects be carefully determined in order to avoid injury to
other real-time communication on the bus. Also, the CMD/STIM should obtain higher priority
than the RES/ERR/EV/SERV/DAQ.

The most significant bit (of the 32-bit value) set, indicates a 29 bit CAN identifier.

XCP Version 1.1 Release 11

Part 3 - XCP on CAN - Transport Layer Specification

1.2 COMMUNICATION MODEL

XCP on CAN makes use of the standard communication model.
The block transfer communication model is optional.
The interleaved communication model is not allowed.

1.2.1 M ASTER BLOCK TRANSFER WITH INCREMENTAL CAN-ID

Diagram 1 : Master Block Transfer with Incremental CAN-ID

For block transfer from Master to Slave during a download or programming sequence,
performance can be increased if the Master uses different CAN-ID s for every request and
the communication is done with MIN_ST(_PGM) = 0.
With CAN_ID_MASTER_INCREMENTAL, the slave can inform the master that for a block
transfer sequence it has to use a range of CAN-IDs for the different requests. The Master
has to send the first request with CAN_ID_MASTER. The Master has to send consecutive
requests by incrementing CAN_ID_MASTER for every new request. The master has to send
the last request of the block transfer sequence with CAN_ID_MASTER+MAX_BS(_PGM)-1.

12 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

1.3 HEADER AND TAIL

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

Diagram 2 : Header and Tail for XCP on CAN

1.3.1 HEADER

For XCP on CAN there’s no Header (empty Control Field).

XCP Version 1.1 Release 13

Part 3 - XCP on CAN - Transport Layer Specification

1.3.2 TAIL

For XCP on CAN, the Tail consists of a Control Field containing optional Fill bytes.
The maximum data length of a CAN message and therefore maximum length of an XCP on
CAN message is MAX_DLC = 8.
If the length (LEN) of an XCP Packet equals MAX_DLC, the Control Field of the XCP Tail is
empty and the XCP on CAN Message is the same as the XCP Packet (DLC = LEN =
MAX_DLC).
If LEN is smaller than MAX_DLC, there’re 2 possibilities to set the DLC.
A first possibility is to set DLC = LEN. The Control Field of the XCP Tail is empty and the
XCP on CAN Message is the same as the XCP Packet.

XCP on CAN Message (Frame)

XCP Packet

XCP Tail
DLC PID .... empty
LEN

DLC = LEN Control Field

empty

Diagram 3 : No XCP Tail if DLC = LEN (<= MAX_DLC)

A second possibility is to set DLC = MAX_DLC = 8. The Control Field of the XCP Tail
contains MAX_DLC – LEN fill bytes. The contents of the FILL bytes is “don’t care”.

XCP on CAN Message (Frame)

XCP Packet XCP Tail

DLC PID .... Fill

LEN MAX_DLC - LEN
DLC =
MAX_DLC =8
MAX_DLC

Diagram 4 : XCP Tail if DLC = MAX_DLC (> LEN)

With MAX_DLC_REQUIRED, the slave can inform the master that it has to use CAN frames
with DLC = MAX_DLC = 8 when sending to the slave.

14 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

1.4 THE LIMITS OF PERFORMANCE

The maximum length of a CTO or a DTO packet is 8.

Name Type Representation Range of value

MAX_CTO Parameter BYTE 0x08
MAX_DTO Parameter WORD 0x0008

XCP Version 1.1 Release 15

Part 3 - XCP on CAN - Transport Layer Specification

2 SPECIFIC COMMANDS FOR XCP ON CAN

Table of Command Codes:

Command Code Timeout Remark

GET_SLAVE_ID 0xFF t1 optional
GET_DAQ_ID 0xFE t1 optional
SET_DAQ_ID 0xFD t1 optional

If SET_DAQ_ID is implemented, GET_DAQ_ID is required.

16 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

2.1 GET SLAVE CAN IDENTIFIERS

Category CAN only, optional
Mnemonic GET_SLAVE_ID

Position Type Description

0 BYTE Command Code = TRANSPORT_LAYER_CMD = 0xF2
1 BYTE Sub Command Code = 0xFF
2 BYTE 0x58 (A_ASCII = X )
3 BYTE 0x43 (A_ASCII = C )
4 BYTE 0x50 (A_ASCII = P )
5 BYTE Mode
0 = identify by echo
1 = confirm by inverse echo

The master can use GET_SLAVE_ID to detect all XCP slaves within a CAN network.
At the same time, the master gets to know the CAN identifier the master has to use when
transferring CMD/STIM to a specific slave and the CAN identifier this slave uses for
transferring RES/ERR/EV/SERV/DAQ.
The master has to send GET_SLAVE_ID with the XCP Broadcast CAN identifier.
If the master sends an XCP message with the XCP Broadcast CAN identifier, all XCP slaves
that are connected to the CAN network have to respond. GET_SLAVE_ID is the only XCP
message that can be broadcasted.
A slave always has to respond to GET_SLAVE_ID, even if the slave device is not in
Connected state yet.
The slave has to send the response with the CAN identifier it uses for transferring
RES/ERR/EV/SERV/DAQ. The CAN identifier for CMD/STIM is coded in Intel format (MSB
on higher position).
The master sends GET_SLAVE_ID with an Identification Pattern (ASCII for “XCP”). The
master uses this Pattern for recognizing answers from XCP slaves.
If the master sends a GET_SLAVE_ID(identify by echo), the slave has to send a response
that contains an echo of the Pattern. Additionally the slave informs the master about the
CAN identifier the master has to use when transferring CMD/STIM to this slave.

Positive Response (mode = identify by echo) :

Position Type Description

0 BYTE Packet ID: 0xFF
1 BYTE 0x58
2 BYTE 0x43
3 BYTE 0x50
4 DWORD CAN identifier for CMD/STIM

XCP Version 1.1 Release 17

Part 3 - XCP on CAN - Transport Layer Specification

If the master sends a GET_SLAVE_ID(confirm by inverse echo), the slave has to send a
response that contains an inversed echo of the Pattern. Additionally the slave repeats the
CAN identifier the master has to use when transferring CMD/STIM to this slave.

Positive Response (mode = confirm by inversed echo) :

Position Type Description

0 BYTE Packet ID: 0xFF
1 BYTE 0xA7
2 BYTE 0xBC
3 BYTE 0xAF
4 DWORD CAN identifier for CMD/STIM

If the master sends a GET_SLAVE_ID(confirm by inverse echo), without a previous

GET_SLAVE_ID(identify by echo), the slaves will silently ignore that command.
If the master first sends a GET_SLAVE_ID(identify by echo) and then a
GET_SLAVE_ID(confirm by inversed echo), this sequence allows the master to reliably
distinguish the responses of the slaves from other communication frames on the CAN network
and to reliably detect the CAN identifier pairs for every single slave.

Master Slave
upon GET_SLAVE_ID(XCP, identify by echo)
Broadcast CAN id
slave 1 upon its
Response(XCP, CAN id for CMD/STIM) CAN id for RES/
ERR/EV/SERV/DAQ

Response(XCP, CAN id for CMD/STIM) slave 2 upon its

CAN id for RES/
ERR/EV/SERV/DAQ
upon
GET_SLAVE_ID(XCP, confirm by inversed echo)
Broadcast CAN id

Response(XCP, CAN id for CMD/STIM)

slave 1 upon its
CAN id for RES/
ERR/EV/SERV/DAQ

Response(XCP, CAN id for CMD/STIM) slave 2 upon its

CAN id for RES/
ERR/EV/SERV/DAQ

upon CONNECT
CAN id for CMD/STIM
for slave 1 slave 1 upon its
Response
CAN id for RES/
ERR/EV/SERV/DAQ
upon CONNECT
CAN id for CMD/STIM
for slave 2 slave 2 upon its
Response
CAN id for RES/
ERR/EV/SERV/DAQ

Diagram 5 : Typical use of GET_SLAVE_ID modes

18 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

2.2 GET DAQ LIST CAN IDENTIFIER

Category CAN only, optional
Mnemonic GET_DAQ_ID

Position Type Description

0 BYTE Command Code = TRANSPORT_LAYER_CMD = 0xF2
1 BYTE Sub Command Code = GET_DAQ_ID = 0xFE
2 WORD DAQ_LIST_NUMBER [0,1,...MAX_DAQ-1]

Positive Response:

Position Type Description

0 BYTE Packet ID: 0xFF
1 BYTE CAN_ID_FIXED
0 = CAN-Id can be configured
1 = CAN-Id is fixed
2 WORD Reserved
4 DWORD CAN Identifier of DTO dedicated to list number

As a default, the master transfers all DAQ lists with DIRECTION = STIM on the same CAN
Identifier as used for CMD.
Alternatively, the master may have individual CAN Identifiers (other than the one used for
CMD) for the DAQ lists with DIRECTION = STIM.

As a default, the slave transfers all DAQ lists with DIRECTION = DAQ on the same CAN
Identifier as used for RES/ERR/EV/SERV.

Alternatively, the slave may have individual CAN Identifiers (other than the one used for
RES/ERR/EV/SERV) for its DAQ lists with DIRECTION = DAQ.

With GET_DAQ_ID, the master can detect whether a DAQ list uses an individual CAN
identifier and whether this Identifier is fixed or configurable.

If the CAN Identifier is configurable, the master can configure the individual Can Identifier for
this DAQ list with SET_DAQ_ID.

XCP Version 1.1 Release 19

Part 3 - XCP on CAN - Transport Layer Specification

2.3 SET DAQ LIST CAN IDENTIFIER

Category CAN only, optional
Mnemonic SET_DAQ_ID

Position Type Description

0 BYTE Command Code = TRANSPORT_LAYER_CMD = 0xF2
1 BYTE Sub Command Code = SET_DAQ_ID = 0xFD
2 WORD DAQ_LIST_NUMBER [0,1,...MAX_DAQ-1]
4 DWORD CAN Identifier of DTO dedicated to list number

The master can assign an individual CAN Identifier to a DAQ list.

If the given identifier isn’t possible, the slave returns an ERR_OUT_OF_RANGE.

20 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

3 SPECIFIC EVENTS FOR XCP ON CAN

There are no specific events for XCP on CAN at the moment.

XCP Version 1.1 Release 21

Part 3 - XCP on CAN - Transport Layer Specification

4 INTERFACE TO ASAM MCD 2MC DESCRIPTION FILE

The following chapter describes the parameters that are specific for XCP on CAN.

4.1 ASAM MCD 2MC AML FOR XCP ON CAN

/************************************************************************************/
/* */
/* ASAP2 meta language for XCP on CAN V1.0 */
/* */
/* 2003-03-03 */
/* */
/* Vector Informatik, Schuermans */
/* */
/* Datatypes: */
/* */
/* A2ML ASAP2 Windows description */
/* --------------------------------------------------------------------------------------------*/
/* uchar UBYTE BYTE unsigned 8 Bit */
/* char SBYTE char signed 8 Bit */
/* uint UWORD WORD unsigned integer 16 Bit */
/* int SWORD int signed integer 16 Bit */
/* ulong ULONG DWORD unsigned integer 32 Bit */
/* long SLONG LONG signed integer 32 Bit */
/* float FLOAT32_IEEE float 32 Bit */
/* */
/**************************************************************************************/
/************************ start of CAN ***********************************************/

struct CAN_Parameters { /* At MODULE */

uint; /* XCP on CAN version */

/* e.g. "1.0" = 0x0100 */

taggedstruct { /* optional */
“CAN_ID_BROADCAST” ulong; /* Auto detection CAN-ID */
/* master -> slaves */
/* Bit31= 1: extended identifier */

“CAN_ID_MASTER” ulong;
/* CMD/STIM CAN-ID */
/* master -> slave */
/* Bit31= 1: extended identifier */
"CAN_ID_MASTER_INCREMENTAL"; /* master uses range of CAN-IDs */
/* start of range = CAN_ID_MASTER */
/* end of range = CAN_ID_MASTER+MAX_BS(_PGM)-1 */

“CAN_ID_SLAVE” ulong; /* RES/ERR/EV/SERV/DAQ CAN-ID */

/* slave -> master */
/* Bit31= 1: extended identifier */

“BAUDRATE” ulong; /* BAUDRATE [Hz] */

"SAMPLE_POINT" uchar; /* sample point */

/* [% complete bit time] */

22 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

“SAMPLE_RATE” enum {
"SINGLE" = 1, /* 1 sample per bit */
"TRIPLE" = 3 /* 3 samples per bit */
};

"BTL_CYCLES" uchar; /* BTL_CYCLES */

/* [slots per bit time] */
"SJW" uchar; /* length synchr. segment */
/* [BTL_CYCLES] */
"SYNC_EDGE" enum {
"SINGLE" = 1, /* on falling edge only */
"DUAL" = 2 /* on falling and rising edge */
};

“MAX_DLC_REQUIRED”; /* master to slave frames */

/* always to have DLC = MAX_DLC = 8 */

(block “DAQ_LIST_CAN_ID” struct { /* At IF_DATA DAQ */

uint; /* reference to DAQ_LIST_NUMBER */

taggedstruct { /* exclusive tags */

/* either VARIABLE or FIXED */
"VARIABLE";
"FIXED" ulong; /* this DAQ_LIST always */
/* on this CAN_ID */
};

})*;

};

};/************************* end of CAN ***********************************/

XCP Version 1.1 Release 23

Part 3 - XCP on CAN - Transport Layer Specification

4.2 IF_DATA EXAMPLE FOR XCP ON CAN

/begin XCP_ON_CAN

0x0100 /* XCP on CAN version */

CAN_ID_BROADCAST 0x0100 /* Broadcast */

CAN_ID_MASTER 0x0200 /* CMD/STIM */

CAN_ID_MASTER_INCREMENTAL

CAN_ID_SLAVE 0x0300 /* RES/ERR/EV/SERV/DAQ */

BAUDRATE 500000 /* BAUDRATE */

/begin DAQ_LIST_CAN_ID
0x0000 /* for DAQ_LIST 0 */
FIXED 0x310
/end DAQ_LIST_CAN_ID

/begin DAQ_LIST_CAN_ID
0x0001 /* for DAQ_LIST 1 */
FIXED 0x320
/end DAQ_LIST_CAN_ID

/begin DAQ_LIST_CAN_ID
0x0002 /* for DAQ_LIST 2 */
FIXED 0x330
/end DAQ_LIST_CAN_ID

/end XCP_ON_CAN

24 XCP Version 1.1 Release

 Part 3 - XCP on CAN - Transport Layer Specification

XCP Version 1.1 Release 25

Part 3 - XCP on CAN - Transport Layer Specification

ASAM e.V.
Arnikastraße 2
D-85635 Höhenkirchen
Germany

Tel.: (+49) 08102 / 8953 17

Fax.: (+49) 08102 / 8953 10
E-mail: [email protected]
Internet: www.asam.net

26 XCP Version 1.1 Release