Plugins ››
Parent Previous Next

Table of Contents

1        Introduction        2

1.1        Features        2

1.2        Limitations        2

1.3        Performance Characteristics        2

2        Architecture        4

3        Usage        5

3.1        General setup        5

3.2        Modes of operation        9

3.2.1        DAQ        9

3.2.2        Polling        14

3.3        The XCP plugin window        16

3.3.1        XCP plugin configuration options        17

3.3.2        A2L (ASAM) file generator        19

3.4        Measurement sequence        23

4        XCP Master configuration examples        25

4.1        Integration with VECTOR CANoe        25

4.1.1        Prepare ASAM2 2MC (A2L) file        25

4.2        Integration with VECTOR CANape        28


The XCP plug-in is a lightweight implementation of an XCP slave.  It enables measuring and calibrating of the target ECU without impacting overall ECU’s performance or memory footprint.

The XCP plug-in interfaces between a measurement / calibration tool like CANoe or CANape and the rest of the tools stack down to the target ECU.  All microcontrollers, supported by iSYSTEM tools, can be handled by the XCP plug-in.

The XCP plug-in enables the measurement and calibration of an ECU without the need of any slave code on the ECU, without performance degradation to the ECU operation and without the need of a physical interface (like CAN, FlexRAY, …), other than the ECUs CPU debug or trace ports.

The XCP plug-in supports polled mode access, where access is directed from the XCP master and also high speed data acquisition, where data accesses are directed by the emulator (iC5000, iC3000, …) and streamed to the XCP master.


Synchronous data acquisition (DAQ)

Direct memory access (polling)

Online memory calibration (read / write access)

Time stamped data transfer, generation of event timestamps by the ECU/Emulator

A2L file generation


Ethernet transport layer supported only

Only dynamic DAQ list supported

Bypassing is not supported

Block mode is not supported

Resume mode is not supported

Checksum is not supported

Dynamic event list (Plug-and play) is not supported

1.3Performance Characteristics



Timestamp resolution

100 µs

Min sampling interval – polling

1 ms

Min sampling interval – DAQ

100 µs

Bypassing latency time

< 500 µs

Max DAQ events


Max DAQ per Event


Max ODT entries


Max ODT entry size

8 bytes


Conceptual architecture


The XCP master (i.e. CANoe, CANape) and the XCP slave (winIDEA XCP plugin) must be configured properly to establish communication. The communication protocol (TCP or UDP) and port should match. If the master and slave are in different host you will have to configure the addresses accordingly, by default the communication is setup for localhost connection.

3.1General setup

1)Enable the XCP plug-in in winIDEA. (Plugins/Options)

2)Enable the Status Window of the XCP plugin. (Plugins/Options/XCP/Status window)

3)Review the XCP configuration options for both the master and the slave. Generally, the slave functions as a “listening” server that sources data and the master (i.e. CANoe) as a client that consumes it.

XCP slave configuration:

XCP master configuration (i.e. CANoe):

3.2Modes of operation

The XCP plug-in enables ECU measurement (ECU’s memory observation) and ECU calibration (ECU’s memory write). In all cases, it is the master’s (CANoe, CANape) responsibility to set-up the measurement environment.

The ASAM 2MC configuration file (extension .A2L) is a good starting point to prepare the measurement environment. A default WINIDEA_XCPSERVER.A2L file is provided by iSYSTEM for easy start-up.

On the master side, data acquisition may be configured as DAQ or Polling. DAQ is recommended as data acquisition is much faster and the sampling interval more consistent.


In DAQ mode, data acquisition is performed by the emulator.  For maximum performance, disable »Real time memory-access« under Debug/Options/Memory Access. If real-time memory access is enabled and in use, the debugger and the DAQ aquisition subsystem will compete resources, resulting in a slower or less stable sampling interval.


DAQ configuration in CANoe:

In this case, iXcpArray_01 variable will be sampled by emulator at maximum sampling rate. Whenever variable changes, an event is triggered and  data streamed to XCP master.

When DAQ is running, this is clearly indicated on the XCP's plugin main page. Performance issues

General performance is indicated in the line »DAQ average/desired sampling time (us)«. Desired sampling time comes from minimum required event sampling time (see table):

DAQ event name

DAQ event number

Desired sampling rate (ns)



max possible rate













IO module-DIN(1)


max possible rate

IO module-AIN0(1)


max possible rate

IO module-AIN1(1)


max possible rate

IO module-AIN0(avg)(1)


max possible rate

IO module-AIN1(avg)(1)


max possible rate

user defined




If average sampling time exceeds the desired minimum required sampling time, the status line appears in red, clearly warning the end user of irregular sampling conditions.

Please take care when deciding on event number.  Events 0,1 and 5-255 cause a lot of traffic on the debug port which could lead to irregular measurement conditions.

(1) Events 5 through 9 are dedicated to IO-module.  

DAQ event name


IO module-DIN

Event for sampling IO module Digital Inputs.

The linked variable should be UWORD type. It takes DIN0-DIN31 input values.

The linked variable address represents the bitmask for active digital inputs. Default value 0x000000FF enables DIN0-DIN7

IO module-AIN0

Event for sampling IO module Analog Input AIN0.

The linked variable should be 4-bytes float type.

The linked variable address represents the AIN port number.

IO module-AIN1

Event for sampling IO module Analog Input AIN1.

The linked variable should be 4-bytes float type.

The linked variable address represents the AIN port number.

IO module-AIN0(avg)

Event for sampling IO module Analog Input AIN0 with averaging.

The linked variable should be 4-bytes float type.

The linked variable address represents the AIN port number.

IO module-AIN1(avg)

Event for sampling IO module Analog Input AIN1 with averaging.

The linked variable should be 4-bytes float type.

The linked variable address represents the AIN port number.

IO module DAQ configuration in CANoe:

In this case, variable ioModuleAIN0 and ioModuleAIN1 must be of type float. They are generated automatically by A2L file generator.

ioModuleDIN must be of type UWORD.  It is generated automatically by A2L file generator. Address of this variable represents the enabled ports bitmask. By default, the address is set to 0x000000FF, which enables digital inputs DIN0-DIN7.


When the polling mode is used the memory access requests are generated by the master.  The XCP commands (read and/or write to ECU’s memory) are processed sequentially by the XCP slave. The statistics are clearly displayed in the “XCP statistics” section.  

Note: Real-time memory access under Debug/Options/Memory Access must be ENABLED in this case.


Polling configuration in CANoe:

In this case, every 100 ms a read request is forwarded to XCP plugin, which reads the ECU’s memory. Statistics about the operation of the plug-in in this mode are shown on the XCP plugin statistics section:

If real-time memory access is not enabled, access to ECU’s memory is disabled. Statistics under XCP memory reads total/errors shows the number of unsuccessful attempts.  XCP_CMD_DENIED is returned to the master.

3.3The XCP plugin window

Command buttons to start, stop, A2L file generation and XCP plugin configuration.

The status line displays the general XCP plugin status (Stopped, Running / Listening).

The master (client) info displays  the master connection status (whether a master is connected or not)

The XCP statistics display overall XCP commands statistics. Memory reads, writes and errors are reported separately.

The DAQ statistics display the overall DAQ acquisition performance.

3.3.1XCP plugin configuration options

Configuration options are displayed in separate window.  




Communication protocol between XCP master and XCP slave. (TCP, UDP) UDP is faster, but it doesn’t guaranty message delivery.


(Listening) communication port of the XCP plugin.

Auto Start

Sets whether XCP plugin is started automatically.


Memory access mode for HCS12x family. (Logical, banked or linear)

3.3.2A2L (ASAM) file generator

For easier integration with popular XCP master applications (i.e. Vector CANoe, Vector CANape), simple A2l file generator is embedded into XCP plugin. Invoke it either by pressing the “gear” icon or, alternatively, from the menu (Plugins/Options/XCP/Generate A2L file)

4.Main window of the A2L (ASAM) file generator appears:

On startup, the generator connects to winIDEA instance and reads available global variables from all downloaded files.

Note: Target application should be downloaded to successfully read global variables.

Note: Simple variables, arrays and structures with simple member expansion are supported.

Note: For diagnostics purposes, startup sequence is logged in the “Generator output” field.

Note: Variable is prefixed with download file name, if more than one exists.        

5.In the left list box (Available variables), select variables, which shall be monitored by  XCP plugin:

6.Move selected ( > ) or all( >>> ) to the right list box (Selected variables)

7.Press “Generate” to start A2l FILE generation process. Generation is template-based, template(s) reside(s) in $(UserProfileDir)\iSYSTEM\winIDEA\Templates\XCP\. Template is actually ASAM file with special $(winIDEAVariables) tag, which is replaced with observed variables data. Templates have extension .A2L.TPL.  New templates could be added / modified for specific purposes.

Note: template is automatically selected, if single template exists in the templates folder; otherwise, user must manually select one.

Note: Checked “Generate Writable Variable” check box generates “writable” variables, i.e. they could be manipulated through XCP protocol by XCP master.

Note: Template contains predefined virtual variables for IO module DAQ sampling (ioModuleDIN, ioModuleAIN0 and ioModuleAIN1). Those variables should be used with IO module events only.

Target A2L is generated in workspace folder by simple replacing $(winIDEAVariables) tag with selected variables data. Default file name is WINIDEA_XCPSERVER.A2L.

3.4Measurement sequence

5.Prepare measurement configuration on the master side. If you have started with A2L file generator , only adoption of measurement mode is required.  Some XCP masters allows linking the ECU's MAP file with A2L observation variables; this automatically updates variable addresses.

For DAQ-based measurement, following events/measurement modes are available by default:

max_rate (max sampling rate on the Emulator)

1ms_loop (1ms sampling rate on the Emulator)

10ms_loop (10ms sampling rate on the Emulator)

100ms_loop (100ms sampling rate on the Emulator)

1s_loop (1s sampling rate on the Emulator)

Up to 256 events could be used (please add own to .A2L file or A2L.tpl template).

Please note, that an event will ONLY be triggered, if ANY of the observed variable(s) has changed.  

Picture:  Example of measurement configuration in CANape

6.Prepare target application.

7.Run the XCP plugin

8.Run the target aplication from winIDEA.

9.Start measurement from the master. Optionaly use debugger Run control to manipulate target execution

4XCP Master configuration examples

In this section, some popular XCP master applications and required configuration setup are described. Integration examples could be found in winIdea examples/XCP folder.

4.1Integration with VECTOR CANoe

Note: XCP support in CANoe is optional. CANoe option .XCP or .AMD is required to activate XCP support. Please contact Vector for further information.

4.1.1Prepare ASAM2 2MC (A2L) file

To startup with CANoe, correctly defined ASAM 2MC configuration file (A2L) is crucial for correct configuration. A2L file generator is a good starting point.

CANoe includes specialised  ASAP2 file viewer, which allows A2L file preview. Appropriate tool is required to create/modify the ASAP2 file (i.e. ASAP2 editor).  

However, it could easily be adjusted by means of simple text-editor (since A2L file is a text file).  

Essential sections of A2L file are

IF_DATA XCP section


The IF_DATA_XCP section describes essential XCP plugin properties. Use complete IF_DATA_XCP section in your target ECU A2L file to enable correct XCP data exchange.

This section provides very important part, so-called “Event list”.  Event list contain one or more events. of XCP Events

Events are placeholders for variable observation.  Each event has the unique ID. Max 255 could be used with XCP plugin. From the master point of view, all events are trigger-based events (not cyclic); it means, XCP message would be transmitted to master only if variable change is detected by XCP plugin. Setting the event type to cyclic in A2L file doesn’t make sense: their behavior is predefined in XCP plugin and is based on the event ID.  

However, inside the emulator, changes are detected by internal loop, which is cyclic. Following table describes event’s internal cycle interval:

Event ID

Event name

Sampling cycle time



fastest possible rate (min 100 µs cycle)



1 ms



10 ms



100 ms



1 s


user defined

same as event 0 (fastest possible rate) MEASUREMENT section

The MEASUREMENT section defines observed variables measurement and their relation to XCP events.  This part should be adjusted to actual ECU memory layout and desired observation cycle time. Example:

/begin MEASUREMENT iXcpCounter_100ms ""


 ECU_ADDRESS 0x20000068

 FORMAT "%.15"



    LINK_MAP "iXcpCounter_100ms" 0x20000068 0x0 0 0x0 1 0x8F 0x0

    DISPLAY 0 0 65535

 /end IF_DATA


Note: If target ECU memory layout changes, the A2L file should be updated somehow.  Vector provides special tools for such purposes. For example, the ASAP2 Updater reads an ASAP2 source file and updates the address and data type information on the basis of the entries in a linker map file. The most prevalent linker MAP formats are supported, such as IEEE, COFF, ELF and the ASCII map formats of many compilers.

4.2Integration with VECTOR CANape

Integration with CANape is somehow similar to integration with CANoe with more measurement setup flexibility. Following screenshots may show/help how to prepare a  measurement environment.

1.Prepare target application, turn on BlueBox emulator, start winIdea and run the XCP plug-in

2.In CANape, start a new configuration

3.Create new device from existing database

Note: Use predefined WINIDEA_XCPSERVER.A2L database

4.After CANape loads the database file, it immediately tries to establish the communication with winIdea XCP plugin. If succesfull, XCP plugin updates master (client) info and number of received XCP commands. CANape updates its own status, too.  CANape allows manual communication manipuation to XCP server (bring online/offline, activate/deactivate device)

If connection fails,  review the TCP/IP communication options in CANape and diagnostic info on XCP plugin. Please note, single master connection to XCP slave is allowed only! If you experience troubles with connection establishment, simply put ECU offline.

5.Register linker map file with WINIDEA_XCPSERVER in device configuration.  That's the way how LINKER and CANape exchange target ECU memory and variable adresses. If the source code of the ECU is modified, map file would be modified as well (when project is recompiled and re-linked). CANape detects such map file modification and refreshes the A2L file automaticaly.

6.Now edit the A2L file with internal database editor. It allows variable definition and other ECU parameters. Variables could be simply linked to MAP file.

7.Configure measurement

Now you are ready to select desired event(s) and attach variable(s).

8.Prepare measurement windows and select observed variables.

9.Start measurement. DAQ progress is updated on the XCP plugin status window.

During measurement, full debug/trace control is possible in winIdea (Stop, Step, Step over, Run, Run until return..)