CCP / XCP on CAN Explained - A Simple Intro [2025]

Here, the CAN ID reflects the ID used by the CCP master for communication. The 1st byte is 0x01, corresponding to the CONNECT command as evident from the previous table. The 2nd byte is the CTR value. The 3rd and 4th bytes are specific to the CONNECT command and correspond to the target ECU's station address in Intel byte order. In other words, the above CRO is used by the master to establish a connection with ECU 0x0139. All subsequent communication will in this case be with this specific ECU until the master terminates the connection or connects to another ECU.

The trace shows a connection to the ECU with station address 0x0139, which responds to the initialization command sent by the master. As evident, the 1st byte is 0xFF (as the message is a CRM). The 2nd byte shows that no errors occurred, while the 3rd byte matches the CTR of the CRO. With this sequence, the connection between the master and ECU 0x0139 is established.

The trace shows the DAQ-DTO communication from a slave following an initial configuration sequence. The data relates to ODT list #37 (0x25) with a payload of 5 bytes. Note how we do not pad the unused bytes (as this is not required for DAQ-DTOs). Note also how a new CAN ID is introduced for this DAQ response (more on this later).

CRO, CRM-DTO and EV-DTO messages must have a payload length of 8. Any unused bytes are padded with arbitrary values (we use 0xAA in this intro). DAQ-DTO messages may use the actual payload size.

Note that the example does not use the 0xAA padding, as this is optional in XCP on CAN.

In the trace, the master sends a CONNECT CMD (0xFF) to the ECU with the communication mode set to normal (0x00). Note that, in contrast to CCP, the master does not need to specify a station address in the payload of the CONNECT frame. This is because the CAN identifiers already uniquely identify which ECU the master is communicating with.

The ECU responds with a CAN frame that can be decoded as per the CONNECT table above:

• The 1st byte equals the positive response PID 0xFF (RES)
• The 2nd byte is the resource availability (0x04 = 0b00000100 means that DAQ is available)
• The 3rd byte relates to the 'communication mode' (0x80 = 0b10000000 e.g. tells us that Intel byte order is used)
• The 4th byte is the maximum CTO size (here 8 bytes, meaning we are limited to Classical CAN CTOs)
• The 5th and 6th byte equal the maximum DTO size (here 8 bytes, meaning we are limited to Classical CAN DTOs)
• the 7th and 8th bytes equal the XCP protocol layer version and transport layer version respectively (both 1 in this case)

As before, we can interpret the response based on the table:

• The 1st byte equals the positive response PID 0xFF (RES)
• The 2nd byte is the session status (0x00 means that everything is reset and no active DAQs are running)
• The 3rd byte relates to the seed & key protection status (0x00 means that no commands are protected)
• The 5th and 6th byte equal the session config ID (0x00 means no active session)

The GET_STATUS command is particularly useful for obtaining information about whether certain commands (e.g. related to data acquisition via DAQ lists) are protected via seed & key authentication. Note that basic XCP polling via SHORT_UPLOAD commands is never protected via seed & key authentication.

It is also worth noting that multiple methods exist for packing the DAQ list # and ODT list # information in the DAQ DTOs. The simplest case is 'absolute ODT numbers', where the ODT list # is unique across all DAQ lists. Here, the PID (i.e. ODT #) is sufficient for globally identifying an ODT list. In the section on data logging we showcase this in action.

Another method exists, however, where relative ODT list numbers are used across DAQ lists. Thus, you could e.g. have two ODT lists with PID = 0x00, meaning that they cannot be uniquely identified as the CAN ID is identical across the two DTOs. Here, a 1 or 2 byte DAQ list identifier can be added in the 2nd to 3rd bytes of the CAN frame payload. With this, one can again uniquely identify a specific ODT list.

The A2L file and ECU will provide information on what method is used.

A 1-byte counter field may optionally be used in the communication of XCP DTOs. If a CTR field is used in XCP DTO DAQ packets, the slave will only insert the value of the CTR in the 1st frame of a DAQ list, i.e. in the 1st ODT list.

Most of our XCP on CAN overview assumes that the lower layer is Classical CAN. However, since v1.2, XCP can also be based on CAN FD, which adds a number of opportunities for optimization. If an ECU supports XCP on CAN FD, it may support longer CTO/DTO payloads beyond 8 bytes, which will then be evident from the CONNECT response by the ECU as per the table.

Support for CAN FD CTOs enables the master to leverage longer CAN FD frames when initializing DAQ lists, which can reduce the number of separate CAN messages significantly. Further, support fro CAN FD DTOs may allow for encoding much more ECU signal values into the same CAN frame data payload. This is powerful because it reduces busload, but also because it allows for better time synchronization of the data (as will become evident in the data logging section).

CCP/XCP of course contain numerous more topics that we have not taken the time to discuss here. Deliberately, we have focused on the basic topics and concepts related to data logging. However, below you'll find useful links for further reading.

• Vector's XCP Book v1.5: A detailed overview of the XCP 1.5 protocol
• XCP (Wikipedia): The basics on the XCP protocol
• ASAM MCD-1 XCP overview: Also provides a detailed overview of the XCP protocol
• ASAM ASAM MCD-2 MC overview: Provides an overview of the ECU description file standard
• Seed & key details (Vector): A useful intro to the basics on authorization

For CCP/XCP communication, incl. polling, the byte order is ECU specific and described in the A2L file. In the examples above we therefore provide both an Intel and Motorola example, though the selection here is arbitrary and not linked to whether the protocol is CCP or XCP. You can also identify the byte order based on the XCP CONNECT response by interpreting the 3rd byte (communication mode).

One restriction, however, is that in CCP communication the CONNECT message 2-byte station address is always Intel byte order.

Let us consider an example: We wish to record 7 signals, each of them with a length of 1 byte. To do so, we define a new ODT #0 (PID 0x00) with 7 element entries. Element 1 refers to signal 1 with a specific ECU source address. Element 2 refers to signal 2 with another source address etc.

When we use the DAQ mode for data measurement, we can now refer to ODT #0 in order to get the ECU to provide us with time synced data on all 7 signals - within a single DAQ-DTO CAN frame. In other words: The ODT we defined describes the structure of a DAQ-DTO message, meaning that the ECU will now know how to package the 7 signal bytes in a single CAN frame - and the master knows how to extract the 7 signal bytes from that CAN frame.

Notice the impact on the busload: If we were to poll all 7 signals, it would require 14 CRO/CRM-DTO CAN frames per cycle - now it only requires 1 DAQ-DTO CAN frame. Further, we can easily plot these 7 signals together as they share the same CAN frame timestamp - making it much easier to perform analysis. For the same reason, ODT lists are typically defined to group related signals together.

In practice, a master will often define multiple ODT lists and assign PIDs for each of them in the range of 0x00 to 0xFD. Each ODT then defines the structure of a separate DAQ-DTO.

So we have quite a bit going on here, but let's break it down:

We start by using the CRO command GET_DAQ_SIZE. This has two purposes: It informs us about the size of the specified DAQ list in terms of ODT lists - and it clears the current list. Essentially, this works like a 'reset' command for the DAQ list, in this case DAQ list #5.

As part of the GET_DAQ_SIZE command we also provide the 11-bit CAN ID 0x712 in the last 4 bytes. This informs the ECU that it should use CAN ID 0x712 to broadcast the subsequent DAQ-DTOs. This is subtle, but an important aspect: Essentially, the master is able to specify the CAN ID for every DAQ list, which in turn also enables the master to initiate DAQ measurement across multiple ECUs in parallel.

The ECU confirms the CRO from the master and informs us that the DAQ list #5 has 3 ODTs with the first PID being 0x07.

Next, the master starts populating DAQ list #5 and ODT list #7 with the source address information for 7 x 1-byte signals. This is done through a simple loop consisting of 7 repetitions of two commands: SET_DAQ_PTR and WRITE_DAQ.

First, the master uses SET_DAQ_PTR to "select" DAQ list #5, ODT list #7 and element #0 of the ODT list. Next, the master uses WRITE_DAQ to write the contents of this element reference: A length of 1, an address extension of 0 and a source address of 0x00001000.

Basically, we have now told the ECU to "package" the value of our 1st signal (which is stored in the specified source address) into the 2nd byte of the DAQ-DTO that corresponds to DAQ list #5 and ODT list #7 (the 1st byte of the DAQ-DTO being the PID 0x07).

After this, we repeat the process for the remaining 6 signals until the ODT #7 has been completed.

In this simplistic case we only care about this particular DAQ and ODT list. Therefore, the final step is to start the DAQ measurement via the START_STOP command. Here, we specify that we wish to start DAQ list #5 and ODT list #7. As part of this, we specify the timing parameters, namely that event channel 0x03 should be used with a prescaler of 10. The ECU specific event channel details are specified in the ECU description file.

As evident, the ECU will now start broadcasting data from DAQ list #5 and ODT list #7 at the specified frequency. The CAN frame payloads include the ODT PID 0x05 in the 1st byte and the 7 'element' signal values in the remaining payload.

Note also that you can alternatively use the START_STOP command to 'prepare' multiple DAQ lists and ODT lists for measurement and then use the START_STOP_ALL command to simultaneously start or stop all of them.

Below example trace shows an already initiated DAQ sequence:

In this example, the target ECU is broadcasting data across three ODTs in total, as evident from the 1st bytes spanning from 0x00 to 0x02. While it's not explicitly clear from the trace, the three ODTs are split into two DAQ lists: One DAQ list contains ODT #0 with a sampling frequency of 10 ms - while DAQ list #1 contains the remaining ODT lists #1 to #2 with a sampling frequency of 100 ms. This is why the DAQ-DTO with PID 0x00 is observed more frequently in the trace vs. the other DAQ-DTOs.

In this trace, we explicitly show the initial CONNECT and GET_STATUS command, which are typically used prior to starting a DAQ initialization sequence. The ECU responses to these commands can yield useful information about DAQ-related capabilities of the ECU as explained in the XCP CTO section - see also the related 'response tables' for these commands. In particular, note that the CONNECT response tells us that the client supports 0x40 (64) byte CTOs and DTOs, though for exposition we use Classical CAN frames in this example only. The CONNECT response also informs us that the ECU uses Intel byte order. The GET_STATUS response tells us that the ECU does not use seed & key authentication for any commands, including DAQ.

Let us outline the rest of the example:

• The master starts by clearing any dynamic DAQ lists via the FREE_DAQ command
• Next, the master uses ALLOC_DAQ to allocate a single DAQ list
• Next, the master uses ALLOC_ODT to allocate 4 ODTs to the DAQ list 0x0000
• After this the master uses ALLOC_ODT_ENTRY for each of the 4 ODTs to specify the number of elements/signals
• Now that the basic allocations are done, the master uses SET_DAQ_PTR to target a specific DAQ list (0x0000) and ODT (0x00). Subsequently the master uses WRITE_DAQ commands to allocate specific ECU signals to the target. Notice how each WRITE_DAQ specifies the byte length of the signal, but not the payload position (this is handled by the ECU). Note also that with Classical CAN, the payload per ODT is limited to 7 data bytes. This process is repeated for each of the 4 ODTs
• Once the signal writing is done, the master uses SET_DAQ_LIST_MODE to 'configure' the targeted DAQ list 0x0000. The 2nd byte, MODE, is set to 0x00, which means the 'direction' is slave-to-master (for data acquisition), timestamps are not included in the DAQ-DTO payloads - and the ODT PID is not disabled, meaning that the 1st byte of the DAQ-DTOs will reflect the ODT identifier field. The EVENT_CHANNEL_NUMBER 0x0002 is linked to a specific 'trigger event' in the ECU, in this case implying that the DAQ list is broadcast periodically every 5 ms. The prescaler value is set to 1, meaning we do not downscale the frequency of the DAQ list
• Finally, the master uses the START_STOP_DAQ_LITS to 'select' DAQ list 0x0000 for synced startup - and then uses START_STOP_SYNCH to actually trigger the start of the DAQ-DTO communication from the ECU

At the end of the trace we see how the ECU starts producing the four separate DAQ-DTOs, each linked to the relevant ODT via the PID in the 1st byte. Note also how the length of the DAQ-DTOs corresponds to the total byte length of the signals assigned to the respective ODTs during the WRITE_DAQ step.

This trace is very similar to the previous one, but now includes multiple separate DAQ lists. A few highlights:

• In DAQ list 0x0000 ODT 0x01 the master assigns 0x0F (15) elements, which requires 15 x WRITE_DAQ commands because the master uses Classical CAN frames for the initialization. The total byte length of these 15 elements is 24 bytes as evident from the final DAQ-DTO related to this ODT. When accounting for the PID, that means 25 bytes are required in total. In CAN FD, it is necessary to 'round up' to the closest supported data length, which in this case is 32 bytes - meaning that some padding is included
• Notice also how we include the ECU slave responses to the two START_STOP_DAQ_LIST commands. This is to show how the ECU responds with the FIRST_PID value, telling the master what the first PID is for each DAQ list (related to absolute PID numbering)
• The example also shows how the two DAQ lists use separate event channels (0x0002 = 5 ms and 0x0003 = 10 ms periodic broadcast)

In this example, the master fully leverages CAN FD in both the XCP CTOs (for the initialization) and DTOs (for the subsequent DAQ-DTO communication).

Specifically, the master uses the WRITE_DAQ_MULTIPLE to add 7 elements to a single DAQ list and ODT within a single write command. As evident, this command requires specifying the number of elements (0x07) and then essentially parsing a similar structure as in the regular WRITE_DAQ commands, though with the extension and ECU address field order reversed.

The resulting DAQ-DTO contains all 7 elements (14 data bytes). As the required data length incl. the PID is 14 + 1 = 15 bytes, the closest CAN FD frame length is 16 bytes and therefore 1 byte of padding is added.

Here, the 3rd byte 0x01 means that we end the session entirely (in contrast to a temporary disconnection). This effectively resets the ECU including our previous configuration. To target the specific ECU of interest, we specify the station address (Intel format) of the ECU, i.e. 0x702.

As evident, DAQ is more convoluted to set up - but enables efficient time synced communication of ECU data.

In this example, the master first stops the existing DAQ communication via the START_STOP_SYNCH command (with the 2nd byte set to 0x00). After this, the master disconnects the overall XCP session. Notice how this command is simpler vs. CCP as the XCP master does not need to target a specific ECU address (as this is implicit from the CAN IDs used).

In the above example, the master is requesting two different 4-byte signal values from the ECU, namely from source addresses 0x12345678 and 0xABCDEF00. In both cases, the ECU responds with CAN ID 0x702.

In most CAN bus decoding scenarios, you would be able to simply lookup the response CAN ID and find the 'start bit' and 'bit length' of a given signal to extract the raw data from the payload.

However, that is not possible here as the ECU uses the same CAN ID across two different signals. In other words, the CAN ID is not sufficient to distinguish between the signal coming from 0x12345678 and the one coming from 0xABCDEF00.

To some extent, this is similar to how OBD2 responses from an ECU use the same CAN ID (typically 0x7E8) across different signals like speed and RPM. In the case of OBD2 we can, however, easily solve this because the OBD2 PID (Parameter Identifier) is included in the payload. Together with the CAN ID, this serves as a unique identifier within the response frame - enabling us to view the response as a case of multiplexing.

We cannot directly do this in CCP polling because the response payload does not include the ECU source address. In other words: In use cases with multiple CCP polling signals we need to combine information from the request & response message.

In most practical applications, it is reasonable to assume that you will know this signal encoding. This is because the master itself controls (via the initialization sequence) how to package each signal into the DAQ and ODT lists, as explained in the previous section.

For example, we know that the DAQ-DTOs with CAN ID 0x712 and ODT PID 0x07 contain the signal with source address 0x00001000 in the 2nd byte - because that is how we packaged it during the initialization. From the ECU description file we can then review how to interpret this 1-byte signal value. The description may state that this signal is a temperature measured in degC and it should be multiplied by a factor of 0.8 and offset by 20. If you're familiar with DBC files, you'll note that such information can easily be entered into a DBC, allowing for quick decoding of the trace data in most CAN software tools.

Naturally, if the master changes the initialization to package the data differently on another test run, the implication will be that the DBC file must be updated accordingly.

As before, we can compare this to the logic of signal encoding in other CAN protocols and in DBC files. The 'MEASUREMENT' tag is used to envelop the description of a measurement signal, in this case Airflow. It has a detailed description and a min/max defined by the lower/upper limit.

The signal also has a 4-byte source address, 0x40000144. If we recall the CCP polling outline, this source address could be used in a SHORT_UP command polling sequence to request the raw value for this particular ECU signal. Similarly, in the context of DAQ measurement, this source address would be used in the initialization process. In other words, an engineer can lookup the signal of interest (Airflow) in a A2L file or A2L GUI tool - and configure his master tool to request this.

Assuming we've now recorded a trace of raw values, we'd need to decode the information. As explained before, the first step would be to extract the raw bytes from the response payload - and the method for doing this will depend on whether we're using polling or DAQ measurement. Further, the byte ordering is not specified by the CCP protocol - but will be specified within the A2L file at a global or signal level.

As outlined, this conversion rule uses a conversion type called RAT_FUNC. This is one of multiple supported conversion types and is defined as below:

As evident, the rational function is a more sophisticated version of the linear function used in DBC files. In particular, it supports 6 coefficients, which are specified in the computation method. Importantly, the equation is reversed in comparison with e.g. the LINEAR computation method. To compare this to e.g. DBC files, we first need to 'solve for phys'.

In 99% of RAT_FUNC cases, the coefficients a, d, e equal 0, meaning the function can be simplified as below:

In the example, the coefficients are set to 0 1 0 0 0 1, meaning the function simplifies to below:

In this simple case, the rational function simplifies to a linear function, similar to the one used in DBC files. A2L files in fact also support another conversion type, LINEAR, which is simply phys = a*raw + b. In the case of the Airflow signal, this could have been used instead.

Finally, the unit is also specified in the measurement details, meaning we can now plot the Airflow physical value as measured in kg/s. The Format field is %6.2, which should be read as %Length.Layout, with Length reflecting the overall length of the decoded signal and Layout reflecting the number of decimal places.

As is probably clear, one does not normally look through the A2L file via a text editor. Rather, the A2L file is simply loaded in a compatible tool (e.g. a PC GUI tool with a connected CAN interface, or a CAN data logger). This then allows the engineer to use the tool to perform the relevant measurement from the ECU without having to understand the A2L file structure and syntax.

In this example, the master requests the seed via the GET_SEED command 0x12, specifying a 'resource mask' of 0x02 in the 3rd byte. The resource mask references the level of access requested - with 0x02 being DAQ access only (see the CCP 2.1 standard for details).

The ECU responds with a frame in which the 4th byte is 0x01, implying that DAQ access is protected (in contrast to 0x00 which would imply that authentication would not be required). The ECU provides the requested seed in the remaining 4 bytes.

Based on the seed, the ECU calculates the key and provides it via the UNLOCK command, 0x13. The key is in this case 4 bytes long. The ECU responds positively including the requested resource mask 0x02, meaning that DAQ access is now unlocked.

The most common implementation of the security algorithm is via a *.dll file, since the master device is frequently a Windows PC with a GUI tool and a CAN interface. The use of a *.dll file also enables standardization across CCP tools, while eliminating the need for the master tool to know the underlying algorithm used.

It is, however, challenging to use *.dll files in standalone CAN bus data loggers and telematics devices (as they do not run Windows), hence some companies use alternative solutions - e.g. proprietary file formats better suited for embedded devices.