【CANdelaStudio-从入门到深入到实战】50 从“硬复位”到“软着陆”：0x34/0x36/0x37 窗口下载的流量控制艺术

老张上周差点被客户骂到自闭。他负责的ECU刷写工具在传输一个32MB的固件时，每传3MB就断连一次，反复重连了7次才勉强刷完。

客户指着日志里密密麻麻的“0x7F 36 78（RCRRP）”说：“你这工具是在跟ECU玩拔河比赛吗？”老张委屈——明明按照UDS规范实现了0x34（请求下载）、0x36（传输数据）、0x37（请求退出传输），怎么传输效率还不如串口助手手动发呢？

我看了他的代码，发现一个典型问题：他把0x36的数据块大小设成了固定的4096字节，而ECU的接收缓冲区只有2048字节。

每次发完数据，ECU都回复“等待（0x78）”，但工具端根本不等，直接发下一包——结果ECU缓冲区溢出，直接丢包，工具端收不到肯定回复就报超时重连。这不是协议问题，是流量控制没做好。

痛点拆解：你以为的“窗口机制”可能只是“窗口期”

很多工程师对0x34/0x36/0x37的理解停留在“三步走”表面：先协商大小，再分块传输，最后确认结束。

但实际刷写时，ECU的接收能力不是恒定的——它可能一边擦除Flash一边接收数据，也可能因为DMA通道被高优先级任务抢占而暂时“卡住”。

常见错误实现：

# 反例：固定块大小，忽视ECU的流控反馈defdownload_firmware