IAP协议中数据包丢失如何处理？

Question

在IAP（In-Application Programming）协议的固件升级过程中，若因通信不稳定导致数据包丢失，如何确保升级的完整性和可靠性？常见的问题是：IAP协议本身通常不包含自动重传机制，当接收端未能正确接收某一数据包时，系统缺乏有效的确认与重传策略，可能导致固件镜像损坏。例如，在串口或CAN总线上传输时，若校验失败或ACK响应超时，当前帧数据被丢弃后应如何处理？是否需由主机端主动重发，还是从机应请求重传？如何设计合理的超时重传、序列号标记与校验机制，以实现可靠升级？

Answer 1

一、IAP固件升级中通信不稳定问题的挑战与应对策略

在嵌入式系统开发中，In-Application Programming（IAP）技术被广泛用于现场固件更新。然而，在实际部署中，由于串口、CAN总线等物理层通信存在噪声、干扰或网络延迟，数据包丢失成为常见问题。IAP协议本身通常不包含完善的错误恢复机制，导致固件镜像完整性难以保障。

1. 常见问题分析：IAP协议为何缺乏可靠性保障？

• IAP协议设计初衷是轻量级，适用于资源受限设备，因此常省略复杂的重传与确认机制。
• 标准IAP流程仅依赖单向传输和简单ACK响应，一旦校验失败或响应超时，无法定位错误帧。
• 主机端往往假设从机已正确接收数据，缺乏主动探测机制。
• 在CAN或UART上传输时，电磁干扰可能导致位翻转，CRC校验虽可检测但无修复能力。
• 若未使用序列号标记，重复包或乱序包可能被误处理，造成Flash写入异常。

2. 核心机制设计：构建可靠的IAP通信框架

为解决上述问题，需引入以下三大核心机制：

机制	作用	实现方式
序列号标记	识别数据包顺序与重复	每帧携带递增SeqNum（如uint8_t）
校验机制	确保数据完整性	CRC16/32 + 数据长度校验
确认与重传	处理丢包与超时	NACK反馈 + 主机定时重发
超时控制	避免死锁	固定RTT基础上增加抖动容限
状态同步	支持断点续传	保存已接收块索引至非易失存储

3. 通信流程设计：基于NACK的请求重传模型

推荐采用“从机驱动”的重传策略：当从机发现校验失败、序列号不连续或ACK未送达时，主动发送NACK请求重传。该模式相比主机盲目重试更高效。

// 示例：从机返回NACK帧结构
typedef struct {
    uint8_t cmd;      // 指令码: NACK = 0x1F
    uint8_t seq_num;  // 请求重传的序列号
    uint8_t reason;   // 错误类型: 0=校验失败, 1=超时, 2=非法命令
} nack_packet_t;
    

4. 超时与重传算法实现

设定合理的超时窗口至关重要。建议采用指数退避算法防止网络拥塞：

1. 初始超时时间设为T_base（如500ms）
2. 每次重传后超时时间乘以退避因子（如1.5）
3. 最大重试次数限制为5~7次
4. 成功接收后重置超时计数器
5. 结合RTT估算动态调整T_base
6. 使用硬件定时器中断管理超时事件
7. 在RTOS环境下可用消息队列解耦收发逻辑

5. Mermaid流程图：可靠IAP升级交互过程

sequenceDiagram
    participant Host
    participant Slave

    Host->>Slave: 发送数据帧(Seq=1, CRC)
    Slave-->>Host: ACK(Seq=1)
    
    Host->>Slave: 发送数据帧(Seq=2)
    Note right of Slave: 校验失败
    
    Slave-->>Host: NACK(Seq=2, reason=0)
    
    Host->>Slave: 重传数据帧(Seq=2, CRC)
    Slave-->>Host: ACK(Seq=2)

    Host->>Slave: 发送数据帧(Seq=3)
    Slave-->>Host: ACK(Seq=3)
    

6. 断点续传与完整性验证

即使部分数据已损坏，系统仍可通过以下方式恢复：

• 将接收到的数据暂存于RAM或双Bank Flash缓冲区
• 每完成一个数据块（如1KB），记录其MD5哈希值
• 升级完成后执行整体镜像签名验证（如RSA-2048）
• 利用Bootloader中的安全验证模块阻止非法固件运行
• 支持通过外部EEPROM保存当前进度状态