XCP on CAN, Ethernet, and SPI - Calibration & XCP Protocol

XCP on CAN: Configuration and Limits

Parameter	Description	Typical Value
CAN_ID_MASTER	CAN ID for tool→ECU command frames	0x600 (or A2L-defined)
CAN_ID_SLAVE	CAN ID for ECU→tool response and DAQ frames	0x601 (or A2L-defined)
BAUDRATE	CAN bus speed	500 kbps standard; 2/5 Mbps CAN-FD
MAX_CTO	Max command transfer object size (bytes)	8 (Classic CAN), 64 (CAN-FD)
MAX_DTO	Max data transfer object size (bytes)	8 (Classic CAN), 64 (CAN-FD)

A2Lxcp_on_can.a2l

/begin IF_DATA XCP
  /begin XCP_ON_CAN
    XCP_MASTER_CANID 0x600      /* CRO: command response object */
    XCP_SLAVE_CANID  0x601      /* DTO: data transfer object */
    BAUDRATE         500000     /* 500 kbps */
    SAMPLE_POINT     75.0       /* 75% sample point */
    BTL_CYCLES       10
    SJW              1
    MAX_CTO          8
    MAX_DTO          8
  /end XCP_ON_CAN
/end IF_DATA

XCP on Ethernet: High-Bandwidth DAQ

A2Lxcp_on_eth.a2l

/begin IF_DATA XCP
  /begin XCP_ON_IP
    TCP                         /* or UDP for lower overhead */
    PORT 5555                   /* TCP port — tool connects here */
    HOST_ADDRESS "192.168.1.100" /* ECU IP address */
    MAX_CTO 256                 /* large command packets */
    MAX_DTO 1500                /* near-MTU DAQ packets */
    /begin DAQ_EVENT
      SHORT_NAME "event_1ms"
      EVENT_CHANNEL_NUMBER 0
      MAX_DAQ_LIST 64
      TIME_CYCLE 1              /* ms */
      CONSISTENCY DAQ           /* all signals in list sampled atomically */
    /end DAQ_EVENT
  /end XCP_ON_IP
/end IF_DATA

Transport	MAX_DTO	Max DAQ Channels at 10ms	CAN Bus Load Impact
XCP/CAN (Classic)	8 bytes	~40 float32 signals	Each DAQ packet = 1 CAN frame — significant load
XCP/CAN-FD	64 bytes	~320 float32 signals	Reduced frame count vs Classic CAN
XCP/ETH (TCP)	1500 bytes	~5000 float32 signals	Zero CAN load; requires Ethernet interface on ECU

XCP on SPI: Internal ECU Multi-Core Calibration

XCP/SPI is used on multi-core SoCs where a dedicated measurement processor accesses the main application core's memory via a high-speed SPI bus — no external CAN connection required for measurement. The calibration tool communicates with the measurement processor, which bridges to the application core's RAM.

Cxcp_spi_slave.c

/* XCP SPI slave: lightweight framing, no IP stack */
/* Used on secondary core of Renesas RH850 or NXP MPC57xx */

void XcpSpi_RxCallback(uint8* rxBuf, uint16 len)
{
    /* Parse XCP frame from SPI data */
    XcpPacket_t* pkt = (XcpPacket_t*)rxBuf;

    switch (pkt->cmd) {
        case XCP_CMD_CONNECT:
            XcpSpi_SendConnectResponse();
            break;
        case XCP_CMD_DOWNLOAD:
            /* Proxy DOWNLOAD to application core RAM via IRAM bridge */
            AppCore_WriteMemory(pkt->mta, pkt->data, pkt->length);
            XcpSpi_SendPositiveResponse();
            break;
        case XCP_CMD_DAQ_UPLOAD:
            /* Read application core RAM for DAQ */
            AppCore_ReadMemory(pkt->mta, localBuf, pkt->length);
            XcpSpi_SendDataResponse(localBuf, pkt->length);
            break;
    }
}

MAX_CTO / MAX_DTO Tuning for High Channel Count

💡 Why MAX_DTO Size Matters for DAQ

Each DAQ packet transmitted from ECU to tool carries measurement data. With MAX_DTO=8 bytes (XCP/CAN), one CAN frame can hold at most two float32 values (8 bytes). To sample 100 float32 signals at 10ms requires 50 CAN frames every 10ms = 5000 frames/second, consuming ~50% of a 500 kbps CAN bus. Switching to XCP/ETH with MAX_DTO=1500 bytes packs 375 float32 values per UDP packet — 100 signals in one packet every 10ms, zero CAN load.

Scenario	Recommended Transport	MAX_DTO	Rationale
Development bench, ≤40 signals at 10ms	XCP/CAN	8 bytes	Standard CAN sufficient
Integration testing, 100+ signals	XCP/CAN-FD	64 bytes	Higher bandwidth, same wiring
Vehicle calibration, 300+ signals at 1ms	XCP/ETH	1500 bytes	Only viable option for high channel-rate
Multi-core SoC internal calibration	XCP/SPI	64 bytes	No physical CAN/ETH needed on internal bus

Summary

XCP transport selection is driven by channel count and sample rate requirements. XCP/CAN is the default for bench and vehicle calibration with modest signal counts. XCP/ETH is required for high-channel-count DAQ at kilohertz rates — it eliminates CAN bus load as a DAQ bottleneck entirely. XCP/SPI serves internal multi-core ECU calibration without an external interface.

🔬 Deep Dive — Core Concepts Expanded

This section builds on the foundational concepts covered above with additional technical depth, edge cases, and configuration nuances that separate competent engineers from experts. When working on production ECU projects, the details covered here are the ones most commonly responsible for integration delays and late-phase defects.

Key principles to reinforce:

Configuration over coding: In AUTOSAR and automotive middleware environments, correctness is largely determined by ARXML configuration, not application code. A correctly implemented algorithm can produce wrong results due to a single misconfigured parameter.
Traceability as a first-class concern: Every configuration decision should be traceable to a requirement, safety goal, or architecture decision. Undocumented configuration choices are a common source of regression defects when ECUs are updated.
Cross-module dependencies: In tightly integrated automotive software stacks, changing one module's configuration often requires corresponding updates in dependent modules. Always perform a dependency impact analysis before submitting configuration changes.

🏭 How This Topic Appears in Production Projects

Project integration phase: The concepts covered in this lesson are most commonly encountered during ECU integration testing — when multiple software components from different teams are combined for the first time. Issues that were invisible in unit tests frequently surface at this stage.
Supplier/OEM interface: This is a topic that frequently appears in technical discussions between Tier-1 ECU suppliers and OEM system integrators. Engineers who can speak fluently about these details earn credibility and are often brought into critical design review meetings.
Automotive tool ecosystem: Vector CANoe/CANalyzer, dSPACE tools, and ETAS INCA are the standard tools used to validate and measure the correct behaviour of the systems described in this lesson. Familiarity with these tools alongside the conceptual knowledge dramatically accelerates debugging in real projects.

⚠️ Common Mistakes and How to Avoid Them

Assuming default configuration is correct: Automotive software tools ship with default configurations that are designed to compile and link, not to meet project-specific requirements. Every configuration parameter needs to be consciously set. 'It compiled' is not the same as 'it is correctly configured'.
Skipping documentation of configuration rationale: In a 3-year ECU project with team turnover, undocumented configuration choices become tribal knowledge that disappears when engineers leave. Document why a parameter is set to a specific value, not just what it is set to.
Testing only the happy path: Automotive ECUs must behave correctly under fault conditions, voltage variations, and communication errors. Always test the error handling paths as rigorously as the nominal operation. Many production escapes originate in untested error branches.
Version mismatches between teams: In a multi-team project, the BSW team, SWC team, and system integration team may use different versions of the same ARXML file. Version management of all ARXML files in a shared repository is mandatory, not optional.

📊 Industry Note

Engineers who master both the theoretical concepts and the practical toolchain skills covered in this course are among the most sought-after professionals in the automotive software industry. The combination of AUTOSAR standards knowledge, safety engineering understanding, and hands-on configuration experience commands premium salaries at OEMs and Tier-1 suppliers globally.