-
- CCP命令
- 连接命令(CONNECT)
- CCP命令
按照CCP协议,主设备必须先与总线上的某个从设备建立逻辑连接,才能与其开始通信。CONNECT命令就是主设备用来和从设备建立逻辑连接的,其中包括了从设备的ECU地址。在该命令之后送出的所有命令都是针对被选中的从设备节点发送的,直到有一个新的ECU地址被选中。
如果主设备使用CONNECT命令连接一个新的ECU,则与当前ECU的连接会暂时断开。如果使用CONNECT命令连接一个已处于连接状态的ECU,则该ECU返回一个确认信息。只有当某个ECU被正确连接后,该ECU才会对主设备发出的CRO命令做出响应。CCP协议支持Motoroal或Intel的数据格式,但CONNECT,命令中的ECU站地址必须采用Intel格式(低字节在前)。
以下为CONNECT命令的CRO数据场结构。
位 置 | 类 型 | 描 述 |
0 | 字节 | 命令代码=0x01(CONNECT) |
1 | 字节 | 命令序号=CTR |
2 | 字 | ECU地址 |
4~7 | 字节 | 无效 |
针对CONNECT命令反馈DTO数据场结构。
位 置 | 类 型 | 描 述 |
0 | 字节 | Packet ID:0xFF |
1 | 字节 | 命令返回代码=ERR |
2 | 字节 | 命令序号=CTR |
4~7 | 字节 | 无效 |
例如,主设备需要和某个从设备建立连接,向其发送一条CONNECT命令,该ECU的站地址为0x0200。当前指令序列号的值为0x45,则CRO结构为
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0x01 | 0x45 | 0x00 | 0x02 | -- | -- | -- | -- |
注测试:实现程序中对mcu ecu地址cmd[2]为0x1F,cmd[3]为0x2F。
从设备对该指令返回一个DTO,其中包括确认代码ERR及CTR。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0xFF | 0x00 | 0x45 | -- | -- | -- | -- | -- |
-
-
- 交换站标识符(EXCHANGE_ID)
-
在ASAP标准中,MCD系统与ECU的通信需要ASAP2描述文件的支持,通过该条命令,自动化系统可由DTO返回的ID标识符自动为ECU分配一个ASAP描述文件。EXCHANGE_ID命令的CRO数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | 命令代码=0x17(EXCHANGE_ID) |
1 | 字节 | 命令序号=CTR |
2 | 字节 | CCP主设备ID信息(可选,根据实际应用情况而定) |
针对EXCHANGE_ID命令反馈的DTO数据场结构如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | Packet ID:0xFF |
1 | 字节 | 命令返回代码=ERR |
2 | 字节 | 命令序号=CTR |
3 | 字节 | 从设备ID标识符的长度(字节数) |
4 | 字节 | 从设备ID数据类型(可选字节,视实际应用而定) |
5 | 字节 | 资源可用状态字节 |
6 | 字节 | 资源保护状态字节 |
7 | 字节 | 无效 |
从设备收到该命令后,会自动将地址指针定义到存放ID标识符的起始地址,主设备随后就以该起始地址使用UPLOAD指令上传ID信息。
CCP协议在基本通信的基础上定义了一些其他功能,如非易失性内存烧写等。为了防止可能对ECU进行的误操作,在ECU程序实现时,可以对某些功能通过密钥进行保护。资源可用状态及资源保护状态两个字节反映了这些特殊功能当前是否处于保护状态,两字节的结构定义如下所示。
Bit | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 |
x | PGM | x | x | X | X | DAQ | CAL |
各位的说明:
CAL | 标定 |
DAQ | DAQ模式 |
PGM | 非易失性内存烧写 |
X | 保留的为将来用 |
资源可用状态字节,如果对应某位为“真”,则表明当前该项功能未受保护,可以启用;资源保护状态字节,如果对应某位为“真”,则表示该功能当前受密钥保护,需要授予权限才能进行访问。
例如,主设备向从设备发送EXCHANGE_ID命令,当前CTR为0x23,CRO状态,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0x17 | 0x23 | -- | -- | -- | -- | -- | -- |
从设备返回TDO,其中包括确认代码ERR(0x00)、CTR(0x23)、从设备ID号的长度及数据类型,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0xFF | 0x00 | 0x23 | 0x04 | 0x02 | 0x03 | 0x03 | -- |
由返回DTO可知,从设备ID号长度为4个字节,数据类型编号为2,资源可用状态字节为0x03,资源保护状态也是0x03。
-
- 2.申请密钥(GET_SEED)
通过前面介绍功能可能处于资源保护状态,如果某项功能处于保护状态,主设备需要发送GET_SEED命令向ECU申请解开该项功能的密钥。GET_SEED命令每次只能请求解开一项功能,如果需要请求解开多项资源功能,就需要多次重复使用GET_SEED和UNLOCK命令。
从设备通过DTO返回密钥数据,主设备由返回的密钥通过seed&key算法算出解开对应功能的密钥,使主设备有权限访问该项功能(UNLOCK命令)。GET_SEED命令的CRO数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | 命令代码=0x12(GET_SEED) |
1 | 字节 | 命令序号=CTR |
2 | 字节 | 请求从设备开放的功能 |
3~7 | 字节 | 无效 |
针对GET_SEED命令返回DTO的数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | Packet ID:0xFF |
1 | 字节 | 命令返回代码=ERR |
2 | 字节 | 命令序号=CTR |
3 | 字节 | 请求功能当前受保护状态(“真”或“假”) |
4~7 | 字节 | “密钥”数据 |
备注:如返回DTO中,请求功能当前受保护状态字节值为“假”,表示当前该项申请功能是可用的,不再需要UNLOCK命令来解开该功能。
例如,主设备向从设备发送GET_SEED命令,当前CTR为0x23,请求从装备开放DAQ通信模式,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0x12 | 0x23 | 0x02 | -- | -- | -- | -- | -- |
从设备返回TDO,其中包括确认代码ERR(0x00)、CTR(0x23)、请求功能当前受保护的状态及密钥数据,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0xFF | 0x00 | 0x23 | 0x01 | 0x14 | 0x15 | 0x16 | 0x17 |
由返回DTO可知,所请求的功能当前受保护状态值为“真”,需要通过UNLOCK命令来解开对该命令的保护。返回的密钥数据是0x14、0x15、0x16、0x17。
-
- 3.解除保护(UNLOCK)
通过GET_SEED命令得到的“密钥”数据,由seed&key算法计算而得到的“钥匙”,通过UNLOCK命令可解开从设备对某项功能的保护。UNLOCK命令的CRO数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | 命令代码=0x13(UNLOCK) |
1 | 字节 | 命令序号=CTR |
2~7 | 字节 | 钥匙 |
针对UNLOCK命令返回DTO的数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | Packet ID:0xFF |
1 | 字节 | 命令返回代码=ERR |
2 | 字节 | 命令序号=CTR |
3 | 字节 | 当前各功能的状态 |
4~7 | 字节 | 无效 |
例如,主设备向从设备发送UNLOCK命令,当前CTR为0x23,通过GET_SEED命令计算得到的钥匙为0x140x150x160x17,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0x13 | 0x23 | 0x14 | 0x15 | 0x16 | 0x17 | -- | -- |
从设备返回TDO,包括确认代码ERR(0x00)、CTR(0x23),如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0xFF | 0x00 | 0x23 | 0x02 | -- | -- | -- | -- |
由返回DTO可知,当前功能状态为0x02,表示仅仅DAQ通信是可用的。
-
- 4.设置MTA地址(SET_MTA)
MTA地址相当于一个地址指针。CCP在执行许多命令前,都要为后续的内存读取或擦写设定一个起始地址。SET_MTA命令就是用来设置一个初始地址(32位基地址+地址偏移),其后对内存的读取操作都会由该起始地址开始。地址偏移量取决于ECU本身的实现形式,可以指向内存中的一个页或其中某一块区域。
CCP协议定义了两个MTA地址:MTA0与MTA1,分别针对不同的命令。DNLOAD、UPLOAD、DNLOAD_6、SELECT_CAL_PAGE、CLEAR_MEMORY、PROGRAM及PROGRAM_6命令使用ATM0,MOVE命令使用MTA1,SET_MTA命令的CRO数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | 命令代码=0x03(DNLOAD) |
1 | 字节 | 命令序号=CTR |
2 | 字节 | MTA序号(0或1) |
3 | 字节 | 地址偏移 |
4~7 | 字节 | 地址 |
针对SET_MTA命令返回DTO的数据场结构,如下所示。
位 置 | 类 型 | 描 述 |
0 | 字节 | Packet ID:0xFF |
1 | 字节 | 命令返回代码=ERR |
2 | 字节 | 命令序号=CTR |
3~7 | 字节 | 无效 |
例如,主设备向从设备发送SET_MTA命令,当前CTR为0x23,MTA序号为0,地址偏移量为0x02,基地址为0x34002000,如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0x02 | 0x23 | 0x00 | 0x02 | 0x34 | 0x00 | 0x20 | 0x00 |
从设备返回TDO,包括确认代码ERR(0x00)、CTR(0x23),如下所示。
byte | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 |
0xFF | 0x00 | 0x23 | -- | -- | -- | -- | -- |