Key features

<< Click to Display Table of Contents >>

Navigation:  Working with CanEasy > XCP >

Key features

 

Some standard commands:

 

Set up Connection With Slave

Disconnect From Slave

Get Current Session Status From Slave

Get Communication Mode Info

Get Identification From Slave

Request to Save to Non-volatile Memory

Get Seed for Unlocking a Protected Resource

Send Key for Unlocking a Protected Resource

Set Memory Transfer Address in Slave

Upload From Slave to Master

Build Checksum Over Memory Range

 

 

 

Address oriented memory read access

 

- Measurement

Reading memory periodically (polling)

No ECU specific code necessary

 

- Event synchronous measurement

Reading memory at a specific point in time or event (DAQ)

ECU specific code necessary

 

 

 

Address oriented memory write access

 

- Calibration

Writing memory periodically

No ECU specific code necessary

 

- Event synchronous calibration

Writing memory at a specific point in time or event (STIM)

ECU specific code necessary

 

 

 

Bypassing

 

Simultaneously making use of Synchronous Data Acquisition (DAQ) and Synchronous Data Stimulation (STIM)

At least two DAQ lists are required one DAQ list for reading variables (Data Acquisition) one DAQ list for writing variables (STIM)

Specific event channels required, which control the bypassing process

xcp_4

 

 

 

Time correlation

 

XCP offers services to read current value of the slave clock of the ECU

Enables the calibration tool to correlate measurement data from different ECUs

The command to get the XCP slave clock is GET_DAQ_CLOCK_FROM_SLAVE

 

 

 

Flash programming

 

- Flashing with XCP is roughly subdivided into three areas:

Preparation

(e.g. checking versions to avoid unsuitable memory content)

Execution
(new content is sent to the ECU and written to memory)

Post-processing
(e.g. checksum checking, etc.)

- Rather limited functionality
 (no serial number handling etc.)

- Information about the flash sectors etc. is part of the A2L file

 

 

 

ECU states

 

Two mechanisms to provide current ECU state:

Mandatory:
XCP slave reports the current state to the XCP master
in the response to the GET_STATUS command

Optional:
If XCP slave supports asynchronous event messages,
it can use the event EV_ECU_STATE_CHANGE 
to inform XCP master about a state change
and new STATE_NUMBER
XCP slave sends the event message to the XCP master once
with the next GET_STATUS request the XCP master receives the STATE_NUMBER again.

 

xcp_5