今天我们为大家带来的分享内容是关于CCP协议栈的移植以及基于CANape标定的相关知识。图1为基于CCP协议的标定系统简易实现图，其中红框部分为CCP协议栈。
图1 简易标定系统实现
CCP（CAN Calibration Protocol）协议是ASAP 标准的组成部分，CCP协议为标定系统的开发提供了一个标准的通信平台。在欧美已被大部分主流OEM和Tier1&Tier2广泛接受并成为标准。应用CCP协议的标定工具可以在控制器运行过程中实现对控制器中数据及特性参数的动态标定。
如果要实现基于CCP协议的标定功能，需要在ECU 内部实现支持CCP协议的驱动程序（CCP driver）。目前大多数应用都采用Vector 提供的free CCP driver。考虑到ECU底层程序与CAN 驱动程序的实现各不相同，将CCP驱动程序结合到ECU中并不是一件一蹴而就的事, 这需要对CCP 协议本身、标定工具及标定工具与ECU之间的通信有深入的了解。由于篇幅有限，下面简单介绍下CCP协议的基础知识。
基于CCP协议的标定只占用CAN报文的两个ID标识符，需要两个消息对象，即CRO（Command Receive Object）和DTO（Data Transmission Object），如图2所示。CRO用于主设备向从设备发送命令（共28条命令）, DTO则用于从设备向主设备发送数据，CRO和DTO的ID标识符自行约定。
图2 基于CCP协议的主从设备之间的通信流
DTO 分三种类型:
1）CRM（Command Return Message）： 见图3，是由从设备发送, 反馈CRO命令的报文。
2）Event Message: 见图3，当从设备检测到内部发生错误机制时, 由从设备自行向主设备发送, 报告其当前的运行状态, 并请求主设备暂停当前工作进程以处理发生的错误。
图3 DTO – CRM&Event Message
3）DAQ（Data Acquisition）：见图4，DAQ类型DTO用于DAQ模式，由从设备定期向主设备发送。
图4 DTO – DAQ
以上为CCP协议的一些基础知识，其他涉及到协议命令内容和功能控制等知识，建议部分入门读者阅读CCP协议相关技术文档。
CCP协议栈移植准备
首先需要一份协议栈代码，本文采用Vector 提供的free CCP driver，该协议栈代码可以在Vector官网申请免费下载。
从Vector官网下载下来的是一个ccp.exe的程序，运行程序会释放出free CCP driver协议栈文件，见图5，需要移植的三个文件为CCP.C、CCP.H和CCPPAR.H。CCP.C和CCP.H的内容为协议栈执行函数，一般不需要修改。需要修改的为CCPPAR.H，CCPPAR.H中设计了大量的宏定义开关和类型重定义，这些开关可以开启或关闭CCP协议栈提供的一些功能。
图5 free CCP driver协议栈文件
协议栈文件需要移植到MCU（Microcontroler）中，车用MCU一般是使用Freescale（已被NXP并购）的芯片，协议栈移植需要软硬件平台支持。本文介绍的CCP协议栈移植使用的软硬件平台如下表：
| 硬件平台 | 软件平台 | ||
| MCU调试编译器 | 标定测量工具 （MCS） |
||
| 型号/版本 | MC9S12XEP100 | CodeWarrior v5.9.0 | CANape16.0 SP3 |
| 概述 | MC9S12XEP100是Freescale设计的HCS12(X)系列MCU，芯片集成了5路的MSCAN控制器，在汽车ECU应用领域使用很广泛 | CodeWarrior包括构建平台和应用所必需的所有主要工具 - 编译器、调试器、编辑器、链接器、汇编程序等 |
CANape是Vector开发的一款可用于标定、测量、诊断和刷写的工具，其具备交互友好的UI界面和专业的功能设计 |
CCP协议栈移植方法
首先在Main函数中设计CCP通信的执行框架，见图6：
图6 执行框架
因为ccpSendCallBack()函数执行的时候需要禁止中断对其进行保护，所以要注意在CCPPAR.H文件中将MCU的全局中断控制操作指令重定义到CCP_DISABLE_INTERRUPT和CCP_ENABLE_INTERRUPT上。
其次，在CCPPAR.H中设置CRO和DTO的ID。设置byte存储模式为Motorola模式。基本的执行框架和配置建立好之后，后续的移植过程将从Connect、Checksum、Seedkey、DAQ和刷写五大功能展开。
1. Connect
实现基本的连接功能是后续功能移植的基础，需要封装基本的CAN收发函数，接收函数封装为ccpBootReceiveCro（rec_buffer），发送函数封装为ccpBootTransmitCrm（send_buffer），发送函数需要被协议栈调用。
如图7为ECU内部的一些基本交互函数，需要自定义的基本接口函数为：
Ø void ccpSend（BYTEPTR msg ）；
图7 ECU内部基本交互
ccpSend（BYTEPTR msg）函数是被协议栈内部直接调用的，而ccpSend（BYTEPTR msg ）在执行的时候需要调用CAN发送的底层函数，所以要将封装好的CAN发送程序接入到ccpSend（BYTEPTR msg ）函数中。其调用关系见图8：
图8 ccpSend调用关系
以上即可完成基本的Connect功能，见图9。Connect功能的完成也证明指令收发链路都已经打通。
图9 Connect
Connect指令交互可以在CANape的Trace窗口看到，见图10。
图10 Connect报文交互
2. Checksum
Checksum功能是用于CANape启用Cache的情况下执行Cache与ECU内部数据CRC校验的情况。协议栈提供的校验算法在ccpBackground()中执行，如果需要自定义校验算法可以在ccpUserBackground()中设计。
启用协议栈提供的Checksum功能需要在CCPPAR.H中将以下宏定义进行配置：
#define CCP_CHECKSUM
#define CCP_CHECKSUM_TYPE CCP_WORD //校验位为16位
以上简单配置就可以启用协议栈提供的基本Checksum功能。
3. Seedkey
Seedkey功能用于对协议栈通信过程中访问权限的加密。Seedkey算法的逻辑可以通过图11示意进行理解。
图11 Seedkey加密算法
访问权限分为三块，分别为标定权限、DAQ权限和Program权限。
Seedkey算法设计需要在ECU端进行算法集成，在CANape工程中添加dll文件的支持。
ECU端启用Seedkey功能需要在CCPPAR.H文件中开启Seedkey功能的宏定义开关。
#define CCP_SEED_KEY
4. DAQ
DAQ功能用于ECU周期性的主动上报变量值，启用了DAQ功能后，CANape在测量DAQ变量的时候就不需要进行重复的Polling了，ECU会定期的将这些数据上发到CANape，这样可以极大的降低总线负载。
在ECU端，要进行周期定时器的设计，周期定时器内调用ccpDAQ(eventChannel)，该函数将分配到对应Channel的DAQ变量发送给CANape。
ECU端需要在CCPPAR.H文件中开启DAQ功能并配置ODT和DAQlist的Size。
#define CCP_DAQ
#define CCP_MAX_ODT 3
#define CCP_MAX_DAQ 2
ECU端配置好之后CANape对需要启用DAQ功能的变量进行组织（如图12）并告知给ECU，ECU将这些变量使用DAQ - DTO帧周期性的发送给CANape。
图12 CANape配置DAQ变量
5. 刷写
CANape 提供了两种对于FLASH变量的标定方式，分别为Flash kernel法和调用FLASH擦写函数法。使用Flash kernel法时, CANape将Flash kernel下载到RAM中运行, 将标定后的FLASH.hex写入FLASH中。这种方法不占用FLASH空间, 但占用较大的RAM空间，且只能针对几种有限的硬件环境。部分版本的CANape中没有提供MC9S12XEP100单片机的Flash kernel, 因此，在这种情况下，需要采用调用FLASH擦写函数法。首先，先自行编写一套针对相应硬件环境的FLASH 擦写驱动, 并在CCP命令处理模块中的子函数中调用该擦写函数。基本的擦写流程见图13。
图13 CANape擦写Flash流程图
在执行刷写操作过程中，CCP协议栈提供了相应的程序接口，分别为ccpFlashClear()和ccpFlashProgramm()函数。这两个函数是刷写指令与Flash擦写函数的引导接口。调用关系见图14。
图14 函数调用关系
嵌入擦写函数以后，CCP调用SET_MTA、CLEAR_MEMORY、PROGRAM6和PROGRAM命令即可完成擦写过程。
针对D-FLASH存储器的擦写单位是Sector , 在MC9S12XEP100中D-Flash的每个Sector包含256Bytes，故标定的数据需要单独占据一页或几页以方便CANape对其进行擦写。而在做刷写操作的时候也要按照Sector单位进行擦除和写入。Hex数据流向见图15。
图15 Hex数据流向图
CANape端要进行Memory Flash的配置，系统会根据刷写Sector的范围执行刷写操作。执行刷写的报文交互可以在 CANape的Trace窗口看到见图16。
图16 刷写-Trace窗口报文交互
总结：
CCP协议目前的版本为1999年ASAP发布的V2.1，作为一种仅支持CAN总线的应用层协议，逐渐显露出了其局限性。随着汽车电子的发展，LIN/FlexRay/MOST/Enthernet等通信总线开始应用在ECU和整车上，所以一种可以基于多种总线上使用的协议 – XCP协议开始被提出，在2003年，XCP在CCP的基础上被ASAM组织 以“ASAM MCD-1 XCP”的名字标准化。XCP的全称是Universal Measurement and Calibration Protocol，这里“X”代表的意思就是这个协议可以运行在多种通信总线上（CAN，Ethernet，FlexRay，SCI，SPI，USB）。
以上为本次分享内容，后续我们将继续为大家介绍XCP协议栈的移植，请继续关注我们。
相关精彩推荐：
怿星一意，专注车载
引领汽车科技新高度
