XCP Slave

The XCP protocol is primarily designed for ECU calibration and read/write access to the variables and memory contents of various microcontroller systems inside vehicles. It is based on the master-slave topology, so you can connect multiple smaller systems on the same network into a larger system. Data transmission can be synchronous or asynchronous, which corresponds well with Dewesoft’s channels.

The XCP slave plugin can transfer gathered data within Dewesoft over the XCP interface. It communicates over the TCP/IP protocol and can transfer multiple channels at speeds up to 1 million samples/s. The plugin works with Dewesoft’s and some other third party XCP masters e.g. ETAS Inca and Vector Canape.

XCP versions

The plugin currently implements XCP protocol version 1.4 and is backwards compatible down to version 1.0. It supports the transport layer XCP on ethernet (TCP/IP) version 1.3.


Settings are under Settings/Extensions/XCP Slave and they are divided into two parts TCP/IP settings and DAQ settings.

TCP/IP settings

Communication between XCP master and slave is established over the TCP/IP protocol. Which means you need to set two things:

  • IP address - IP address of the machine running the XCP slave plugin.
  • Port - the port number on which XCP slave should listen for incoming connections.

NOTE: If your machine has multiple ethernet adapters be sure to use the IP address of the one connected to the same network as your XCP master.

DAQ settings

In many cases, the XCP slave plugin will only be a part of a larger system so there’s an option to give control over the measurement and storing to the XCP master. The first option enables control, meaning whenever XCP master starts or stops data transfer, Dewesoft’s measurement is also started or stopped. Additionally, the second option enables the storing of Dewesoft’s measurement whenever XCP data transfer is active. It’s recommended to enable create multifile under the storing options, which will prevent overwriting other data files. XCP slave plugin also mounts DAQ active synchronous channel, which has a value of one if the XCP data transfer is currently active, or zero if it’s not. This channel can be used as a trigger to do some operations when XCP data transfer is active or only as a display of current data transfer status within the measurement.


XCP slave plugin has its setup screen in channel setup which can be divided into four parts:

  1. Status
  2. Sync events
  3. Async events
  4. Outputs


A short overview of the current state. Available states for Daq controller are the following:

  • Enabled - measurement will start whenever XCP data transfer is activated
  • Enabled (storing) - measurement will start in storing mode whenever XCP data transfer is activated
  • Disabled - control over measurement is disabled

Also, there’s a connection status which informs you if any XCP master is currently connected to the XCP slave.

Sync events

XCP synchronous events are periodic and are best used with data transfer of the Dewesoft’s synchronous channels. There is always only one synchronous event available, which is automatically calculated to match the dynamic acquisition rate as close as possible. Channels with the sample rate divider are best used with a combination of synchronous event and prescaler, which can be defined on the XCP masters side. Synchronous events are defined with the following properties:

  • Name - the name of the event.
  • Short name - the shortened name of the event.
  • Time unit - defines the event’s basic tick period.
  • Time cycle - used to define a basic tick period divider.
Time unit Time cycle Time between samples Sample rate
1 ms 1 1 ms 1000 Hz
10 us 5 50 us 20000 Hz

For better performance, you should have a look at the packed mode section.

Async events

XCP asynchronous events are non-periodic also called as non-cyclic. They are best used with data transfer of the Dewesoft’s asynchronous channels. Asynchronous event is driven by theĀ trigger channel. Data is sampled and transferred at exact time stamps of the samples added to the trigger channel.


XCP protocol defines data output as a pair of memory address and size of actual memory occupied. In the XCP slave plugin that translates to an autogenerated memory location and Dewesoft channel’s sample size. When populating XCP output list, you have two options:

  • Autogenerate - scan for all available Dewesoft channels and add them to the list. If a channel is already defined in the list, it is simply ignored. After the list is populated, you can choose which outputs you want to use and only those will be exported to the A2L file.
  • Add / Remove - using these you can manually add or remove channels one by one. Channels added are automatically used.

NOTE: XCP outputs defined in XCP slave plugin are not actual memory locations, so any memory optimisation on the XCP master side must be turned off.

Packed mode

XCP protocol version 1.4 implemented the packed mode data transfer. Which enables higher data rates in the range of 1 million samples/s. This feature also lowers the CPU intensity of the XCP slave plugin. So you should use this data transfer option whenever possible. XCP slave plugin automatically calculates best possible packed modes for defined synchronous events and saves it to the A2L file.

NOTE: For the best possible performance you should match the data transfer rate to the actual channel’s sample rate.