CCP uses generic commands, which are not node specific, to perform different functions in a slave node. As the commands are generic every node must have an individual station address. A logical connection between master and slave has to be set up before any commands can be sent. This connection persists until the master decides to connect to another slave node or until the master sends a disconnect command. After the connection the master controls all communication between master and salve. Every message from the master is followed by a reply message from the slave containing data or error codes.
CCP-specific CAN messages
CCP is built on the CAN 2.0B protocol. All messages are 8 bytes long.
Only two types of CAN messages is needed, CRO and DTO, one for each direction. The CRO (Command Recieive Object) messages are sent from master to slave and contain control commands. DTO (Data Transmission Object) messages are sent from slave to master. When a slave has received a CRO message it performs the given instructions and then answers with a DTO message containing a CRM (Command Return Message). The CRM code tells the master if the corresponding control command has been performed as planned or not.
Figure 2: CRO and DTO messages
The CAN identifiers used for the CRO and DTO messages are determined by a configuration file (“A2L file”, defined by the ASAM MCD 2MC/ASAP2 standard) which is used to configure the master. The configuration file may also contain information about the slave memory organization, which is useful for data acquisition and calibration. Since the CAN identifiers define the priority of the message it should be chosen in a way that does not disturb the ordinary traffic on the bus. CCP does not determine which byte order to use (Motorola or Intel) in general data transmission. There is an exception that states that the byte order for the station address used when establishing a connection between master and slave has to be Intel (LSB first).
Description of CRO messages
CRO messages are sent from master to slave and contain instructions. The first byte is a command code (CMD) which describes the purpose of the message. The second byte is a command counter (CTR) and is used for keeping track of the communication. The command counter is also expected to be sent in return in the DTO message from the slave. Bytes 2-7 are reserved for data parameters depending on the command code. A message is always 8 bytes long and bytes which are not defined are considered as do not care”.
Description of DTO messages
The DTO message is sent by the slave as a receipt of a received CRO message and it is also used for data acquisition. The first byte in the message is called PID (Packet ID). The value of the PID describes the message type. There are three types of messages:
- 0xFF, command return message (CRM), if the DTO is sent as a receipt of
a CRO message.
- 0xFE, event message, if the DTO reports internal slave status changes
in order to invoke error recovery or other services.
- 0 – 0xFD, data acquisition message (DAQ). This PID has the value of an
ODT (Object Descriptor Table), which is described later.
Data acquisition (DAQ)
The master device can initiate and start data acquisition from the slave device. Data is sent from the slave with special DAQ-DTOs. The data bytes are organized in DAQ lists which consists of a number of ODT lists. An ODT list contains up to 7 pointers to memory addresses in the ECU where data is stored. Besides pointers to memory addresses a ODT-list can contain a address extension and the number of bytes to be sent. All slave devices don’t handle data elements longer than one byte and it is up to the master to solve this task by splitting up the data into single bytes.
Figure 5: Organization of ODT list
DAQ-DTO consists of a PID and the data elements of which the memory pointers in the ODT list points at. The PID number (usually the same as the ODT list) has a value between 0 and 253 which means that there can be only 254 ODT lists simultaneously.
Figure 6: Organization of DAQ lists
The CCP specification allows several DAQ lists, which can be simultaneously active. Transmission of DAQ lists is initiated by the master through a START_STOP command. Data bytes in the ODT lists are sampled in the slave device and then sent on the CAN bus in DAQ-DTOs. If a new START_STOP command is received by the slave before the ongoing DAQ cycle is finished, there are two ways to react. The new DAQ command is started and the ongoing is terminated or the ongoing cycle is finished and the new is ignored. There are advantages and disadvantages with both methods and the CCP specification doesn’t say which one to choose.
The following commands are included in the CCP specification (Figure 7). All commands don’t have to be implemented if the ability for calibration isn’t needed and are therefore marked as optional in the table below (Figure 7). Also GET_DAQ_SIZE, SET_DAQ_PTR, WRITE_DAQ, START_STOP (and START_STOP_ALL) are DAQ specific and don’t have to be implemented unless this resource is used. GET_SEED and UNLOCK are used to unlock CCP resources like data acquisition and calibration if they are protected by a key (password), which is optional.
Figure 7: Commands.
Depending on the error code from the slave and how critical it is, the master take different actions that are described in Figure 8.
Figure 8: Error handling.
Error C0 is a warning and no action is taken. If error C1 occurs there is an error in the communication or the node sending it is busy. On error C1 the master should wait the ACK time, described in figure 7, and then try to resend the message. This should be done two times. Error C2 might be a temporary power loss and can be solved by a re-initialization. Error C3 is irresolvable and the master should terminate the running session.
Cold Start” means that a new logical connection between master and slave is established with a CONNECT command and some further initialization.
Example of sequences
The examples describe commands to use, as master, for basic CCP communication.
Login session (Cold Start)
A typical connection between master and slave starts with a CRO containing a CONNECT command from the master. The slave should answer with a corresponding DTO. To make sure that both master and slave talks the same “language” a GET_CCP_VERSION command is sent from the master with the expected version number. If the version number sent in return from the slave matches, communication can proceed. For “plug ‘n play” compatible nodes EXCHANGE_ID command can be used for automatic session configuration, depending on station address. On command GET_SEED the slave node returns information about protection status (locked/unlocked) of resources (DAQ or Calibration). If, for some reason, a resource is locked it has to be unlocked before it can be used. To unlock a resource an UNLOCK command, with a “key” received in the GET_SEED DTO, has to be sent from the master. Before the login session is ended initialization of status bits are recommended, this is done with SET_S_STATUS command.