【CANdelaStudio-从入门到深入到实战】07 诊断请求的“生命周期”——从PCI解析到响应发送的完整流水线

开篇故事：一个让ECU“死机”的凌晨三点去年冬天，我接到一个紧急电话——某OEM的ADAS控制器在整车路试时，每隔20分钟就会“死机”一次。售后团队查了三天，发现死机总发生在诊断仪发送22 F1 90（读取VIN码）之后。更诡异的是：死机前，诊断仪明明收到了正确的响应，但ECU却再也不能处理任何后续请求。我连夜翻看CAN日志，发现了一个细节：每次死机前，诊断仪都会在极短时间内连续发送两个22 F1 90请求，间隔仅8ms。而我们的UDS栈在处理第一个请求时，还在慢悠悠地读取NVM中的VIN码（耗时约15ms），第二个请求的PCI（协议控制信息）就已经到了。ECU的接收缓冲区只有1个帧的深度。当第二个请求覆盖了第一个请求的部分数据时，我们的代码直接访问了未初始化的内存——然后，就是经典的“跑飞”死机。这个场景，就是我今天要带你拆解的核心问题：一个诊断请求从CAN帧到达，到应用层处理完成并响应发送，中间到底经历了哪些环节？每个环节的“坑”在哪里？痛点拆解：你以为的“收到请求”其实是个幻觉很多刚入行的工程师认为“收到诊断请求”就是中断里把CAN帧读出来，然后调用应用层函数。但真相是：CAN帧的接收和UDS请求的完整解析，中间隔着一道“PCI解析”的鸿沟。常见错误实现（反例代码）