XCP Protocol

The XCP Protocol is a universal calibration and measurement-based networking protocol originated from the ASAM for connecting the calibration systems to ECU. Generally, it is used in automotive vehicles for run-time automation testing. In the case of UDS or Keyword protocol, the run time read or write of calibration parameters is not possible. Because the flash read or write mostly prevented in ECU, so this is not good to use. To prevent this, the QCM has come up with a new standard by which it can be done in a simple way of read-write operation.

The XCP protocol is commonly used in the automotive industry to measure and calibrate the electronic control units (ECUs) by which the ECU’s are very correct to detect and operate the vehicle on the road so that no accident or the human safety will be increasing.

Mostly, the engineers use it to read the measurement data and write the parameters to ECU during the development, testing, and in-vehicle calibration.  The main objective of the XCP protocol is to enable the read and write access to the variables and memory contents of the microcontroller systems runtime. The ASAM standard states The primary purpose of the XCP protocol is to adjust the internal parameters by writing command and acquire the current values of internal variables by reading command of an ECU runtime. Even if by using the protocol you can flash your application software into the flash memory of your microcontroller (available inside your ECU). 

In addition, The XCP protocol supports both the synchronous and asynchronous serial interfaces. With Ethernet or USB as the transport medium, XCP can also serve as a standardized interface to analog measurement devices and to hardware interface converters to RAM emulators, JTAG or other microcontroller debug interfaces of the diagnosis purpose.

The XCP Single-Master is the measurement and calibration system, often a PC, and the ECUs operate as Slaves. In XCP protocol, the master establishes a communication channel, a point-to-point connection, with the slave. The connection must be point-to-point between master and slave and broadcasting XCP messages is not allowed, except XCP message GET_SLAVE_ID, which can be broadcasted. Multiple masters are not allowed but a master can have multiple communication channels active in the same network at the same time. 

Every slave in the system has an ECU description file, A2L-file, which specifies what checksum method that is used, the physical meaning of the data, the link between variable names and their address range, and so on. The XCP master can access these descriptions files and read out all the necessary information to the might need.

The communication between master and slave is done through the XCP protocol driver that is integrated into the master. In XCP Standard communication mode each request packet sends from the master, the slave will respond with a response packet or an error packet. The master will not send a new packet until it receives a response or error packet from the slave regarding a previously sent request. To speed up the process of uploading and downloading to the memory and programming the flash, Block Transfer Communication Mode can be applied.

The XCP protocol communication mode is similar to the one that is used in the UDS protocol. In this mode, multiple requests are sent at the same time as a block of data and the slave responds by sending a block of responses back to the master. Another way to enhance transfer speed is to use the Interleaved Communication Mode where the master doesn’t wait for a response packet until it sends a new request. The number of requests that can be sent interleaved by the master depends on the queue size of the slave. Block Transfer Communication Mode and Interleaved Communication Mode cannot be used in the same system. 

Application Of The XCP Protocol:

• It is used in ECU development.
• It is used in Systems for function and environmental tests of ECUs.
• It is used in a test bench for combustion engines, gearbox, climate control, Instrument Cluster calibration, or Wheel alignment, etc.
• It is used for measurements and calibration in pre-production vehicles.
• It is also used in a general CAN application outside the vehicle industry.

XCP Protocol Frame Format:

An XCP message consists of the three parts, Header, Packet, and Tail. The Header and the Tail is part of the Transport layer and consist of a Control Field which content depends on what bus is used. The Packet part of an XCP protocol message consists of an Identification Field, Timestamp Field (optional), and a Data Field and is a generic part of the protocol layer.

XCP Packet:

In the XCP protocol, two different types of packets are used in the communication via XCP, Command Transfer Object (CTO), and Data Transfer Object (DTO). The CTO has five types of objects:

1. CMD (Command).
2. RES (Response).
3. ERR (Error).
4. EV (Event).
5. SERV (Service Request Processor).

The DTO has two types of objects that are both used for event-driven reading of variables from, or writing values to, the memory of the slave.

1. DAQ (Data Acquisition).
2. STIM (Stimulation).

Data Acquisition (DAQ): A core feature of the XCP protocol is the DAQ lists. In order to be able to send a large amount of data in a small amount of time and with low bandwidth load desirable, XCP offers the ability to configure lists that take care of the transmitting requested data at a given interval. Each DAQ list (Figure 10) has a number of Object Descriptor Tables (ODTs) that in turn contain Object Descriptor Table Entries (ODT Entries) as described in Figure 11. Each the ODT Entry has an address and a length, these make out the description of the parameter that it represents. When the DAQ list has processed the contents of the list are copied to the corresponding address of each entry in each ODT. The slave doesn’t receive an acknowledgment that the master has received the data correctly.

For each DAQ-list configurations, a number of ODT’s are defined, each having a unique identifying PID.

Each ODT entry in a DAQ list points to a memory element with specified address and length.

DAQ-list configuration: The XCP protocol has two different ways of configuring the DAQ-lists, static, and dynamic. While static configuration is mandatory according to the specification, dynamic configuration seems to be the preferred way (as an example CANape only uses the dynamic configuration in their examples). Which configuration method that is to be used is decided exclusively by the slave, there is no way for the master to the request one or the other, nor can both be used in parallel. In addition to the configurable DAQ-list (static or dynamic), the slave can also have a number of predefined DAQ-lists. These lists cannot be altered in any way. Each the ODT entry has a predefined address and size. The only thing the master is allowed to do is configure their direction, Prescaler, priority, and which event channel it should be connected to.

In the static configuration of the XCP protocol, the slave already has a structure of DAQ-lists with ODT’s and the ODT’s have entries. This configuration cannot be edited. If there is only one DAQ-list, that has three ODT’s and the ODT’s have 5 entries each, then this is all the master has got at its disposal. The entries can be edited, i.e. the address and address extension that maps it to the memory space can be changed. A lot of the DAQ-list’s properties can also be changed just as in the case with the predefined list.

The dynamic configuration is, as the name suggests, less restricted. The XCP protocol master can request allocation of any number of the DAQ-lists, each DAQ-list can have any number of ODT’s and the ODT’s can have any number of entries. There are some restrictions to the command sequence of the allocation, see Figure 12 and the following list:

• The allocation must always start with sending a command to clear the previous allocations; this is done with the FREE_DAQ. This will reduce the number of DAQ-lists to the predefined lists if any exists on the device.
• The next step is to allocate the DAQ-lists; this can either be done one at a time or by allocating all the lists at once. If a FREE_DAQ has not been executed before this step the device will return an error message.
• After allocating the DAQ-lists the master can start allocating ODT’s to the different lists. All the ODT’s in all the DAQ-lists need to be allocated before the first entry is allocated.
• Finally, the entries are allocated as:

The parameter MAX_ODT is defined in the AUTOSAR specification as a maximum number of ODTs available on the slave, its range, however, suggests that it is instead the maximum number of ODTs available in the DAQ-list. More about the different XCP protocol parameters can be found in the XCP AUTOSAR module.

STIM Lists – Data Stimulation Lists: The opposite of DAQ lists are STIM lists. They provide a means for the master to write to (stimulate) the slave in a controlled manner. When the master writes to a STIM list, the data is buffered in the slave until the STIM list is executed at which point the simulation data is copied to specified memory addresses of the ECU.

The STIM lists execute at a certain interval or at certain points in the program running on the ECU. This avoids the problems of directly modifying control parameters on the fly, mid execution of some control-loops. Instead, it allows the ECU to apply new parameters at controlled points in time.

The STIM lists are built up in the same fashion as DAQ lists. They consist of ODT’s (object data descriptors) and ODT entries. Each ODT is transmitted in a single STIM packet from the master to the slave and consists of multiple ODT elements. Each element has previously been configured to point to a memory address + extension with a specified length.

Processing Event Channel: Each DAQ-list is connected to an event channel that dictates how often the DAQ-list should be executed. The DAQ-list also has a parameter called a Prescaler that states how many event channel executions that should occur between each time the DAQ-list is run. If this parameter is set to 1 the DAQ-list will be run each time the event channel is executed.

XCP Signal Bypassing: Bypassing is a feature of the XCP that allows replacing some part of an ECU’s control logic with code that resides on the XCP master. For example, one could replace part of a calculation in the ECU with code that executes in Matlab/Simulink on the master to test out new controller methods without the need to reprogram the ECU. It combines the use of DAQ lists with STIM lists to achieve this.

The use of this feature of the XCP protocol requires additional instrumentation of the ECU’s code in order to function. When bypassing is activated on some part of the ECU’s program, the ECU will send a DAQ packet as it enters the bypassed code, with the parameters required to calculate a response to the master. Then the slave enters a waiting state. When the master receives the DAQ list for the bypassed code, it replies with a STIM packet containing the result of the calculation. At this point, the ECU resumes operation with the received STIM data as the result of the bypassed code.

XCP-Security Access:

The XCP protocol provides an ECU unlock feature like the UDS protocol. To ensure that access to the ECU is restricted to authorized persons only a security mechanism called Seed & Key is a part of the XCP specification. A slave unique key is needed to grant access to a slave and the master must ask the slave for a seed to be able to compute the key and gain access. The algorithm to calculate the key is unknown to the master to ensure confidentiality. The key algorithm is encapsulated in a file called SeedNKey.DLL which the master uses to calculate the key with the help of the seed provided by the slave.

XCP-ECU Flash Programming:

In the XCP object called SECTORS describes the physical layout of the ECU memory. The start addresses and sizes of the SECTOR are of high importance when reprogramming the ECU.

Programming of flash memory in a slave device can be divided into three parts.

1. Administration before programming: For example to check what version of the software is currently loaded in the memory.
2. The flash process: This is when the programming of the memory takes place.
3. Administration below: For example to do the checksum control to see if the flashing process was successful.

The XCP protocol standard does not support special commands for version control because the administration steps are very project-specific and depend on the ECU, but the ECU functional description can specify which standard XCP commands can be used for the administration actions like version control.

The XCP standard offers seven commands to be used especially for the programming are:

1. PROGRAM_START.
2. PROGRAM_CLEAR.
3. PROGRAM_FORMAT.
4. PROGRAM.
5. PROGRAM_VERIFY.
6. PROGRAM_RESET.

XCP-Flash Memory Access:

There are two different to the flash access methods supported by the XCP protocol to be used in the flash process. Absolute access mode and Functional access mode which both uses to the same commands but with some different parameters.

(1) Absolute Access Mode.

(2) Access by Address.

In the XCP protocol, this is the default mode and is used when the physical layout of the flash memory is well known to the programming tool. The flash content to be programmed must be available and the address information of the data must be known. The physical layout information can be read out of the ECU or in the description file depending on how it is done in the project. The block of data is contained in the Command Transfer Object (CTO) will be programmed into the flash memory starting at the Memory Transfer Address (MTA) which will be incremented by the number of bytes of data that are being programmed into the memory.