基于WPF的STM32 ISP烧录上位机：从Hex解析到Flash写入全流程

简介：这套用 C# 与 WPF 开发的 STM32 ISP 上位机源码，主要面向需要自制固件烧录工具、搭建 BootLoader 升级界面或学习串口 ISP 协议的开发者，针对官方 VC 库在 WPF 环境下无法直接使用的痛点，提供了一套可独立集成和调用的通信模块。压缩包共 38 个文件、约 2.01MB，主体包含 11 个 C# 源文件、2 个 XAML 界面文件、3 个可执行程序与 2 份 PDF 文档，另有 Visual Studio 解决方案、工程配置及编译中间文件；源文件对应逻辑实现，XAML 负责界面布局，exe 可直观预览运行效果。该源码的核心 ISP 通信模块覆盖 STM32 自举流程中连接、擦除、编程、校验等关键环节，DEMO 示例清晰展示了在 WPF 应用中调用这些接口的事件处理过程，能帮助开发者理解 ISP 命令帧格式、应答机制以及状态机切换。随包提供的 USART 协议在 STM32 微控制器自举程序中应用文档，恰好补充了底层协议细节，便于对照代码分析启动配置与数据交互。截至目前已有 820 人学习下载；对需要定制 STM32 下载工具或深入掌握 WPF 串口通信的中高级开发者而言，这套可编译、可修改、带 DEMO 的源码兼顾实用性与学习价值。

1. STM32 烧录的新解法：WPF 上位机把 ISP 流程装进了现代界面

做嵌入式项目时，最影响心情的环节往往不是调 Bug，而是给板子烧录：开一个老旧的命令行式工具，手选串口、手选 Hex、盯着字节流猜进度，一旦操作错一步，轻则重启重来，重则「擦除了却没写进去」白等几分钟。这个 WPF 版的 STM32 ISP 上位机源码，就是把这个过程重做了一遍——把 STM32 出厂内置的那段串口 Bootloader 协议用 C# 实现成 Windows 桌面程序，选型号、选文件、点烧录，握手、擦除、写 Flash、校验自动完成。它适合两类人：一类是手头有 STM32 板子、想摆脱原厂串口工具的嵌入式开发者；另一类是学了 WPF 数据绑定但缺一个真实串口项目练手的 C# 初学者。

2. 技术选型与架构设计：WPF 界面、串口层和 ISP 协议层怎么各司其职

2.1 为什么用 WPF 而不是 WinForms 或控制台

STM32 ISP 的本质是串口命令交互，用控制台程序也能完成，但实际烧录有一个很现实的问题：Flash 页数多的时候过程很长，用户需要看到进度，烧错了需要明确错误发生在哪条命令上。WPF 在表达这类「状态变化」上有天然优势——进度条绑定一个属性，日志区绑定一个集合，协议层只管更新状态，界面自动跟着变化，不需要像 WinForms 那样每个控件手动 Invoke。另一个原因是界面定制成本低：产线工具往往要加 Logo、加序列号记录、加统计报表，WPF 改模板比改控件事件树轻松得多。所以这个项目选 WPF 不是炫技，是这个场景下最顺手的路线。

2.2 三层架构：界面、串口、协议各自管什么

这个项目的拆分思路很清晰，从上到下是三层。界面层负责数据绑定和交互，用户看到的下拉框、进度条、日志区都在这层；串口层封装 System.IO.Ports.SerialPort，把打开、关闭、写字节、读超时这些细节收敛到一个类里；协议层只依赖串口层，负责命令拼装、校验字节计算、ACK/NACK 判断，不关心界面长什么样。

分层带来一个直接好处：协议层可以脱离 UI 做单元测试。写命令的校验字节、ACK 判断逻辑全部是纯逻辑，接一个虚拟串口就能测；界面层即使整体重画，协议代码一行都不用动。

2.3 目录结构与关键文件

工程目录保持了典型 WPF + MVVM 项目的形状，核心文件不多，读者打开应该能快速找到入口：

STM32.ISP.Wpf/ ├── Models/ │ └── HexRecord.cs # Hex 解析后的记录：地址 + 数据 ├── Services/ │ ├── HexFileParser.cs # Intel HEX 文件解析 │ ├── SerialPortService.cs # 串口封装、端口枚举 │ └── IspProtocol.cs # ISP 命令：同步/擦除/写入/跳转 ├── ViewModels/ │ └── MainViewModel.cs # 绑定属性与烧录流程编排 ├── Views/ │ └── MainWindow.xaml # 主界面布局 └── App.xaml

整个工程没有引入第三方通讯库，串口用 .NET 内置的 SerialPort，ISP 协议是手写的。这就给二次开发留了很好的扩展点：如果你的目标芯片 Bootloader 命令格式和常见 F1 系列不完全一样，需要动的地方基本集中在 IspProtocol.cs，其他地方不用碰。

3. 核心模块拆解：一条 Hex 记录从解析到写入 Flash 的完整链路

3.1 Intel HEX 解析：把文本文件变成地址和数据

烧录的第一步是把 Hex 文件读进内存。Intel HEX 的每一行都是以冒号开头，格式是:LLAAAATTDD...CC，其中 LL 是本行数据长度，AAAA 是 16 位地址，TT 是记录类型，00 表示数据记录，01 表示文件结束，04 表示扩展线性地址（用来拼接 32 位高地址），CC 是校验和。

public static List<HexRecord> Parse(string path) { var records = new List<HexRecord>(); uint baseAddr = 0; foreach (var line in File.ReadAllLines(path)) { if (line[0] != ':') continue; int len = Convert.ToInt32(line.Substring(1, 2), 16); uint addr = Convert.ToUInt32(line.Substring(3, 4), 16); int type = Convert.ToInt32(line.Substring(7, 2), 16); if (type == 0x04) // 扩展线性地址，高 16 位 { baseAddr = Convert.ToUInt32(line.Substring(9, 4), 16) << 16; } else if (type == 0x00) // 数据记录 { var data = new byte[len]; for (int i = 0; i < len; i++) data[i] = Convert.ToByte(line.Substring(9 + i * 2, 2), 16); records.Add(new HexRecord { Address = baseAddr + addr, Data = data }); } else if (type == 0x01) // 文件结束 { break; } } return records; }

这里有两个关键点。第一，MCU 的 Flash 起始地址是 0x08000000，而 Hex 文件里大量地址在 0x08000000 以下，这就需要靠 04 类型记录给出的高 16 位去拼接，不加这个字段，写地址会整体错乱。第二，我一般不会省略校验和判断，拿到每行后把所有字节累加，低 8 位不为零就直接报「文件损坏」，这是烧录前能拦住低级错误的最后一道门。

3.2 串口封装：参数为什么是 115200 8E1

串口层做的事情不多但很重要：枚举可用端口、打开连接、带超时读写。STM32 出厂 Bootloader 在 F1 系列上默认采用 115200 波特率、8 数据位、偶校验（Even）、1 停止位，也就是常说的 8E1。

public bool Open(string portName, int baudRate = 115200) { _port = new SerialPort(portName, baudRate, Parity.Even, 8, StopBits.One); _port.ReadTimeout = 500; _port.WriteTimeout = 500; _port.Open(); _port.DiscardInBuffer(); // 清掉上电残留字节，避免干扰握手 return _port.IsOpen; } public byte ReadByte(int timeout = 500) { _port.ReadTimeout = timeout; try { return (byte)_port.ReadByte(); } catch (TimeoutException) { throw new TimeoutException($"等待应答超时，{timeout}ms 内未收到数据"); } }

很多人第一次跑这个项目时会把校验位设成 None，结果同步指令发出去永远收不到 ACK，这就是参数不一致导致的。这里有个经验：打开串口后立刻 DiscardInBuffer，因为 USB 转串口模块上电瞬间经常会在 RX 线上产生毛刺或残留字节，不清理的话，第一个 0x7F 握手字节会被残留数据挤掉，直接握手失败。读超时默认 500ms，但后面擦除命令需要单独拉长，这个在避坑章节会细说。

3.3 ISP 协议交互：命令格式与校验字节

ISP 协议的核心命令不多，最常用的是这几条：0x7F 同步、0x02 读芯片 ID、0x43 整片擦除、0x31 写内存、0x11 读内存、0x21 Go 跳转。每条命令发出后，Bootloader 会回 0x79 表示 ACK，回 0x1F 表示 NACK。

public bool Sync() { _port.DiscardInBuffer(); _port.Write(new byte[] { 0x7F }, 0, 1); return ReadByte() == 0x79; // 收到 ACK 才算同步成功 } public bool WriteMemory(uint address, byte[] data) { // 命令头：0x31 + 3 字节地址（高字节在前）+ XOR 校验 var header = new List<byte> { 0x31 }; header.Add((byte)(address >> 16)); header.Add((byte)(address >> 8)); header.Add((byte)address); header.Add((byte)(header[0] ^ header[1] ^ header[2] ^ header[3])); _port.Write(header.ToArray(), 0, header.Count); if (ReadByte() != 0x79) return false; // 数据段：长度(实际字节数-1) + 数据 + XOR 校验 var body = new List<byte> { (byte)(data.Length - 1) }; body.AddRange(data); byte checksum = 0; foreach (var b in body) checksum ^= b; body.Add(checksum); _port.Write(body.ToArray(), 0, body.Count); return ReadByte() == 0x79; }

这里最容易被忽视的是校验字节的计算规则：命令字节和地址字节做 XOR，结果需要让所有字节 XOR 之和等于 0xFF。写内存命令头四个字节 0x31、0x08、0x00、0x00 的 XOR 结果是 0x39，这个 0x39 就是校验字节，少发或者算错，Bootloader 直接回 NACK。数据段同理，长度字节和所有数据字节逐个 XOR，结果作为最后一个字节发出去。单次写入的数据长度不能超过 256 字节，实际使用时我习惯按一页大小切块，每页写一次，进度条也按页数来推进。

3.4 烧录流程编排：进度如何从协议层回到进度条

有了上面几个基础方法，烧录主流程就是一个线性编排：同步、擦除、按页写入、最后发 Go 让芯片跳进用户程序。MVVM 模式下，UI 线程不能阻塞在串口读写上，常见做法是把整个流程丢进后台任务，进度通过属性变更通知回传。

public async Task FlashAsync(string hexPath) { var records = HexFileParser.Parse(hexPath); var chunks = BuildChunks(records, _config.PageSize); await Task.Run(() => { if (!_isp.Sync()) throw new Exception("握手失败，请检查 BOOT0 和串口接线"); if (!_isp.EraseAll()) throw new Exception("擦除失败"); for (int i = 0; i < chunks.Count; i++) { if (!_isp.WriteMemory(chunks[i].Address, chunks[i].Data)) throw new Exception($"写入失败 @ 0x{chunks[i].Address:X8}"); Progress = (i + 1) * 100 / chunks.Count; } _isp.Go(_config.FlashBase); // 跳转到 0x08000000 运行用户程序 }); }

BuildChunks 做的事情是把 Hex 解析出来的零散记录按目标 Flash 页大小重新分组，同一页内的数据合并成一个 byte[]，跨页的数据拆开。页大小从哪里来？从芯片配置来，F103 中容量系列一般是 1KB，大容量系列是 2KB，这个值如果配小了，写入次数成倍增加，烧录变慢；配大了，一页可能跨越两个物理页，写入会越界。所以这个参数我建议直接写进配置表，不要写死在循环里。

4. 运行与实战：从 Visual Studio 打开到点亮第一块板子

4.1 硬件接线与 BOOT 跳线

拿到源码后别急着编译，先把硬件准备好。你需要一块 STM32 板子、一个 USB 转串口模块和几根杜邦线。接线遵循 TX 接 RX、RX 接 TX 的交叉规则：USB 转串口模块的 TX 接板子的 RX（也就是 USART1 的 PA10），模块的 RX 接板子的 TX（PA9），GND 必须共地。电压要注意，最好用 3.3V 电平的模块，如果是 5V TTL 模块，要确认板子上有没有电平转换电路，否则长期使用有烧脚风险。

BOOT 跳线是进入 ISP 模式的关键。把 BOOT0 拨到 1（高电平），BOOT1 保持 0，然后按一下复位键，MCU 启动后会进入系统存储器的 Bootloader，而不是用户程序。此时串口发 0x7F 才有机会收到 ACK。烧录完成后记得把 BOOT0 拨回 0，再按复位，用户程序才会从 Flash 正常启动。

4.2 编译启动项目

用 Visual Studio 打开解决方案文件，等待 NuGet 还原完成。这个项目没有外部依赖，还原一般几秒就结束。确认一下工程文件里的目标框架，然后直接按 F5 启动，主窗口就会弹出来。如果编译报错，九成是目标框架版本和本机安装的 .NET SDK 不匹配，右键项目改一下 TargetFramework 即可，源代码本身不需要改动。

启动后界面上的串口下拉框应该已经枚举出了当前系统的串口。插上 USB 转串口模块，如果列表里没有出现新端口，点一下刷新按钮重新枚举。枚举的逻辑是遍历 SerialPort.GetPortNames()，把结果绑定到 ComboBox 的 ItemsSource 上，这是 SerialPortService 里最简单的一段代码。

4.3 烧录操作步骤

硬件接好、程序跑起来后，操作顺序是这样：下拉框里选择设备对应的 COM 口，点击连接，日志区会出现握手成功的提示；然后在芯片型号下拉框里选择目标型号，这里决定后面的页大小和 Flash 基地址；点击选择 Hex 文件，文件对话框里选编译器生成的 .hex；最后点烧录，进度条开始走动。

烧录过程中留意日志区的输出。每一步命令都有日志：同步、擦除、写第几页、校验、跳转。如果哪一步返回 NACK，日志会带上命令字和错误地址，这个信息对定位问题很有用。整个烧录过程在中小容量芯片上通常几秒到十几秒，取决于 Hex 文件大小和波特率。

4.4 烧录完成后的验证

烧录完成并不等于万事大吉。最直接的验证是看板子行为：如果烧的是 LED 闪烁程序，LED 应该按照预期节奏闪起来；如果是带串口打印的程序，打开任意串口工具看输出。但有一种更严谨的验证方式——用 ISP 的读内存命令，把 Flash 里刚写入的内容回读出来，和 Hex 文件逐字节比对。

public byte[] ReadMemory(uint address, int length) { var cmd = new List<byte> { 0x11 }; cmd.Add((byte)(address >> 16)); cmd.Add((byte)(address >> 8)); cmd.Add((byte)address); cmd.Add((byte)(cmd[0] ^ cmd[1] ^ cmd[2] ^ cmd[3])); _port.Write(cmd.ToArray(), 0, cmd.Count); if (ReadByte() != 0x79) throw new Exception("读内存命令未应答"); _port.Write(new[] { (byte)(length - 1) }, 0, 1); var data = new byte[length]; for (int i = 0; i < length; i++) data[i] = ReadByte(); ReadByte(); // 结束 ACK return data; }

回读验证在调试自定义 Bootloader 时特别有用。如果回读数据和 Hex 不一致，问题基本出在地址映射上，而不是传输过程。我在项目里习惯烧录完成后自动回读首尾各 256 字节比对，比对通过才在界面显示「烧录成功」，这个逻辑加在 FlashAsync 末尾即可。

5. 避坑指南：串口、协议、时序三个维度的踩坑记录

5.1 端口列表里看不到 USB 串口

现象：USB 转串口模块插上后，上位机端口列表里没有任何反应，设备管理器里能看到一个带黄色感叹号的未知设备。

原因：模块的 USB 转串口芯片驱动没装上。市面上常见模块用的芯片方案五花八门，Windows 不会自动识别所有芯片。

解决：先看设备管理器里未知设备的名字，根据硬件 ID 找到对应驱动装好，然后重新打开上位机点刷新。另外提醒一句，有些劣质模块用的芯片是克隆方案，驱动要认准硬件 ID 而不是包装盒上的品牌。

5.2 点连接一直握手超时

现象：点连接后日志区报「等待应答超时」，0x7F 发出去没有任何回应。

原因：这个是最常见的翻车点，原因通常是三个之一——BOOT0 没拨到高电平，MCU 还在跑用户程序；TX/RX 接反；串口参数不是 115200 8E1。

解决：先检查 BOOT0 拨到 1 并且按过复位键；然后对调 TX 和 RX 两根线；最后确认串口打开参数是 Parity.Even。如果三者都没问题，用示波器或逻辑分析仪看一下 RX 线上有没有 0x7F 波形的回应，这一步能快速区分是硬件不通还是协议不对，省得瞎猜。

5.3 擦除命令发出后程序卡住

现象：日志停在「擦除」这一步，进度条一动不动，过一会儿报超时，或者直接界面假死。

原因：擦除整片 Flash 对中小容量芯片也需要几秒钟，而串口读超时默认只有 500ms，Bootloader 还在擦除时上位机已经超时放弃了。另一个可能是某些 Bootloader 版本不支持 0x43 整片擦除，只认扩展擦除命令 0x44。

解决：擦除前把串口 ReadTimeout 临时拉长到 5000ms，磨刀不误砍柴工。老版本 Bootloader 不支持整片擦除的，切换到扩展擦除命令，先读出芯片页数量，再逐页标记后擦除。这个逻辑要在协议层做分支，不要写死在 UI 里。

5.4 写 Flash 时返回 NACK

现象：烧录进度走到某个地址，日志报「写入失败 @ 0x0800xxxx」，协议层收到 0x1F。

原因：写入地址超出了芯片 Flash 的实际范围。Hex 文件没问题，但芯片型号选错了——选了小容量型号，页大小和 Flash 总容量参数不匹配，导致分块地址越过末尾。

解决：核对芯片型号和实际板子的料号，F103C8 是 64KB，F103ZE 是 512KB，容量不同分块策略完全不同。另外注意地址对齐，写内存命令要求地址按字节连续写入，但每次写入的数据长度如果跨页，要拆成两次写，不能图省事一包塞进去。

5.5 烧录成功但程序不运行

现象：进度条走满，日志显示「烧录成功」，但板子没有任何反应，LED 不闪，串口无输出。

原因：上位机没有发 Go 跳转指令，或者发了但跳转地址不对；另一个常见原因是 BOOT0 还在高电平，复位后又进了 Bootloader，看起来就像程序没烧进去。

解决：检查流程末尾有没有调用 0x21 命令跳转到 0x08000000；然后确认 BOOT0 拨回 0，手动按一次复位。这两个环节都对了还是没反应，用回读功能读 Flash 起始地址的数据，和 Hex 文件开头比对，基本能区分是没烧进去还是没跑起来。

6. 二次开发思路：从「能烧」到「好用」的三个改造方向

6.1 芯片参数配置表化

这个项目最初的芯片型号是写死在代码里的，想支持新芯片就要改协议层，改完还可能影响已经在用的型号。我接手后会做第一件事：把芯片参数抽成配置表。每个芯片维护三个核心参数——Flash 基地址、页大小、芯片 ID，存进一个字典。

public record ChipConfig(uint FlashBase, uint PageSize, ushort Pid); private static readonly Dictionary<string, ChipConfig> ChipConfigs = new() { ["STM32F103C8"] = new(0x08000000, 0x400, 0x410), ["STM32F103ZE"] = new(0x08000000, 0x800, 0x414), };

下拉框直接绑定这个字典的 Keys，烧录时按选中型号取配置，IspProtocol 只接收配置参数，不再关心具体型号。之后再加 F4、F0 系列，就是往字典里加一行的事。

6.2 用 GetID 自动识别目标芯片

配置表有了，下一步就是让工具自己认芯片。用 0x02 命令读芯片 ID，Bootloader 会返回 ACK、长度、ID 字节和结束 ACK。这个 ID 和配置表里的 Pid 一比对，型号就确定了，选错型号这种低级错误可以从流程上杜绝。

public ushort GetPid() { _port.Write(new byte[] { 0x02, 0xFD }, 0, 2); if (ReadByte() != 0x79) throw new Exception("GetID 命令未应答"); int len = ReadByte() + 1; ushort pid = 0; for (int i = 0; i < len; i++) pid |= (ushort)(ReadByte() << (8 * i)); ReadByte(); // 结束 ACK return pid; }

实现在协议层加就够了，界面层在握手成功后就调用，拿到 ID 自动匹配下拉框，匹配不上就弹警告。这一步做完，工具从「手动选型号」变成「插上就识别」，离产线可用近了一大步。

6.3 产线批量模式

最实用的一个改造是加批量烧录。逻辑不复杂：后台起一个定时器轮询串口列表，一旦发现有新设备接入就自动执行握手、读 ID、烧录、回读校验，完成后记录结果到 CSV，并弹出提示换下一块板子。界面加一个「批量模式」开关，再把进度计算从单次烧录改成「累计烧录数量 / 目标数量」。

这个模式对产线场景是刚需，但对个人开发者来说，它更大的意义是把整个烧录流程变成可重复验证的自动化路径，而不是每次手动点按钮。从那以后我每次改协议层代码，都会强制走一遍完整流程：同步、读 ID、擦除、写一页、回读比对、Go，五步缺一不可，宁可多花两分钟也不想再被「玄学失败」折腾。希望帮到你。

本文还有配套的精品资源，点击获取