利用Xmodem协议在Uboot环境下实现串口程序烧录的实战指南

1. 为什么需要Xmodem协议烧录？

最近在调试一块嵌入式开发板时，遇到了一个典型问题：开发板虽然设计了网络接口，但在Uboot阶段网络功能极不稳定，经常出现连接失败。更麻烦的是，这块板子除了串口之外没有其他可用接口。这时候我突然想到，既然有串口，为什么不试试最原始的Xmodem传输方式？

Xmodem协议诞生于1977年，是历史最悠久的文件传输协议之一。它采用128字节数据块传输，自带校验机制，虽然速度慢但可靠性高。在嵌入式开发中，当网络、USB等高速接口不可用时，串口+Xmodem的组合往往能救命。我实测发现，即使用最普通的115200波特率，传输一个10MB的镜像也只需要15分钟左右——这个时间对于紧急修复来说完全可以接受。

2. 环境准备与工具配置

2.1 硬件连接检查

首先确保你的开发板通过USB转串口模块与PC相连。用万用表测量TX/RX/GND三根线的连接是否正常，特别注意有些开发板需要交叉连接（PC的TX接板子的RX）。我遇到过因为线序接反导致传输失败的情况，后来发现是转换模块的标识印反了。

2.2 终端软件设置

推荐使用SecureCRT或MobaXterm这类支持Xmodem协议的终端工具。以SecureCRT为例：

1. 新建串口会话，波特率通常设为115200
2. 关闭流控（Flow Control设为None）
3. 在"Transfer"菜单中确认Xmodem功能可用
4. 建议开启日志记录功能，方便排查问题

# 查看Uboot支持的传输协议 => help [...] loadx - load binary file over serial line (xmodem) [...]

3. 完整烧录流程详解

3.1 内存地址规划

在Uboot中输入bdinfo查看内存布局。通常我们会选择DRAM的中间区域作为临时存储地址，比如0x82000000。要确保：

• 地址范围不与其他功能冲突
• 预留足够空间（镜像大小+20%缓冲）
• 避开Uboot自身使用的区域

# 示例：查看内存信息 => bdinfo memstart = 0x80000000 memsize = 0x20000000

3.2 Xmodem传输实战

1. 在Uboot命令行输入：

   => loadx 0x82000000

2. 在SecureCRT中选择"Transfer > Send Xmodem"
3. 选择要传输的镜像文件
4. 等待传输完成（进度条会显示）

传输过程中可能会遇到这些情况：

• 校验失败自动重传（正常现象）
• 长时间卡顿（尝试降低波特率）
• 数据损坏（检查串口线接触）

3.3 写入存储设备

传输完成后，按照常规流程写入Flash：

# 擦除NAND分区 => nand erase.part kernel_nand # 写入数据（注意长度要对齐） => nand write 0x82000000 kernel_nand 0x400000

4. 常见问题解决方案

4.1 传输中断处理

当遇到传输中断时，可以尝试：

1. 重新插拔串口线
2. 更换USB端口（避免供电不足）
3. 在Uboot中重置环境变量：

   => env default -a => saveenv

4.2 速度优化技巧

虽然Xmodem本身速度有限，但我们可以：

• 使用Xmodem-1K变种（如果Uboot支持）
• 提前压缩镜像（如用lzma压缩）
• 关闭终端软件的额外显示功能

# 如果支持1K块传输 => loadx 0x82000000 1k

4.3 校验验证方法

写入完成后务必验证：

# 读取回数据 => nand read 0x83000000 kernel_nand 0x400000 # 比较内存数据 => cmp 0x82000000 0x83000000 0x400000

5. 进阶技巧与替代方案

对于经常需要串口烧录的情况，建议：

1. 在Uboot中编写自动化脚本
2. 使用Ymodem协议传输多个文件
3. 考虑升级硬件（如改用USB CDC ACM协议）

# 示例自动化脚本 setenv update_script 'loadx 0x82000000; nand erase.part kernel_nand; nand write 0x82000000 kernel_nand 0x400000' saveenv

实际项目中，我遇到过需要连续烧录三个不同镜像的情况。通过结合Xmodem传输和Uboot脚本功能，成功实现了全自动化烧录流程。虽然每次要花费近一小时，但在没有其他选择的情况下，这种方案至少保证了开发的可持续性。