小猫爪：嵌入式小知识16-XCP协议简介

0 目录

1. 小猫爪：嵌入式小知识15-XCP基础简介
2. 小猫爪：嵌入式小知识16-XCP协议简介
3. 小猫爪：嵌入式小知识17-XCP on CAN简介
4. 小猫爪：嵌入式小知识18-XCP SeedNKey.dll

1 前言

  上一节介绍了一下XCP的相关基础，为我们后续学习打下了坚实的基础，接下来就开始进行枯燥乏味的协议介绍。参考资料：XCP协议规范2003。

2 XCP协议简介

2.1 各种包

  在XCP基础简介文章中，提到了XCP协议包分为CTO和DTO，然后又细分为CMD, RES, ERR, EV, SERV, DAQ, STIM，在上篇文章中已经对XCP协议包的格式进行了简单说明，XCP依靠PID来进行区分协议包类型，具体PID划分如下：

接下来来看看每一种包的形式和作用。

注：下面的表中出现的MAX_CTO和MAX_DTO，分别表示CTO包和DTO包的最大数据字节长度。

2.1 CMD

  CMD就是XCP的各种命令，PID的范围是0xC0~0xFF，具体的相关命令有：

1. Standard commands (STD)
   

2. Calibration commands (CAL)
   .

3. Page switching commands (PAG)
   

4. Data Acquisition and Stimulation commands (DAQ)
   

5. Non-volatile memory programming commands (PGM)
   
     每一种命令的作用这里就不一一细说了，具体请参考XCP标准协议的Part2，《ASAM_XCP_Part2_Protocol-Layer-Specification_V1.0》。

2.2 RES

  RES是CMD的正响应，PID固定为0xFF，具体RES的响应内容根据CMD而变化，具体请参考XCP标准协议的Part2，《ASAM_XCP_Part2_Protocol-Layer-Specification_V1.0》。

2.3 ERR

  ERR是CMD的负响应，PID固定为0xFE，Error Code如下所示：

2.4 EV

  EV就是从节点在连接之后，向主节点发送一些异步事件通知，PID固定为0xFD，Event Code如下：

2.5 SERV

  SERV就是从节点在连接之后，向主节点发送一些服务请求，PID固定为0xFC，Service Request Code如下：

2.6 DAQ

  DAQ就是从节点给主节点传输数据包，其中PID范围为0x00~0xFB，在上一节中提到过，DAQ的PID包含了绝对或相对ODT编号。

2.7 STIM

  DAQ就是主节点给从节点传输数据包，其中PID范围为0x00~0xBF，在上一节中提到过，STIM的PID包含了绝对或相对ODT编号。

2.8 总结

  所有的PID看下来后，这里就可以总结一下XCP标定的原理过程了。一般在主节点发起连接CMD并且连接成功后，主节点就可以发送各种花里胡哨的命令进行花里胡哨的操作，配置ODT，配置DAQ_list，如果激活了DAQ_list（这里需要强调一点的就是，同一时刻只能激活一个DAQ_list），那么从节点就会愉快的给你定期发送DAQ进行数据测量，当然主节点也可以周期发送读取数据CMD读取数据进行数据测量，然后还可以发送标定命令修改被标定数据值，慢慢的校准慢慢的标定直到被测量数据值满足期望值，然后马上保存被标定数据值，随后根据需求整理打包成各种PAR数据，然后再用XCP的PGM类命令将PAR下载到ECU目标FLASH区域中完成最终标定。

2.2 错误处理

  再来看看XCP的错误处理方式。首先来看看在错误处理上的一些小点。

1. Error
     在XCP中定义的错误有两种，第一种就是主节点错误的发送相关命令，从节点发送负响应，这种错误被称为Error Code Error；还有一种就是在主节点发送命令后，从节点未在规定时间内给予正负响应，这种错误被称为Time-out Error。

2. Pre-action和Action
     当发生错误时，主节点就不能再发送各种花里胡哨的操作了，这个时候主节点只能进行一些特别的操作，这些特别的操作叫做 Pre-action，具体有：
   
     当 Pre-action做完，发现没问题后，这个时候主节点就可以再做另外一些特殊的操作，这些特别的操作叫做Action，具体有：
   

3. Error Severity
     在上面介绍各种包的时候，发现ERR和EV这两种包比别的包多了一个属性severity，它的值范围是S0~S3，这个玩意其实是XCP给ERR和EV的严重程度排了级，如下：
   
     这个东西有啥用呢，就是为了告诉主节点，糟糕糟糕OMG，魔法怎么失灵啦，别折腾了，这个玩意你搞不定的，快快死心吧。

  介绍完错误处理相关的点后，就来说说XCP的错误处理流程吧！！！XCP的错误处理的核心其实核心就是“再来一次”，多试两次就成功啦。

2.2.1 Time-out Error Handling

  关于Time-out Error的处理呢，就是使用上面的Pre-action和Action，多试几次就好啦，如果好不了的话，主节点可以采取一些必要手段，比如重启从节点。在标准通信模式下的流程如下：

  从图中可以看出，首先Master发送了一个Request K, Slave正常回复Response K，然后Master发送了一个Request K+1，结果Slave的回复突然超时了，这个时候Master检测到Time-out Error后首先进行了一个Pre-action操作，就是发送了一个SYNCH命令，随后就再次尝试发送Request K，这个时候，哎，Slave又回复正常了，问题成功消失。

  在块传输模式和交互模式下的处理流程也差不多，这里就不做介绍了，感兴趣的可以去参考XCP标准协议的Part2，《ASAM_XCP_Part2_Protocol-Layer-Specification_V1.0》。

2.2.2 Error Code Error Handling

  对于Error Code Error 的处理，那更是把“再来一次”的核心体现的淋漓尽致，这里就不多介绍了，XCP协议规范里面列举了在不同的CMD下回复的不同的Error Code它所建议的操作，这里拿一小部分示例看一下：

  太随意了，真的太随意了，这里就不做介绍了，感兴趣的可以去参考XCP标准协议的Part2，《ASAM_XCP_Part2_Protocol-Layer-Specification_V1.0》。

  好了，关于XCP的协议介绍，就到这里，祝大家码运滚滚。

2.3 State machine

  XCP协议栈在Slave中运行时，有个简单的状态机，如下图所示：

1. START: 当ECU上电时，检测RESUME模式是否激活，如果激活则跳转到RESUME模式自动进去DTO数据传输，如果没有激活，则进如DISCONNECT状态。
2. RESUME: 在RESUME模式中，如果Master发送CONNECT命令，则会进入CONNECT状态。
3. DISCONNECT：在DISCONNECT状态下，如果Master发送CONNECT命令，则会进入CONNECT状态。
4. CONNECT：在CONNECT状态下，如果Master发送DISCONNECT命令，或者发生S3级别的错误，则会进入DISCONNECT状态。

  本小节结束，下期再见，祝大家BUG多多。

END