30 0x34请求下载与0x36数据传输：UDS刷写的“流水线”核心开篇故事：一次刷写失败引发的“血案”上个月，我帮一家Tier1排查ECU刷写失败问题。客户反馈：用CANape刷写固件时，每次到50%左右就超时断开，但用原厂诊断仪却能成功。我让他们抓取UDS日志，发现一个诡异现象——刷写过程中，0x36数据传输的BlockSize（块大小）竟然从0x40（64字节）突然跳到了0x100（256字节），导致ECU接收缓冲区溢出，直接返回NRC 0x31（请求超出范围）。“我们明明严格按照UDS规范写的代码，为什么BlockSize会变？”对方工程师一脸困惑。我指着日志说：“你看0x34请求下载时，你填的BlockSize是0x40，但0x36开始传输后，工具端却用0x100的块来发数据——这是典型的‘协议握手失败’问题。”这个案例让我意识到：很多人以为0x34和0x36就是简单的“告诉ECU我要下载”和“开始发数据”，却忽略了它们之间精密的“流水线”协作机制。今天，我们就来拆解这对“黄金搭档”的底层逻辑。痛点拆解：三个致命误区误区1：0x34的BlockSize是“建议值”，ECU可以随意改错误认知：很多开发者以为0x34响应里的BlockSize只是给工具端的一个参考，工具可以忽略它。反例代码：