XCP Commands
The XCP commands are half of the way to learn about the calibration protocol. Start mastering them in this article
Last time out, on the article What is XCP (opens in a new tab), we gave you a very thorough overview of what XCP is (hence the title) and what it can do. That ranged from DAQ lists and events to the types of available frames and CTO/DTO's. Today, we'll learn about the available commands (at least, most of them) at your disposal and how you can use them. We also recommend, before starting, that you learn a bit about calibration, if this concept is vague to you: Calibration Overview (opens in a new tab).
There will be lots of tables, and these will be divided into categories: standard commands, calibration, programming, calibration paging and DAQ/STIM related commands. So, get ready for a lot of tables and remember to leave this in your bookmarks, for the next time you have to deal with the CAN frames of this module, or something else. It will prove useful. Let's start:
- Standard Commands - The commands you cannot do without. At least, some of them. You are likely to need most, if not all the items on this list to use the other XCP commands properly:
ID | Name | Mandatory | Description |
---|---|---|---|
0xFF | CONNECT | Yes | Start an XCP session. Only after a positive response from the ECU the communication via XCP can start. The response describes the XCP configuration, including the maximum CTO/DTO size and the supported packages (calibration paging, XCP programming, ...) |
0xFE | DISCONNECT | Yes | Stops an XCP communication session. It can be sent autonomously by the ECU (in case of issues, such as timeouts or overloads) or issued by the master |
0xFD | GET_STATUS | Yes | Learn about the current status of the XCP slave, along with other useful information, such as which resources are protected via seed/key |
0xFC | SYNCH | Yes | Used to synchronize command execution after timeouts |
0xFB | GET_COMM_MODE_INFO | No | Retrieve information about communication timings to be obeyed by the tester, such as the minimum separation time between frames and the maximum block size |
0xFA | GET_ID | No | Used to identify the XCP slave |
0xF9 | SET_REQUEST | No | Request to save the current DAQ configuration into the NvM. Part of the XCP_RESUME mode, which we'll cover someday |
0xF8 | GET_SEED | No | Part of the seed and key mechanism, necessary to unlock specific resources. Gets the seed |
0xF7 | UNLOCK | No | Unlock the protected resources, by providing the key obtained by processing the provided seed from the XCP slave |
0xF6 | SET_MTA | No | Point to a specific address in memory. Used generally before some other commands, such as download, upload, build checksum |
0xF5 | UPLOAD | No | Read data from the ECU, starting at the specified address by SET_MTA. Resultomg MTA-pointed address will have number of read bytes added |
0xF4 | SHORT_UPLOAD | No | Read data from the ECU, with a size smaller than or equal to MAX_CTO / AG |
0xF3 | BUILD_CHECKSUM | No | Perform the checksum of an area starting at MTA. Integral part of calibration page switching, to detect changes in calibration |
0xF2 | TRANSPORT_LAYER_CMD | No | Perform a specific transport layer command, such as defining a PDU dynamically |
0xF1 | USER_CMD | No | User-specific command, to perform a functionality designed by the user |
- Calibration - It would be very unfortunate if your module has calibration in the name and you cannot calibrate. These are the commands that allow you to write values into the ECU:
ID | Name | Mandatory | Description |
---|---|---|---|
0xF0 | DOWNLOAD | Yes | Write data into the XCP slave |
0xEF | DOWNLOAD_NEXT | No | Write consecutive data blocks into the XCP slave |
0xEE | DOWNLOAD_MAX | No | Write data into the ECU, at the maximum available size (MAX_CTO / AG - 1) |
0xED | SHORT_DOWNLOAD | No | Write data into the ECU, with a length smaller than or equal to MAX_CTO / AG |
0xEC | MODIFY_BITS | No | Perform bitwise operations inside 32 bits |
- Programming - One valued XCP capability is the ability to reprogram the ECU. We know, UDS can also do it, but there might be some advantages to using XCP for this. It's up to your architecture to decide which make more sense (why not both? Everyone's happy). We promised to show you what commands are available for programming via XCP, so here they are:
ID | Name | Mandatory | Description |
---|---|---|---|
0xD2 | PROGRAM_START | Yes | Start a programming sequence |
0xD1 | PROGRAM_CLEAR | Yes | Clear a range of memory before reprogramming |
0xD0 | PROGRAM | Yes | Reprogram a segment of memory |
0xCF | PROGRAM_RESET | Yes | Signals the end of a programming sequence |
0xCE | GET_PGM_PROCESSOR_INFO | No | Get information regarding the programming processor |
0xCD | GET_SECTOR_INFO | No | Get information regarding a specific memory sector |
0xCC | PROGRAM_PREPARE | No | Prepare a donwload command with the intent of reprogramming |
0xCB | PROGRAM_FORMAT | No | Describe the format of the upcoming, uninterrupted memory transfer before reprogramming |
0xCA | PROGRAM_NEXT | No | Transmit reprogramming data in block mode |
0xC9 | PROGRAM_MAX | No | Transmit the maximum available data allowed (MAX_CTO / AG - 1) |
0xC8 | PROGRAM_VERIFY | No | Perform verification after reprogramming |
- Calibration Paging - We already explained what calibration paging is, in one of our referenced articles in the introduction. But, if you are distracted and/or never heard of it: calibrations are usually stored in Flash, and the solution to write to Flash memory in runtime is to emulate it, via calibration paging. You basically configure a part of your RAM to emulate an address range of Flash memory and whenever a write/read access is performed to it, XCP will check if you are inside the working page (RAM) or reference page (ROM) and (usually via hardware) provides you R/W access to the Flash. Calibration paging is not limited to this, and we'll try to cover it in greater detail in the future. But for today, these are the calibration paging commands available via XCP:
ID | Name | Mandatory | Description |
---|---|---|---|
0xEB | SET_CAL_PAGE | Yes | Set to a speficic calibration page |
0xEA | GET_CAL_PAGE | Yes | Get the index of the current calibration page |
0xE9 | GET_PAG_PROCESSOR_INFO | No | Get information regarding the calibration paging processor |
0xE8 | GET_SEGMENT_INFO | No | Get information regarding a segment of a calibration page |
0xE7 | GET_PAGE_INFO | No | Get information on a specific calibration page |
0xE6 | SET_SEGMENT_MODE | No | Set the mode of a segment |
0xE5 | GET_SEGMENT_MODE | No | Get information on the current mode of a segment |
0xE4 | COPY_CAL_PAGE | No | Copy one calibration page to another |
- DAQ/STIM - At the heart of XCP, there is the cyclic data read and write access. These concepts are rather simple to understand, given you have read the first part. If not, we heavily recommend. Now, that you did (we hope you did), here are the commands for cyclic data acquisition/stimulation:
ID | Name | Mandatory | Description |
---|---|---|---|
0xE3 | CLEAR_DAQ_LIST | Yes | Clear a DAQ list configuration |
0xE2 | SET_DAQ_PTR | Yes | Select a DAQ list to write or read it |
0xE1 | WRITE_DAQ | Yes | Write an ODT entry to the pointed DAQ |
0xE0 | SET_DAQ_LIST_MODE | Yes | Set the mode of a DAQ list |
0xDE | START_STOP_DAQ_LIST | Yes | Start or stop acquisition on a DAQ list (or select for use in RESUME_MODE) |
0xDD | START_STOP_SYNCH | Yes | Start or stop multiple DAQ lists synchronously |
0xDC | GET_DAQ_CLOCK | No | Get the clock of a DAQ from the XCP slave |
0xDB | READ_DAQ | No | Read an ODT entry of a DAQ list |
0xDA | GET_DAQ_PROCESSOR_INFO | No | Get information on the DAQ processor |
0xD9 | GET_DAQ_RESOLUTION_INFO | No | Get information on the resolution capabilities of a DAQ processor |
0xD8 | GET_DAQ_LIST_INFO | No | Get information on a DAQ list |
0xD7 | GET_DAQ_EVENT_INFO | No | Get information on a specific event |
0xD6 | FREE_DAQ | No | Free all configured DAQ lists (dynamic configuration) |
0xD5 | ALLOC_DAQ | No | Allocate a DAQ list (dynamic configuration) |
0xD4 | ALLOC_ODT | No | Allocate an ODT to a DAQ list (dynamic configuration) |
0xD3 | ALLOC_ODT_ENTRY | No | Allocate an ODT entry inside an ODT (dynamic configuration) |
0xC7 | WRITE_DAQ_MULTIPLE | No | Write multiple ODT entries into a DAQ list |
Quite a dosage of commands, right? We hope you are one of the strong ones who managed to grasp this article. Although it's a gigantic list, it has nothing on UDS. Don't believe us? Check our UDS articles ( UDS Overview (opens in a new tab) and UDS Frames and NRC Codes (opens in a new tab)) and tell us something!
Author: Micael Coutinho (opens in a new tab)
References:
- ASAM MCD-1 XCP - ASAM (opens in a new tab)
- Specification of Module XCP - Autosar Specification (opens in a new tab)
© AutosarToday —@LinkedIn