文件传输 (XMODEM / YMODEM)

文件传输 (XMODEM / YMODEM)

XMODEM 与 YMODEM 在已经建立的连接上传送文件，收发双向都可以。最常见的用途是固件升级：设备进入 bootloader，每秒吐一个 C，等着你把镜像送进去。

收发各支持五种：XMODEM（128 字节，累加和）、XMODEM-CRC、XMODEM-1K、YMODEM 和 YMODEM-G。绝大多数 MCU bootloader——ST 官方 AN3155 以及大量国产 BSP——只认 YMODEM，所以优先选它。

串口、TCP 客户端、TCP 服务端，以及经 RFC 2217 的远端串口，四种连接都能传。UDP 不提供：XMODEM/YMODEM 靠块号重传，数据报一旦乱序就无法重新同步。

不支持 ZMODEM。对端是 Linux 目标机时，用 sz -X / rz -X 让它切到 XMODEM/YMODEM 模式，同样能完成这件事。

传输期间，协议字节不会进入接收区、日志和云控制台；接收区上方出现一条进度条，显示文件名、协议、已传字节、速率、剩余时间和重传次数。它不是模态对话框，所以 bootloader 自己的输出始终可见。

向设备发送文件

1. 正常连接，并确认波特率是 bootloader 的波特率——它常常和应用程序的不一样。
2. 让设备进入 bootloader，接收区应该能看到它在用 C 轮询。
3. 选择 连接 → 发送文件…（Ctrl+Shift+S）。
4. 协议选 YMODEM，选择文件，确定。

不需要掐时机：传输一启动就会接管设备的轮询，屏幕上已经出现的那些 C 不影响。

对话框顶部那一行灰字——COM3 · 115200 8N1 · 无流控——每次都值得看一眼。传输起不来最常见的原因就是这一行不对，事先看见它比事后任何错误提示都有用。

如果设备手册写的是 XMODEM，就改选 XMODEM-CRC 或 XMODEM-1K。

从设备接收文件

选择 连接 → 接收文件…（Ctrl+Shift+R），选好协议和目录，再让设备侧开始发送。

文件名由设备给出，因此按不可信输入处理：路径分隔符、控制字符和 Windows 保留设备名都会被剔除，结果一定落在你选定的目录里。已存在的文件绝不会被覆盖——第二个 app.bin 会保存为 app (1).bin。只要磁盘上的名字和设备要求的不一致，事件行都会说明；文件用一个你没选过的名字存下来，等于你找不到它。

数据先写进隐藏的 .part 文件，传输完成时才改名就位，所以半个文件永远不会看起来像完整文件。

有两条限制来自协议本身，不是本软件的取舍：

• XMODEM 不带长度，收到的文件总会用 0x1A 补齐到块大小的整数倍。需要精确长度时——例如要校验固件镜像的 CRC——请用 YMODEM。
• XMODEM 不会声明自己传完了，所以接收有大小上限，默认 100 MB，可在接收对话框里改。没有这条上限，一个不发 EOT 的设备会一直写到磁盘满。

传输期间会被接管的操作

传输独占端口。进行期间，下列操作会被拒绝并给出原因，而不是静默失效：发送按钮、自动发送、终端键盘输入、云控制台发送、Break、DTR/RTS、修改串口参数、暂停显示，以及对该端口建立桥接。

后四项特别值得点名，因为它们都不是“发送数据”：一次 Break 是一串成帧错误，拉低 DTR 会让很多设备直接复位，改一个参数会重开端口，暂停显示会截住协议正在等待的字节。任何一项都足以终结一次升级。

停止连接始终允许。它会先发出取消序列，但只等很短时间——“停止”不能卡住。

向主动连入的设备传输（TCP 服务端）

XMODEM/YMODEM 的设计假设“对端只有一个”，而 TCP 服务端有几个客户端连进来就有几个。因此传输在启动时会钉住一个客户端，之后的收和发都只认它。

只有一个客户端时自动选中；有多个时必须先在客户端列表里选一个——这里刻意没有像发送按钮那样回退到“第一个”。手工发一帧发错对象，看一眼就知道；把固件刷进错误的设备，不会。

其余客户端在整个传输期间照常收发、照常显示，中途新接入的客户端也不影响传输。被钉住的客户端一旦掉线，传输立即失败，不会干等协议超时。

“设备主动连上来”这种拓扑正是大量 4G DTU 和边缘网关的用法，而只能拨出去的终端软件根本接不上它们。

YMODEM-G 与硬件流控

YMODEM-G 是流式的：发送方不等每一块的应答。这让它更快，同时也意味着完全没有重传——一次出错就是整体失败。

因此它需要硬件流控（RTS/CTS）。没有流控时，YMODEM-G 不是“慢一点”，而是“传到一半必炸”，所以在无流控的连接上该选项直接置灰，旁边写明原因。

传输失败时

有三条行为最好在遇到之前就知道：

• 取消发送后，设备仍会再收到最多一块数据。 已经交给操作系统的字节收不回来。如果那是一次固件升级，请重新完整升级一次。
• 断线绝不会自动续传。 对正在写 flash 的设备来说，静默续传是危险的：这一侧根本不知道设备处于什么状态。明确失败、重新升级，比“看起来成功了”安全得多。
• 接收失败会保留已收到的部分，改名为 <文件名>.partial，路径写在事件行里；但主动取消会删除它。取消是你的意图，断线不是。

隔着设备服务器升级（RFC 2217）

用 远端串口 (RFC 2217) 连上去，上面所有内容照常适用，办公室里的工程师就能升级现场的设备。对端只要是 RFC 2217 服务端即可——Moxa NPort、ser2net 这类设备服务器，或另一台开着服务端模式的本软件。

普通 TCP 转发也能把文件搬过去，但 bootloader 的波特率通常与应用程序不同，而只有 RFC 2217 能改远端串口的波特率。先设远端参数、再传文件，两件事在同一条连接上完成，远程升级才真正走得通。