小猫爪：嵌入式小知识16-XCP协议简介
小猫爪：嵌入式小知识16-XCP协议简介
- 0 目录
- 1 前言
- 2 XCP协议简介
-
- 2.1 各种包
-
- 2.1 CMD
- 2.2 RES
- 2.3 ERR
- 2.4 EV
- 2.5 SERV
- 2.6 DAQ
- 2.7 STIM
- 2.8 总结
- 2.2 错误处理
-
- 2.2.1 Time-out Error Handling
- 2.2.2 Error Code Error Handling
- 2.3 State machine
- END
0 目录
- 小猫爪：嵌入式小知识15-XCP基础简介
- 小猫爪：嵌入式小知识16-XCP协议简介
- 小猫爪：嵌入式小知识17-XCP on CAN简介
- 小猫爪：嵌入式小知识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，具体的相关命令有：
-
Standard commands (STD)
-
Calibration commands (CAL)
.
-
Page switching commands (PAG)
-
Data Acquisition and Stimulation commands (DAQ)
-
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的错误处理方式。首先来看看在错误处理上的一些小点。
-
Error
在XCP中定义的错误有两种，第一种就是主节点错误的发送相关命令，从节点发送负响应，这种错误被称为Error Code Error；还有一种就是在主节点发送命令后，从节点未在规定时间内给予正负响应，这种错误被称为Time-out Error。 -
Pre-action和Action
当发生错误时，主节点就不能再发送各种花里胡哨的操作了，这个时候主节点只能进行一些特别的操作，这些特别的操作叫做 Pre-action，具体有：
当 Pre-action做完，发现没问题后，这个时候主节点就可以再做另外一些特殊的操作，这些特别的操作叫做Action，具体有：
-
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中运行时，有个简单的状态机，如下图所示：
- START: 当ECU上电时，检测RESUME模式是否激活，如果激活则跳转到RESUME模式自动进去DTO数据传输，如果没有激活，则进如DISCONNECT状态。
- RESUME: 在RESUME模式中，如果Master发送CONNECT命令，则会进入CONNECT状态。
- DISCONNECT：在DISCONNECT状态下，如果Master发送CONNECT命令，则会进入CONNECT状态。
- CONNECT：在CONNECT状态下，如果Master发送DISCONNECT命令，或者发生S3级别的错误，则会进入DISCONNECT状态。
本小节结束，下期再见，祝大家BUG多多。