1. 从串口升级说起：为什么是YModem？

搞嵌入式开发的朋友，对“固件升级”这个事儿肯定不陌生。无论是产品出厂后的功能迭代，还是现场修复一个紧急的Bug，都离不开它。早期很多设备，特别是那些资源紧张、没有网络功能的单片机，最常用、最经济的升级方式就是通过串口。我刚开始做项目那会儿，用的就是最原始的“串口打印+手动拷贝”土办法，效率低不说，还容易出错，传着传着数据就乱了，得从头再来，非常折腾。

后来接触到了XModem、YModem这些串口文件传输协议，才算真正找到了“组织”。它们就像是给串口通信这个原始的“乡间土路”铺上了铁轨，规定了火车（数据包）怎么发、怎么收、跑错了怎么办，让传输变得可靠有序。在众多协议里，YModem 是我在嵌入式IAP（In-Application Programming，在应用中编程）场景下用得最多，也最推荐的一个。为什么不是XModem呢？简单说，XModem每包只能传128字节，对于现在动辄几十、几百KB的固件来说，包数量太多，握手、确认太频繁，整体效率就低了。而YModem一包能传1024字节，相当于一次拉八倍的货，效率提升非常明显。

更重要的是，YModem协议本身设计得比较“聪明”和完整。它不光传数据，还能在传输一开始就把文件名、文件大小这些信息带过去，接收方可以提前知道要收的是个啥、有多大，方便做存储空间检查和版本管理。它的错误校验用的是CRC-16，比简单的累加和校验靠谱得多，能有效发现传输过程中的比特错误。整个通信过程有严格的状态机控制，从握手、传数据到结束，每一步都有确认，保证了传输的稳定性。这些特性，让它特别适合作为嵌入式设备IAP升级的“运输队长”。下面，我们就把它拆开揉碎了，看看这个协议到底是怎么工作的，以及怎么把它高效地用起来。

2. 庖丁解牛：YModem协议传输流程全解析

理解协议最好的方式，就是跟着数据流走一遍。咱们把通信的双方叫做 发送方（Sender）（比如你的PC上位机）和 接收方（Receiver）（比如你的STM32单片机）。假设我们要发送一个叫 app_v1.2.bin 的固件文件。

2.1 握手阶段：打个招呼，确认眼神

整个传输始于接收方的一个主动呼叫。当你的设备进入IAP升级模式，准备好接收新固件后，它会持续向串口发送一个ASCII字符 ‘C’（十六进制0x43）。这个‘C’有两个含义：一是告诉发送方“我准备好了，可以用CRC校验模式”；二是在持续“呼叫”发送方，直到得到回应。

发送方（比如串口工具）收到这个‘C’之后，就知道接收方在线且就绪，于是发出第一帧数据，我们称之为头帧（Header Frame）。这一帧不包含真正的固件数据，而是文件的“元信息”。

头帧的结构是这样的，我们一个字节一个字节看：

[SOH][00][FF][文件名+文件大小+NULL填充][CRC高8位][CRC低8位]

• 第1字节 SOH (0x01)： 这是一个标识符，意思是本帧的数据区长度是128字节。如果是后面传输实际数据的数据帧，可能会用到 STX (0x02)，它代表数据区长度是1024字节。你看，协议一开始就区分了不同类型的帧。
• 第2字节 块编号 (0x00)： 这是数据块的编号，头帧固定是0。从第一包真实数据开始，编号会从1开始递增（0x01, 0x02…），到255（0xFF）后再回绕到0。这个编号用于确保数据包的顺序。
• 第3字节 块编号的反码 (0xFF)： 这是第2字节的反码，0x00的反码就是0xFF。这是一个简单的即时验证机制，接收方收到后可以马上算一下“编号 + 反码”是否等于0xFF，快速判断帧头是否在传输中出错了。
• 第4字节开始的128字节数据区： 这里存放的是文件名和可选的文件大小。格式通常是像 app_v1.2.bin 这样的字符串，后面跟一个结束符（NULL, 0x00）。在一些实现里，文件名后面还会跟一个空格，然后是以字符串形式表示的文件大小（比如“ 131072”表示128KB）。无论实际内容多长，这个数据区都必须用0x00填充到整整128字节。
• 最后2字节 CRC16校验值： 这是对整个128字节数据区计算出来的CRC-16校验码，高位在前，低位在后。注意，校验范围只包括数据区，前面的SOH、块编号和反码不参与CRC计算。这保证了数据内容的完整性。

接收方收到这包头帧后，会做几件事：1. 检查块编号和反码的逻辑；2. 计算数据区的CRC，与接收到的CRC比对；3. 解析出文件名和文件大小。如果一切正确，它会回复一个 ACK (0x06)，表示“头帧收到，没问题”。紧接着，它会再次发送一个字符‘C’，这个‘C’是邀请发送方开始传送真正的文件数据了。

2.2 数据传送阶段：高效搬运的流水线

握手成功，流水线就正式开动了。发送方收到第二个‘C’后，开始发送第一包真正的固件数据。

第一包数据帧结构如下：

[STX][01][FE][1024字节数据][CRC高][CRC低]

• 标识符变成了 STX，代表这帧有1024字节的数据区。
• 块编号变为 0x01（注意，不是0x00了），其反码为 0xFE。
• 接着是1024字节的固件数据。如果文件最后剩余数据不足1024字节，依然用0x00补满。
• 最后是这1024字节数据的CRC16校验值。

接收方收到后，校验通过则回复 ACK。发送方收到ACK，就发送下一包（块编号0x02，反码0xFD）。如此循环，直到所有数据发送完毕。

这里有个关键点：YModem是“停-等”协议。发送方发完一包，必须等到接收方的ACK确认，才会发下一包。如果接收方校验失败，它会回复 NAK (0x15)，发送方则需要重发刚才那一包。如果连续多次失败，协议可能会中止。这种机制虽然不如连续ARQ高效，但在简单的点对点串口通信中，实现简单可靠，完全够用。

2.3 结束阶段：优雅地说再见

当所有固件数据包都发送并得到ACK确认后，发送方需要通知接收方：“我的货全发完了”。这个过程有个“二次确认”的机制，很严谨。

1. 发送方首先发送一个 EOT (0x04) 字符，意思是“传输结束”。
2. 接收方第一次收到EOT时，并不直接相信，它会回复一个 NAK。这个NAK不是表示出错，而是一个“请再确认一次”的请求，防止EOT字符在传输中误产生。
3. 发送方收到这个NAK后，第二次发送EOT。
4. 接收方第二次收到EOT，这才确信传输真的结束了。它会回复一个 ACK，紧接着再发一个‘C’字符。这个‘C’是邀请发送方发送“传输结束帧”。
5. 发送方收到ACK和‘C’后，发出最后一帧——结束帧。其格式与头帧类似： [SOH][00][FF][128字节的0x00][CRC高][CRC低] 数据区全是0，表示没有后续文件了（YModem支持批量传多个文件，单个文件时以此表示结束）。
6. 接收方收到结束帧并校验通过后，回复最终的 ACK。至此，整个YModem文件传输会话圆满结束。接收方的IAP程序在验证整个固件文件的完整性（比如再计算一次全局CRC或哈希）后，就可以跳转到新固件开始运行了。

整个流程听起来步骤不少，但用代码实现后就是一个稳定的状态机。我画过很多次这个过程的时序图，每次调试都离不开它。下面这个表格帮你快速回顾核心步骤：

步骤	发送方动作	接收方动作	说明
1	-	持续发送 ‘C’ (0x43)	接收方启动，呼叫发送方
2	发送 头帧 (SOH, 文件名/大小)	接收并校验头帧	协商文件名，使用CRC校验
3	-	回复 ACK， 再发 ‘C’	头帧OK，请求开始数据
4	发送 数据帧 (STX, 数据包1)	接收并校验数据包1	开始传输真实数据，包编号从1开始
5	-	校验成功，回复 ACK	确认包1，等待下一包
6	... (循环步骤4-5) ...	...	传输所有完整数据包
7	发送 EOT (第一次)	回复 NAK	首次传输结束通知，接收方要求二次确认
8	发送 EOT (第二次)	回复 ACK， 再发 ‘C’	确认传输结束，请求结束帧
9	发送 结束帧 (SOH，全0数据)	接收并校验结束帧	正式结束文件传输
10	-	回复 ACK	会话完全结束

3. 动手实现：嵌入式端的YModem接收器代码剖析

协议懂了，关键还是得写代码实现。在嵌入式设备端，我们需要实现一个YModem接收器。这个程序通常跑在芯片内部的Bootloader（IAP程序）里。这里我用一个基于STM32的伪代码示例，来讲解核心逻辑。请注意，这不是完整的可编译代码，但关键思路和代码片段是直接可以用的。

3.1 状态机设计：程序的心脏

实现YModem接收，最清晰的方式就是用一个状态机（State Machine）。它会根据当前状态和收到的字节，决定下一步做什么。我常用的状态定义大概是这样：

typedef enum {
    YM_STATE_IDLE,          // 空闲，等待‘C’
    YM_STATE_RECEIVE_HEADER,// 正在接收头帧
    YM_STATE_RECEIVE_FILE,  // 正在接收文件数据帧
    YM_STATE_WAIT_EOT,      // 等待/处理EOT结束信号
    YM_STATE_COMPLETE,      // 传输完成
    YM_STATE_ERROR          // 传输错误
} ymodem_state_t;

static ymodem_state_t current_state = YM_STATE_IDLE;
static uint8_t packet_num = 0;      // 当前期望收到的包编号
static uint32_t file_size = 0;      // 从头帧解析出的文件大小
static uint32_t bytes_received = 0; // 已接收数据字节数
static FILE* fp = NULL;             // 文件写入指针（假设有文件系统）

主循环或者串口中断服务程序里，就根据 current_state 来驱动整个流程。

3.2 核心函数：处理一个接收到的字节

假设我们在串口中断里每收到一个字节，就调用一个处理函数 ymodem_receive_byte(uint8_t data)。这个函数是状态机的引擎。

void ymodem_receive_byte(uint8_t data) {
    static uint8_t buffer[1024 + 6]; // 缓存一帧数据（含帧头、编号、数据、CRC）
    static uint16_t index = 0;
    static uint8_t filename[128];

    switch(current_state) {
        case YM_STATE_IDLE:
            if(data == 'C') { // 收到起始‘C’
                // 1. 清空缓冲区，准备接收头帧
                index = 0;
                // 2. 发送一个‘C’回应，有些实现需要，这里根据协议我们已收到‘C’，直接切换状态等待头帧
                // uart_send_byte('C');
                current_state = YM_STATE_RECEIVE_HEADER;
            }
            break;

        case YM_STATE_RECEIVE_HEADER:
            buffer[index++] = data;
            // 判断是否收够了一个完整的头帧（SOH帧：1+1+1+128+2=133字节）
            if(index >= 133) {
                if(validate_header_packet(buffer, filename, &file_size)) {
                    // 头帧有效！
                    // 可以在这里检查文件大小是否超过可用Flash空间
                    uart_send_byte(ACK); // 回复ACK
                    uart_send_byte('C'); // 发送‘C’请求第一包数据
                    packet_num = 1;      // 期望的第一包数据编号是1
                    bytes_received = 0;
                    current_state = YM_STATE_RECEIVE_FILE;
                    // 打开文件准备写入（如果是写入Flash，则是准备擦除对应扇区）
                    // fp = fopen((char*)filename, "wb");
                } else {
                    uart_send_byte(NAK); // 头帧校验失败
                    current_state = YM_STATE_IDLE; // 回到空闲，等待重发‘C’
                }
                index = 0; // 清空缓冲区
            }
            break;

        case YM_STATE_RECEIVE_FILE:
            buffer[index++] = data;
            // 判断帧类型：可能是1024字节的STX帧，也可能是最后不足1024的SOH帧
            if(index == 1) { // 收到第一个字节，判断帧类型
                if(buffer[0] == STX) {
                    // 期待接收 1+1+1024+2 = 1028 更多字节
                } else if(buffer[0] == SOH) {
                    // 最后一包短帧，期待接收 1+1+128+2 = 132 更多字节
                } else if(buffer[0] == EOT) {
                    // 收到结束信号，转入EOT处理状态
                    handle_eot();
                    index = 0;
                    break;
                } else {
                    // 非法帧头，报错
                    enter_error_state();
                }
            }
            // 根据帧类型，判断是否收够一帧完整数据
            if( (buffer[0]==STX && index>=1028) || (buffer[0]==SOH && index>=132) ) {
                if(validate_data_packet(buffer, packet_num)) {
                    // 数据包校验成功
                    uint16_t data_len = (buffer[0] == STX) ? 1024 : 128;
                    // 将数据写入Flash或文件
                    write_to_storage(&buffer[3], data_len); // &buffer[3]指向数据区开始
                    bytes_received += data_len;
                    uart_send_byte(ACK); // 确认本包
                    packet_num++; // 期望下一包编号
                    // 如果已接收字节数 >= 文件大小，说明文件传完了，等待EOT
                    if(bytes_received >= file_size) {
                        current_state = YM_STATE_WAIT_EOT;
                    }
                } else {
                    uart_send_byte(NAK); // 校验失败，请求重发
                    // 注意：这里不增加packet_num，期望发送方重发同一编号的包
                }
                index = 0; // 清空缓冲区，准备下一帧
            }
            break;

        case YM_STATE_WAIT_EOT:
            // 这个状态专门等待和处理EOT
            if(data == EOT) {
                handle_eot(); // 处理EOT，内部会处理二次确认和结束帧
            }
            break;

        // ... 其他状态处理
    }
}

3.3 关键子函数：校验与写入

上面代码中调用了几个关键函数：

• validate_header_packet: 校验头帧。包括检查块编号是否为0及其反码，计算128字节数据区的CRC16，并与帧中自带的CRC比对。同时解析出文件名和文件大小。
• validate_data_packet: 校验数据帧。检查块编号是否与期望的 packet_num 匹配（并验证其反码），计算数据区的CRC。
• write_to_storage: 将数据写入存储介质。对于IAP，这就是Flash编程的核心。这里有个大坑我踩过：一定要先擦除再写入！ Flash的特性是只能把1写成0，不能把0写成1，所以写入前对应扇区必须是全1（0xFF）。通常做法是，在接收头帧成功后，就根据文件大小计算需要擦除的Flash扇区范围，一次性擦除干净。

// 简化的Flash写入示例（以STM32 HAL库为例）
void write_to_storage(uint8_t* data, uint32_t len) {
    static uint32_t write_addr = APP_FLASH_START_ADDR; // 应用程序起始地址
    uint32_t i;
    for(i = 0; i < len; i += 4) { // 按字（32位）写入
        uint32_t word_data = *((uint32_t*)(data + i));
        HAL_FLASH_Program(FLASH_TYPEPROGRAM_WORD, write_addr, word_data);
        write_addr += 4;
    }
}

• handle_eot: 处理结束流程。实现前面协议解析里说的“二次确认”逻辑。

void handle_eot() {
    static uint8_t eot_count = 0;
    eot_count++;
    if(eot_count == 1) {
        // 第一次收到EOT，回复NAK要求二次确认
        uart_send_byte(NAK);
    } else if(eot_count == 2) {
        // 第二次收到EOT，回复ACK和‘C’，等待结束帧
        uart_send_byte(ACK);
        uart_send_byte('C');
        eot_count = 0;
        // 状态可以转移到等待结束帧，这里简化处理
    }
}

4. 效率优化与避坑指南：让升级更快更稳

实现基本功能只是第一步，要让YModem IAP在实际产品中好用，还得在效率和稳定性上下功夫。这里分享几个我积累的经验。

4.1 波特率不是越高越好

很多人觉得，升级速度慢，那就把串口波特率调到最高，比如921600甚至更高。理论上没错，但实际有瓶颈。首先，你的MCU的Bootloader代码处理每个字节、计算CRC、写Flash都需要时间。如果波特率太高，串口接收中断过于频繁，可能来不及处理，导致数据溢出丢失。其次，更高的波特率对时钟精度、线路质量要求也更高，在长线或干扰环境下误码率会上升。

我的经验是，115200或256000波特率是一个甜点。在这个速率下，大多数MCU都能从容处理，传输稳定，速度也足够快（传输一个1MB的固件大约需要1-2分钟）。务必在Bootloader里做好流控判断，比如在写Flash前暂时关闭串口中断，或者使用更大的接收缓冲区加DMA，防止数据丢失。

4.2 CRC校验的选择与优化

YModem默认使用CRC-16，具体是 CRC-16/XMODEM 变种（初始值0x0000，多项式0x1021）。这个计算在MCU上如果每次用逐位计算，会比较耗时。一个显著的优化是使用查表法。预先计算好一个256字节的CRC表，这样计算一个数据块的CRC就变成了几次查表和异或操作，速度提升一个数量级。

// CRC-16/XMODEM 查表法示例
static const uint16_t crc16_table[256] = { /* 预先计算好的表 */ };

uint16_t ymodem_calc_crc(const uint8_t *data, uint32_t length) {
    uint16_t crc = 0x0000; // 初始值
    while (length--) {
        crc = (crc << 8) ^ crc16_table[((crc >> 8) ^ *data++) & 0xFF];
    }
    return crc;
}

确保你的发送方（PC工具）和接收方（Bootloader）使用完全相同的CRC算法，否则校验永远通不过。这是调试时最常见的坑之一。

4.3 超时与错误恢复机制

工业产品必须考虑通信中断的情况。你的Bootloader里必须实现超时机制。例如，在发送‘C’呼叫后，如果10秒内收不到头帧，就应该退出升级模式，尝试重启或跳转到旧应用程序。在接收数据包的过程中，如果一段时间内收不到任何字节，或连续收到多次NAK后仍无法正确接收一包，也应视作超时错误，安全退出。

一个好的实践是，在IAP开始前，先通过串口发送一些简单的握手指令（比如发送“READY”并等待特定回复），确认上下位机链路正常，再启动YModem流程。这能避免很多无谓的等待和异常。

4.4 Flash操作的安全性与完整性验证

这是IAP的生命线。务必注意：

1. 分区规划：明确划分Bootloader区、应用程序区、可能还有备份区、参数区。在链接脚本里定好这些区域的起始和结束地址。
2. 写前擦除：这是铁律。擦除整个应用程序区，或者按扇区擦除。
3. 写保护：在跳转到新应用程序前，最好关闭对Flash的写操作，防止应用程序跑飞后意外修改自身代码区。
4. 最终完整性验证：YModem的CRC是包级别的。传输完成后，Bootloader应该对整个接收到的固件镜像计算一次校验和（Checksum）或哈希（如SHA-256），并与固件文件中预先嵌入的校验值（可以放在文件头或尾的固定位置）进行比对。只有全局校验通过，才能执行跳转。这能防止传输过程中虽然每包都对，但漏包或顺序错乱导致的整体错误。
5. 跳转前的检查：检查应用程序入口地址是否合法（通常是Flash应用程序区的起始地址+4的位置，存放的是复位向量）。可以简单读取该地址的值，判断它是否在有效的Flash地址范围内。

5. 实战搭配：好用的上位机工具与调试技巧

协议和下位机代码都准备好了，你还需要一个靠谱的发送方——上位机工具。并不是所有串口工具都支持YModem，更别说稳定支持了。

我强烈推荐 Tera Term 和 SecureCRT。它们都是老牌、专业的终端软件，对YModem协议的支持非常完善。以Tera Term为例，操作很简单：打开串口，设置好波特率，然后在菜单里选择“文件”->“传输”->“YMODEM”->“发送…”，然后选择你的 .bin 或 .hex 文件，它就会自动开始整个协议流程。它会自动处理文件名、文件大小的封装，以及所有的握手、重传逻辑，非常省心。

调试阶段，串口打印是你的最好朋友。在Bootloader的各个关键节点（收到‘C’、收到头帧、每收完10个包、收到EOT等）打印不同的日志。甚至可以把接收到的每个数据包编号都打印出来，这样当传输卡住时，你一眼就能看出是卡在哪一包了。同时，打开串口工具的“日志”功能，把整个通信过程的十六进制数据保存下来，事后可以慢慢分析。

如果遇到一直握手不成功，先别急着怀疑代码。检查一下串口线、电平转换芯片是否可靠。我曾经遇到过因为USB转串口线质量太差，导致‘C’字符发送不完整，一直无法开始传输的诡异问题。还有，确认Bootloader和上位机工具的波特率、数据位、停止位、校验位设置完全一致。YModem协议本身不支持流控，所以RTS/CTS这些硬件流控通常要禁用。

最后，当你一切就绪，第一次看到自己的设备通过串口“叮叮当当”地自动完成固件更新，并成功跳转到新程序运行时，那种成就感是非常实在的。YModem协议虽然古老，但它在简单、可靠、无需额外硬件成本的嵌入式IAP领域，依然散发着强大的生命力。把它吃透，用好，无疑是每个嵌入式工程师工具箱里一件趁手的利器。