Diagnostic Protocols · Chapter 14

Universal Measurement and Calibration Protocol (XCP)

In 2003, XCP was standardized as a successor to CCP. It supports more transport layers than CAN, such as CAN FD, FlexRay, and Ethernet. XCP expands the protocol to include synchronous data acquisition and stimulation, read/write access on calibration data, memory page management, flash programming, and further optional features.

History

2003 — XCP 1.0 with support for CAN, Ethernet, SPI, USB
2008 — XCP 1.1 with support for FlexRay
2013 — XCP 1.2 with ECU description file updates + CAN FD
2015 — XCP 1.3 with ECU states, bypass handling, time correlation
2017 — XCP 1.4 with improvements and a new DAQ mode
2017 — XCP 1.5 with software debugging without a debug adapter

Protocol

XCP is clearly derived from CCP, with some changes. XCP has Command Transfer Object (CTO) packets for commands, responses, errors, events, and service requests, and Data Transfer Object (DTO) packets for DAQ/STIM data. The counter field is now optional, and only used for DAQ-related frames. A timestamp was added to DAQ-related frames, defining exactly when the measurement was taken — an improvement over CCP, where the measurement could only be guessed based on the time the DTO was received.

The first byte of the message contains the PID. As with CCP, for frames from tester to ECU the PID defines the command. For frames from ECU to tester, the PID defines the type of response frame (e.g. result, error, event).

General XCP packet layout

PID0..n bytes1–2 bytes1 byte1–4 bytescommand / measurement bytes

Field	Mnemonic	Value	Description
Packet Identification	`PID`	`PID`	1 byte. Identifies the command (CTO) or DAQ list / response type (DTO).
Fill	`FILL`	`0..n bytes`	Optional padding for word/dword alignment of the data field.
DAQ	`DAQ`	`1–2 bytes`	Only present in DAQ DTOs that carry the DAQ list number separately from the PID.
Counter	`CTR`	`1 byte`	Optional. Used to detect lost DAQ DTOs.
Time stamp	`TS`	`1–4 bytes`	Optional. Records when the measurement was taken on the ECU.
Data	`DATA`	`command / measurement bytes`	Variable-length payload up to MAX_CTO (CTO) or MAX_DTO (DTO).

Command Transfer Object (CTO)

The CTO packet is used for command-oriented communication. The contents are the PID followed by data. For commands, the PID is in the range of 0xC0 to 0xFF.

TesterECUCTO command (Tester → ECU)

command codeup to MAX_CTO − 1 bytes

Field	Mnemonic	Value	Description
Packet Identification	`PID`	`command code`	Range 0xC0–0xFF. Identifies the requested command (e.g. 0xFF CONNECT, 0xF4 SHORT_UPLOAD).
Parameters & data	`DATA`	`up to MAX_CTO − 1 bytes`	Layout depends on the command. Unused trailing bytes are reserved.

Command Transfer Object Responses

The four types of CTO response packets are defined by their PID:

RES (PID = 0xFF) — Positive response to a command.
ERR (PID = 0xFE) — Negative responses now get their own PID compared to CCP. The second byte in the packet defines the error code. Having a separate PID for the error response saves a byte in every response compared to CCP.
EV (PID = 0xFD) — Event packet used by the ECU to inform the tester about an event asynchronously (i.e. not as a response to a command). The second byte in the packet defines the event code.
SERV (PID = 0xFC) — Service packet used by the ECU to request the execution of a service by the tester. For example the ECU can request the tester to restart. The second byte in the packet defines the service code.

Data Transfer Object (DTO)

DTO packets are used for synchronous data acquisition (DAQ) and stimulation (STIM). These packets carry measured or stimulated data rather than command responses.

Standard Commands

A few interesting commands are described below. For the full list, see the XCP standard.

`0xFF` — `CONNECT`

The CONNECT command is the first step in establishing a connection with the ECU. It has a single parameter, the connection mode. The standard defines 0x00 for normal, and 0x01 for user-defined. The ECU responds with the available resources, basic communication mode, the maximum CTO and DTO sizes, and the XCP version numbers.

CONNECT — establish an XCP session

TesterECU

FF00

Field	Mnemonic	Value	Description
Command Code	`CMD`	`FF`	0xFF = CONNECT.
Mode	`MODE`	`00`	0x00 = normal. 0x01 = user-defined.

ECUTester

FF1CC00808000101

Field	Mnemonic	Value	Description
Packet ID	`PID`	`FF`	0xFF = positive response (RES).
Resource	`RES`	`1C`	High Reserved (0) Low CAL/PAG=0, DAQ=1, STIM=1, PGM=1 → DAQ + STIM + PGM available Bitmask of resources available on the ECU.
Comm mode (basic)	`CMB`	`C0`	High OPTIONAL=1, SLAVE_BLOCK_MODE=1 Low Address granularity = BYTE, byte order = Intel (LE) Communication-mode bitmask.
MAX_CTO	`MCTO`	`08`	Maximum CTO size in bytes (8 here — single CAN frame).
MAX_DTO	`MDTO`	`08 00`	Maximum DTO size, little-endian word. 0x0008 = 8 bytes.
Protocol version	`PVER`	`01`	Major version of the XCP protocol layer (most significant byte).
Transport version	`TVER`	`01`	Major version of the active transport layer (most significant byte).

`0xF4` — `SHORT_UPLOAD`

SHORT_UPLOAD is very similar to the CCP equivalent, and is used to read a small chunk of memory from the ECU. Setting MTA is not necessary.

Example of reading 4 bytes from address 0x80000000 (assuming Intel byte order, as advertised in the CONNECT response above):

SHORT_UPLOAD — read 4 bytes from 0x80000000

TesterECU

F404000000000080

Field	Mnemonic	Value	Description
Command Code	`CMD`	`F4`	0xF4 = SHORT_UPLOAD.
Number of elements	`N`	`04`	How many address-granularity elements to read (1..MAX_CTO − 1).
Reserved	`—`	`00`	Reserved.
Address extension	`EXT`	`00`	Memory page / device selector. Implementation-specific.
Address	`ADDR`	`00 00 00 80`	32-bit source address. Little-endian per the CONNECT response (0x80000000).

ECUTester

FF00000000

Field	Mnemonic	Value	Description
Packet ID	`PID`	`FF`	0xFF = positive response.
Data	`DATA`	`00 00 00 00`	Requested bytes. MTA is unchanged.

Error Codes

Code	Description
`0x00`	Command processor synchronization
`0x10`	Command was not executed
`0x11`	Command rejected because DAQ is running
`0x12`	Command rejected because PGM is running
`0x20`	Unknown command or not implemented optional command
`0x21`	Command syntax invalid
`0x22`	Command syntax valid but command parameter(s) out of range
`0x23`	The memory location is write protected
`0x24`	The memory location is not accessible
`0x25`	Access denied, Seed & Key is required
`0x26`	Selected page not available
`0x27`	Selected page mode not available
`0x28`	Selected segment not valid
`0x29`	Sequence error
`0x2A`	DAQ configuration not valid
`0x30`	Memory overflow error
`0x31`	Generic error
`0x32`	The ECU's internal program verify routine detects an error
`0x33`	Access to the requested resource is temporarily not possible

Scanning for XCP

Scanning for XCP is simpler than CCP, since no station address is required. Send the CONNECT command to all CAN arbitration IDs and check for a response.