TechnicalReference_XCP_on_CANs

XCP on CAN
Technical Reference

XCP on CAN Transport Layer

Version 1.08

Authors:
Frank Triem, Sven Hesselmann
Version:
1.08
Status:
released (in preparation/completed/inspected/released)

Technical Reference XCP on CAN

1 Document
Information
1.1 History
Author
Date
Version Remarks
Frank Triem
2005-01-03
1.0
ESCAN00010737: Initial draft
Klaus Emmert
Warning Text added
Frank Triem
2005-02-28
1.1
ESCAN00011300: Manual configuration
Frank Triem
2005-06-22
1.2
ESCAN00011772: Support multiple CAN channels
ESCAN00012311: Support CAN-Driver without
transmit queue
Frank Triem
2005-12-19
1.3
Rework due to inspection
Frank Triem
2006-04-24
1.4
ESCAN00015915: Correct filenames
Frank Triem
2006-05-30
1.5
ESCAN00016517: Update of table of contents
Frank Triem
2006-10-26
1.6
ESCAN00017220: Documentation of reentrant
capability of all functions
Sven
2007-09-14
1.7
Multiple Identity added
Hesselmann
Sven
2008-03-19 1.07.01 Invalid reference corrected
Hesselmann
Andreas
2009-01-14
1.08
ESCAN00031509: Description of how to define
Herkommer
Messages as Application Messages

1.2 Reference
Documents
Index
Document
[1]
XCP -Part 1 – Overview, Version 1.0 of 2003-04-08
[2]
XCP -Part 2- Protocol Layer Specification, Version 1.0 of 2003-04-08
[3]
XCP -Part 5- Example Communication Sequences, Version 1.0 of 2003-04-08
[4]
Technical Reference XCP Protocol Layer, Version 1.0 of 2005-01-17
[5]
Technical Reference CAN Driver, Version 2.21 of 2003-07-29
[6]
AN-AND-1-108 Glossary of CAN Protocol Terminology
http://www.vector-informatik.de

©2009, Vector Informatik GmbH
Version: 1.08
2 / 27
based on template version 1.3

Technical Reference XCP on CAN

1.3 Abbreviations
Abbreviations Complete expression
A2L
File Extension for an ASAM 2MC Language File
AML
ASAM 2 Meta Language
API
Application Programming Interface
ASAM
Association for Standardization of Automation and Measuring Systems
CAN
Controller Area Network
CANape
Calibration and Measurement Data Acquisition for Electronic Control Systems
CMD
Command
CTO
Command Transfer Object
DAQ
Synchronous Data Acquistion
DLC
Data Length Code ( Number of data bytes of a CAN message )
DLL
Data link layer
DTO
Data Transfer Object
ECU
Electronic Control Unit
ID
Identifier (of a CAN message)
Identifier
Identifies a CAN message
ISR
Interrupt Service Routine
MCS
Master Calibration System
Message
One or more signals are assigned to each message.
MRB
Multi receive buffer
MRC
Multi receive channel
OEM
Original equipment manufacturer (vehicle manufacturer)
RES
Command Response Packet
SRB
Single receive buffer
SERV
Service Request Packet
STIM
Stimulation
XCP
Universal Measurement and Calibration Protocol
VI
Vector Informatik GmbH

Also refer to [6] for a list of common abbreviations and terms.
©2009, Vector Informatik GmbH
Version: 1.08
3 / 27
based on template version 1.3

Technical Reference XCP on CAN

1.4 Naming
conventions
The names of the access functions provided by the XCP Transport Layer for CAN always
start with a prefix that includes the characters ‘Xcp’. The characters ‘Xcp’ are surrounded
by an abbreviation which refers to the service or to the layer which requests a XCP
service. The designation of the main services is listed below:
Naming conventions
Xcp…
It is mandatory to use all functions beginning with Xcp…
These services are called by either the data link layer, XCP Protocol Layer or
the application.
They are e.g. used for the transmission of messages.
ApplXcp
The functions, starting with ApplXcp… are functions that are provided by the
application and are called by the XCP Transport Layer for CAN.
These services are user callback functions that are application specific and
have to be implemented depending on the application.

Please note
We have configured the programs in accordance with your specifications in the

questionnaire. Whereas the programs do support other configurations than the one
specified in your questionnaire, Vector’s release of the programs delivered to your
company is expressly restricted to the configuration you have specified in the
questionnaire..
©2009, Vector Informatik GmbH
Version: 1.08
4 / 27
based on template version 1.3

Technical Reference XCP on CAN

2 Overview
This document describes the features, API, configuration and integration of the XCP
Transport Layer for CAN. The XCP Protocol Layer, which is already described within a
separate document [4], is not covered by this document.
Please also refer to “The Universal Measurement and Calibration Protocol Family”
specification by ASAM e.V.
XCP on CAN is a hardware independent protocol that can be ported to almost any CAN
controller. Due to there are numerous combinations of micro controllers, compilers and
memory models it cannot be guaranteed that it will run properly on any of the above
mentioned combinations.
Please note that in this document the term Application is not used strictly for the user
software but also for any higher software layer, like e.g. a Communication Control Layer.
Therefore, Application refers to any of the software components using XCP on CAN.
The API of the functions is described in a separate chapter at the end of this document.
Referred functions are always shown in the single channel mode.

©2009, Vector Informatik GmbH
Version: 1.08
7 / 27
based on template version 1.3

Technical Reference XCP on CAN

3 Functional
Description
3.1 Overview
of
the functional scope
The XCP Transport Layers mange the transmission and reception of XCP Packets.
The XCP Transport Layer for CAN makes use of the CAN-Driver to transmit and receive
XCP messages. Since variable message length is not supported the XCP Transport Layer
has to ensure that all sent XCP messages have the same DLC. I.e. a DLC of 8.
3.2  Reception and transmission of XCP packets
Upon reception of any XCP message the function
vuint8 XcpPreCopy (PRECOPY_PARAM_TYPE PRECOPY_PARAM )
(5.3.1)
is called by the CAN-Driver and the XCP Packet is passed to the Protocol Layer by a call
of the function:
void XcpCommand ( MEMORY_ROM vuint32* pCommand )
After the command has been processed by the Protocol Layer the XCP Response Packet
is passed to the Transport Layer by the service
void ApplXcpSend (vuint8 len, MEMORY_ROM BYTEPTR msg )
(5.2.1)
and the XCP message is transmitted by the CAN-Driver service
vuint8 CanTransmit ( CanTransmitHandle tmtHandle )
the successful transmission is confirmed by the CAN-Driver by a call of
void XcpConfirmation ( CanTransmitHandle tmtObject )
(5.3.2)
The confirmation is passed to the Protocol Layer by a call of
void XcpSendCallback (void )

Asynchronous XCP Packet transmission like e.g. SERV, EV and DAQ are transmitted and
confirmed by the described sequence.
3.3  Support of multiple CAN channels
Multiple CAN channels are supported by the XCP Transport Layer for CAN. However it is
not possible to have multiple connections at one time. I.e. only one connection on one
CAN channel is allowed.
The option ‘multi connection protection’ ensures that only one XCP Master communicates
with the XCP Slave at one time.

©2009, Vector Informatik GmbH
Version: 1.08
8 /  27
based on template version 1.3

Technical Reference XCP on CAN

4  Integration into the application
This chapter describes the steps for the integration of the XCP Transport Layer for CAN
into an application environment of an ECU.
4.1 Files
The XCP Transport Layer for CAN consists of the following files:
Files of the XCP on CAN Transport Layer
xcp_can.c  XCP on CAN Transport Layer.
This file must not be changed by the user!
xcp_can.h  API of the XCP on CAN Transport Layer.
This file must not be changed by the application!
This file has to be included prior to XcpProf.h.
v_def.h
General Vector definitions of memory qualifiers and types.
This file must not be changed by the application!.
_xcp.cfg
XCP user config file template for the configuration on XCP Transport
Layer for CAN with CANgen.

Additionally the following files are generated by the generation tool GENy.
Files generated by GENy
xcp_cfg.h  Configuration file for XCP on CAN.
xcp_parc
Parameter definition for the XCP on CAN.
xcp_par.h  External declarations for the parameters.
v_cfg.h
General Vector configuration file for platform specifics.
v_inc.h
General header for including the Vector CANbedded stack headers.

Note that all files of XCP on CAN must not be changed manually except if CANgen is used
for the configuration of the CAN-Driver. In this case only the generated files xcp_cfg.h,
xcp_par.c and xcp_par.h are relevant and the additional general header for including
the generated header files _v_inc.h has to be customized and renamed to v_inc.h.

4.2 Version
changes
Changes and the release versions of the XCP Transport Layer for CAN are listed at the
beginning of the header and source code.

©2009, Vector Informatik GmbH
Version: 1.08
9 /  27
based on template version 1.3

Technical Reference XCP on CAN

4.3
Integration of XCP on CAN into the application
The Vector CANbedded stack includes optionally XCP on CAN, which comprises the XCP
Protocol Layer in conjunction with the XCP Transport Layer for CAN and the CAN-Driver.
Note that the CAN-Driver, which is distributed as a separate product, is only partly part of
XCP on CAN.
The following figure shows the interface between XCP on CAN and the application:

XCP on CAN
CAN Driver
(can_drv.c)
XcpCommand
XcpPreCopy
XCP on CAN
XcpConfirmation
Interface Layer
ApplXcpSend
XcpSendCallback
(xcp_can.c)
CanTransmit
XCP
Protocol Layer
( XcpProf.c )
XcpEvent
XcpInit
Application
XcpBackground
ApplXcp..

figure 4-1  Integration of XCP on CAN into the application

Practical Procedure
The integration of XCP on CAN can be done by following these steps:

1.  Configure XCP on CAN in the generation tool GENy and generate.
2.  Include the include header file v_inc.h into all modules that access the
XCP on CAN services or provide services that XCP on CAN uses.
3.  Add all source files and generated source files in the make file and link it
together with the data link layer and the application.
4. Initialize the data link layer after each reset during start-up before
initializing XCP on CAN (interrupts have to be disabled until the complete
initialization procedure is done) by calling XcpInit.
©2009, Vector Informatik GmbH
Version: 1.08
10 / 27
based on template version 1.3

Technical Reference XCP on CAN

5. If required call the background function XcpBackground cyclically.
6. Integrate the desired XCP on CAN services into your application. Call
especially the function XcpEvent(channel) cyclic with the appropriate
cycle time and channel number.
The XCP on CAN sources must not be changed for the integration into the
application.

©2009, Vector Informatik GmbH
Version: 1.08
11 / 27
based on template version 1.3

Technical Reference XCP on CAN

5 Description
of
the
API
The XCP on CAN application programming interface consists of services, which are
realized by function calls. These services are called wherever they are required. They
transfer information to- or take over information from XCP on CAN. This information is
stored in XCP on CAN until it is not required anymore, respectively until it is changed by
other operations.
Examples for calling the services of XCP on CAN can be found in the description of the
services.
5.1
Version of the source code
The source code version of the XCP Transportation Layer for CAN is provided by three
BCD coded constants:

V_MEMROM0 MEMORY_ROM vuint8 kXcpOnCanMainVersion =
(vuint8)(CP_XCPONCAN_VERSION >> 8);
V_MEMROM0 MEMORY_ROM vuint8 kXcpOnCanSubVersion =
(vuint8)(CP_XCPONCAN_VERSION);
V_MEMROM0 MEMORY_ROM vuint8 kXcpOnCanReleaseVersion =
(vuint8)(CP_XCPONCAN_RELEASE_VERSION);

Example
Version 1.00.00 is registered as:

kXcpOnCanMainVersion = 0x01;
kXcpOnCanSubVersion = 0x00;
kXcpOnCanReleaseVersion = 0x00;

These constants are declared as external and can be read by the application at any time.

©2009, Vector Informatik GmbH
Version: 1.08
12 / 27
based on template version 1.3

Technical Reference XCP on CAN

5.2
XCP Transport Layer for CAN services called by the Protocol Layer
The following XCP Transport Layer for CAN functions are called by the Protocol Layer.
The API of theses functions can be found in the header of the XCP on CAN components.

5.2.1 ApplXcpSend:
Transmission of XCP Packets
ApplXcpSend
Prototype
Single Channel
Single Receive Channel
void ApplXcpSend ( vuint8 len, const BYTEPTR msg )
Single Receive Buffer
N/a
Multiple Receive Buffer
N/a
Multi Channel
Indexed (MRC)
Not supported
Code replicated (SRB)
N/a
Code replicated (MRB)
N/a
Parameter
len
Length of the XCP Packet that has to be transmitted.
(with len = 1 ... 8)
msg
Pointer to the XCP Packet data.
Return code
-
-
Functional Description
Transmission of XCP Packets.

Particularities and Limitations
  Not reentrant
  Call context of: XcpEvent, XcpBackground and context of CAN-Driver

5.2.2 ApplXcpInit:
Initialization of XCP Transport Layer for CAN
ApplXcpInit
Prototype
Single Channel
Single Receive Channel
void ApplXcpInit ( void )
Single Receive Buffer
N/a
Multiple Receive Buffer
N/a
Multi Channel
Indexed (MRC)
Not supported
Code replicated (SRB)
N/a
Code replicated (MRB)
N/a
©2009, Vector Informatik GmbH
Version: 1.08
13 / 27
based on template version 1.3

Technical Reference XCP on CAN

Parameter
-
-
Return code
-
-
Functional Description
Initialization of the XCP Transport Layer for CAN.

Particularities and Limitations
  Not reentrant
  Call context of XcpInit

5.2.3
ApplXcpBackground: Background task of XCP Transport Layer for CAN
ApplXcpBackground
Prototype
Single Channel
Single Receive Channel
void ApplXcpBackground ( void )
Single Receive Buffer
N/a
Multiple Receive Buffer
N/a
Multi Channel
Indexed (MRC)
Not supported
Code replicated (SRB)
N/a
Code replicated (MRB)
N/a
Parameter
-
-
Return code
-
-
Functional Description
Cyclic background task of the XCP Transport Layer for CAN.

Particularities and Limitations
  Not reentrant
  Call context of XcpBackground

©2009, Vector Informatik GmbH
Version: 1.08
14 / 27
based on template version 1.3

Technical Reference XCP on CAN

5.3
XCP Transport Layer for CAN services called by the CAN-Driver
The following XCP Transport Layer for CAN functions are called by the CAN-Driver.
The API of theses functions can be found in the header of the CAN-Driver parameter file.

5.3.1
XcpPreCopy: XCP message precopy function
XcpPreCopy
Prototype
Single Channel CAN-Driver
Single Receive Channel
vuint8 XcpPreCopy ( CanRxInfoStructPtr rxStruct )
Single Receive Buffer
vuint8 XcpPreCopy ( CanReceiveHandle rxObject )
Multiple Receive Buffer
vuint8 XcpPreCopy ( CanChipDataPtr rxDataPtr )
Multi Channel CAN-Driver
Indexed (MRC)
vuint8 XcpPreCopy ( CanRxInfoStructPtr rxStruct )
Code replicated (SRB)
vuint8 XcpPreCopy ( CanReceiveHandle rxObject )
Code replicated (MRB)
vuint8 XcpPreCopy ( CanChipDataPtr rxDataPtr )
Parameter
rxStruct
Pointer to RxInfoStruct
rxObject
Handle of the received object
rxDataPtr
Pointer to received data
Return code
vuint8
kCanNoCopyData : no data needs to be copied by the CAN-Driver
Functional Description
Precopy function that is called upon every reception of a XCP message.

Particularities and Limitations
  Not reentrant
  Call context of CAN-Driver

©2009, Vector Informatik GmbH
Version: 1.08
15 / 27
based on template version 1.3

Technical Reference XCP on CAN

5.3.2 XcpConfirmation:
XCP message confirmation

XcpConfirmation
Prototype
Single Channel CAN-Driver
Single Receive Channel
void XcpConfirmation ( CanTransmitHandle tmtObject )
Single Receive Buffer
void XcpConfirmation ( CanTransmitHandle tmtObject )
Multiple Receive Buffer
void XcpConfirmation ( CanTransmitHandle tmtObject )
Multi Channel CAN-Driver
Indexed (MRC)
void XcpConfirmation ( CanTransmitHandle tmtObject )
Code replicated (SRB)
void XcpConfirmation ( CanTransmitHandle tmtObject )
Code replicated (MRB)
void XcpConfirmation ( CanTransmitHandle tmtObject )
Parameter
tmtObject
Transmit Handle of the confirmed message.
Return code
-
-
Functional Description
Confirmation function for the XCP message.
This function is called by the CAN-Driver whenever the XCP message has been transmitted successful.
Particularities and Limitations
Not reentrant
Call context of CAN-Driver

5.4
XCP Protocol Layer services called by the Transport Layer for CAN
The following XCP Protocol Layer services are called by the Transport Layer for CAN:
-
void ApplXcpInterruptEnable(void)
-
void ApplXcpInterruptDisbable(void)
-
void XcpCommand( MEMORY_ROM vuint32* pCommand )
-
void XcpSendCallBack( void )
-
vuint8 XcpGetState( void )
For a description of the API and the functionality of these functions please refer to the
Technical Reference XCP Protocol Layer [4].
5.5
CAN-Driver services called by the Transport Layer for CAN
The following CAN-Driver services are called by the Transport Layer for CAN:
-
vuint8 CanTransmit ( CanTransmitHandle tmtHandle )
For a description of the API and the functionality of these functions please refer to the
Technical Reference CAN Driver [5].
©2009, Vector Informatik GmbH
Version: 1.08
16 / 27
based on template version 1.3

Technical Reference XCP on CAN

6 Configuration of XCP on CAN
The configuration of XCP on CAN (XCP Protocol Layer and XCP Transport Layer for CAN)
is only supported by the generation tool GENy.
Therefore if the CAN-Driver is configured with CANgen two generation tools are used:
-
GENy for the configuration of the XCP Protocol Layer
-
CANgen for the configuration of the CAN-Driver. The XCP Transport Layer for CAN
has to be configured manually (refer to chapter 6.2).
6.1
Configuration of XCP on CAN with GENy
If GENy is used for the configuration of the whole CANbedded stack the configuration of
XCP on CAN is conveniently done by GENy. No database attributes are required for the
configuration of XCP on CAN.

figure 6-1 Component selection
©2009, Vector Informatik GmbH
Version: 1.08
17 / 27
based on template version 1.3

Technical Reference XCP on CAN

In order to configure the XCP Transport Layer for CAN (Cp_XcpOnCan) it has to be
activated on the designated channels. The activation of the XCP Transport Layer for CAN
requires to activate the XCP Protocol Layer (Cp_Xcp).
The configuration of each component is done on separate pages. Furthermore XCP
Transport Layer for CAN has ECU specific and channel specific settings that have to be
customized separately.
6.1.1
Main configuration page

figure 6-2  Main configuration page of XCP on CAN Transport Layer
Configuration options
Value
Description
XCP on CAN Transport Layer options
Variable DLC
  Enable
Activate/Deactivate the transmission of messages
  Disable
with variable DLC.
This option is not available yet!
Multi connection protection
  Enable
Activate/Deactivate the protection against multiple
  Disable
connections.
Only available if XCP on CAN is used on multiple
CAN channels.
Table 6-1  Main configuration page of XCP on CAN Transport Layer
©2009, Vector Informatik GmbH
Version: 1.08
18 / 27
based on template version 1.3

Technical Reference XCP on CAN

6.1.2
Channel configuration page
The messages can be selected in GENy within Component Cp_XcpOnCan under the
channel view (see below). The list boxes of the master/slave ID entry fields provide
messages which fit to the requirements. The user can select the appropriate message.

figure 6-3 Channel configuration page of XCP on CAN Transport Layer

Configuration options
Value
Description
Type of bus system
Ready Only
Bus system type for the specific channel.
Manufacturer
Ready Only
Value of the database attribute ‘manufacturer’.
XCP on CAN Transport Layer
Slave Id
Tx-ID
XCP Slave Identifier
This is the ID for Response Packets and DAQ packets.
Only IDs that are not IL, TP or Diag messages and that
have a DLC of 8 can be selected.
Master Id
RX-ID
XCP Master Identifier
This is the ID for Command Packets and STIM Packets.
©2009, Vector Informatik GmbH
Version: 1.08
19 / 27
based on template version 1.3

Technical Reference XCP on CAN

Only IDs that are not IL, TP or Diag messages and that
have a DLC of 8 can be selected.
Table 6-2  Channel configuration page of XCP on CAN Transport Layer
In case there are no messages of type Application available, no selection can be made in
the Master/Slave ID field.
In this case two possible solutions exist:
1. Change the attributes of the XCP message(s) in the database. There are special
attributes to specify a message as NM, TP, IL, etc.

In case this is not possible, use solution 2:

2. Within GENy an IL message can be configured to be ‘Appl’ message. In Tx and Rx
message view, set the checkbox ‘Application Message’ for the appropriate message (as
shown below, message B1_CCP). Then the type changes to Message Class ‘Appl’. Now
this message should be found in the slave or master ID selection.

figure 6-4  Changing message attribute to “Application Message”

6.1.3
Multiple Identity configuration
For information about setting up a Multiple Identity configuration please refer to the
according Technical Reference. This chapter only explains the XCP specific configuration.
For each configured Identity the Slave Id and Master Id must be configured. For a
configuration with Multiple Identity this is not done on the channel dependent page as
shown in chapter 6.1.2, but on the Identities page below the channel dependent page (s.
figure below).
©2009, Vector Informatik GmbH
Version: 1.08
20 / 27
based on template version 1.3

Technical Reference XCP on CAN

figure 6-5 Channel configuration page for Multiple Identity configurations of XCP on CAN Transport Layer

©2009, Vector Informatik GmbH
Version: 1.08
21 / 27
based on template version 1.3

Technical Reference XCP on CAN

6.2
Configuration of XCP on CAN with GENy and CANgen
If the CAN-Driver is configured by CANgen the configuration of the XCP Transport Layer
for CAN has to be done manually. The configuration of the XCP Protocol Layer is
performed conveniently by GENy.
Reference the user config file xcp.cfg on the XCP Protocol Layers main page in GENy
as shown in figure 6-6 and customize it according to Table 6-3.

figure 6-6 Adding a user config file in GENy

©2009, Vector Informatik GmbH
Version: 1.08
22 / 27
based on template version 1.3

Technical Reference XCP on CAN

Configuration options
Value
Description
XCP on CAN Transport Layer Options
XCP_TRANSPORT_LAYER_TYPE_CAN

Activate the XCP on CAN Transport Layer
XCP_xxx_VARIABLE_DLC
ENABLE
Activate/Deactivate the transmission of
DISABLE  messages with variable DLC.
This option is not available yet!
XCP_xxx_MULTI_CHANNEL
ENABLE
Enable support of multiple CAN channels
DISABLE
XCP_xxx_MULTI_CONNECTION_PROT
ENABLE
Protection against multiple connections.
ECTION
DISABLE  Only available if XCP on CAN is used on
multiple CAN channels
kXcpNumberOfCanChannels
2..255
Specify the number of CAN channels that
use XCP on CAN.
Only available if XCP on CAN is used on
multiple CAN channels
Table 6-3  Options and configuration of XCP on CAN Transport Layer

The XCP Slave ID and XCP Master ID have to be configured in the generation tool that
configures the CAN-Driver. If XCP on CAN is only used on one CAN channel refer to
chapter 6.2.1 ‘XCP on CAN uses only one CAN channel’ otherwise refer to chapter 6.2.2
‘XCP on CAN uses multiple CAN channels’.

6.2.1
XCP on CAN uses only one CAN channel
The generation tool CANgen has to be configured as follows:
  Add the precopy function XcpPreCopy for the XCP Master ID in your generation tool.
  Add the confirmation function XcpConfirmation for the XCP Slave ID in your generation tool.
The Transmit handle and the data buffer of the XCP Slave ID have to be defined in the
user config file xcp.cfg:
  #define XcpGetTransmitHandle() TransmitHandleOfSlaveId
#define XcpGetTransmitDataPtr() TransmitDataBufferOfSlaveId
  Replace TransmitHandleOfSlaveId by the transmit handle of the XCP Slave Id that can be
found in the header <node>.h.
  Replace TransmitDataBufferOfSlaveId by the transmit data buffer of the XCP Slave Id
that can be found in the header <node>.c.

Example for Slave Id XCP_DTO
#define XcpGetTransmitHandle() CanTxXCP_DTO

#define XcpGetTransmitDataPtr() (XCP_DTO._c)

©2009, Vector Informatik GmbH
Version: 1.08
23 / 27
based on template version 1.3

Technical Reference XCP on CAN

6.2.2
XCP on CAN uses multiple CAN channels
If XCP on CAN is used on multiple CAN channels (e.g. vehicle bus and private CAN) the
configuration of the XCP Master ID and XCP Slave ID is done by the following steps.
The generation tool CANgen has to be configured as follows:
  Add the precopy function XcpPreCopy for the XCP Master IDs in your generation tool.
  Add the confirmation function XcpConfirmation for the XCP Slave IDs in your generation tool.
The Transmit handles and the data buffers of the XCP Slave IDs have to be defined in an
additional source file.
V_MEMROM0 V_MEMROM1 CanTransmitHandle V_MEMROM2 xcpTxHandleField[] =
{
Tx handle of XCP Slave ID 1,
Tx handle of XCP Slave ID 2
};
V_MEMROM0 V_MEMROM1 TxDataPtr V_MEMROM2 xcpTxDataPtrField[] =
{
data bufferTx of XCP Slave ID 1,
data bufferTx of XCP Slave ID 2
};
The following macros have to be defined in the user config file xcp.cfg:
  #define XcpGetTransmitHandle() (xcpTxHandleField[xcpChannelNumber])
#define XcpGetTransmitDataPtr() (xcpTxDataPtrField[xcpChannelNumber])

Example for Slave Id XCP_DTO and XcpSlave

User config file xcp.cfg :
#define XcpGetTransmitHandle() (xcpTxHandleField[xcpChannelNumber])

#define XcpGetTransmitDataPtr() (xcpTxDataPtrField[xcpChannelNumber])

C Source Code:
V_MEMROM0 V_MEMROM1 CanTransmitHandle V_MEMROM2 xcpTxHandleField[] =
{
CanTxXCP_DTO,
CanTxXcpSlave
};

V_MEMROM0 V_MEMROM1 TxDataPtr V_MEMROM2 xcpTxDataPtrField[] =
{
XCP_DTO._c,
XcpSlave._c
};

©2009, Vector Informatik GmbH
Version: 1.08
24 / 27
based on template version 1.3

Technical Reference XCP on CAN

7 Limitations
7.1.1
Variable length of XCP Packets is not supported
The XCP protocol allows a variable length of XCP Packets. However many OEMs require
that all CAN messages sent within their automotive networks have to have a static DLC.
Therefore the DLC of XCP on CAN messages is always 8 and the Control Field of the
XCP Tails consists of fill bytes.

7.1.2
Assignment of CAN identifiers to DAQ lists is not supported
The assignment of CAN identifiers to DAQ lists is not supported.

7.1.3
Detection of all XCP slaves within a network
The detection of all XCP slaves within a network with the command GET_SLAVE_ID is not
supported.

7.1.4 Channel
API
XCP on CAN is only available with a single channel API.
However all currently available single and multiple channel APIs of the CAN-Driver are
supported.

7.1.5
Multiple Identity only supported for single channel configuration
Multiple Identity for XCP on CAN is only available fora single CAN channel configuration.

©2009, Vector Informatik GmbH
Version: 1.08
25 / 27
based on template version 1.3

Technical Reference XCP on CAN

8 FAQ
8.1
Transmit queue of CAN-Driver is disabled

FAQ
How to operate XCP on CAN if the transmit queue of the CAN-Driver is disabled.

If the transmit queue of the CAN-Driver is disabled at any time it might not be possible to
transmit the XCP Slave message due to an ongoing message transmission. Therefore the
message transmission might have to be requested several times.
This is done with the service ApplXcpBackground() that gets called by
XcpBackground(). This service has to be called cyclic with a recommended call cycle of
1ms. The faster it gets called the faster the XCP Slave message will participate in the
arbitration on the bus.

©2009, Vector Informatik GmbH
Version: 1.08
26 / 27
based on template version 1.3

Technical Reference XCP on CAN

9 Contact
Visit our website for more information on

> News
> Products
> Demo software
> Support
> Training data
> Addresses

www.vector-informatik.com
©2009, Vector Informatik GmbH
Version: 1.08
27 / 27
based on template version 1.3

Document Outline

Last modified October 12, 2025: Initial commit (1fadfc4)