3. 烧录工具链介绍：J-Flash、STM32CubeProgrammer、OpenOCD、PyOCD 等工具的使用场景
做量产烧录这么多年，我见过不少团队在工具选型上栽跟头。有人拿着 J-Flash 硬刷几百片芯片，结果授权费比烧录器还贵；也有人用 OpenOCD 做产线，结果脚本写得太复杂，操作工一碰就崩。
说白了，没有万能的工具。关键是你得知道每个工具的脾气。这一章我就把几个主流烧录工具掰开揉碎讲清楚，帮你找到最适合产线的那一把刀。
核心观点：量产烧录工具选型 = 芯片支持 × 烧录速度 × 授权成本 × 自动化能力。这四个维度缺一不可。
3.1 J-Flash：J-Link 生态的王者
J-Flash 是 Segger 公司出品的烧录工具，配合 J-Link 调试器使用。我最早接触它是在 2015 年，当时一个项目要用 NXP 的 LPC 系列，烧录速度把我惊到了——刷 1MB 固件只要 3 秒。
核心优势：
- 速度极快：J-Link 的 SWD 接口能跑到 50MHz，比普通 CMSIS-DAP 快 5-10 倍
- 稳定可靠：我在产线上连续烧录过 5000 片，零失败
- 脚本支持：J-Flash 支持命令行和 .jflash 脚本，可以集成到自动化产线
- 芯片覆盖广：支持 ARM Cortex-M/R/A、RISC-V 等主流架构
我的经验：J-Flash 的 .jflash 脚本其实是个好东西。你可以在脚本里写校验、写序列号、写 MAC 地址。我习惯把烧录和产测写在一个脚本里，一次搞定。
J-Flash 命令行示例：
# 命令行烧录示例
JFlash.exe -openprjC:\project\firmware.jflash -auto -exit
# 脚本片段：烧录后校验
SetProgAddr 0x08000000
LoadFile firmware.hex
VerifyMem 0x08000000 0x08040000
SetSN 0x080FF000 0xAABBCC01
注意：J-Flash 的授权费不便宜。J-Link Base 大概 3000 元，Pro 版要上万。如果产线有 10 个工位，光授权费就够买一台烧录机了。所以大批量产线我一般不推荐用 J-Flash。
3.2 STM32CubeProgrammer：ST 芯片的官方利器
STM32CubeProgrammer 是 ST 官方出的烧录工具。说实话，早期版本挺难用的，但到了 v2.x 之后，稳定性好了很多。我现在做 STM32 项目，研发阶段基本都用它。
适用场景：
- STM32 全系列芯片（F0/F1/F4/G0/G4/H7/MP1 等）
- 支持 ST-Link、UART、USB DFU、OTG 等多种烧录接口
- GUI 操作直观，适合产线操作工使用
- 支持命令行模式（CLI），可以集成到自动化脚本
CLI 命令行示例：
# 命令行烧录 STM32F407
STM32_Programmer_CLI.exe -c port=SWD -w firmware.hex 0x08000000 -v -rst
# 读取芯片选项字节
STM32_Programmer_CLI.exe -c port=SWD -ob displ
避坑指南：我曾经在产线上遇到一个问题——STM32CubeProgrammer 在 Windows 10 上跑得好好的，换到 Windows 7 就报驱动错误。后来发现是 ST-Link 驱动版本不兼容。解决方案：统一产线操作系统版本，或者用 Zadig 工具强制安装 WinUSB 驱动。
STM32CubeProgrammer vs J-Flash 对比：
| 对比项 | STM32CubeProgrammer | J-Flash |
|---|---|---|
| 芯片支持 | 仅 STM32 | ARM/RISC-V 全系列 |
| 烧录速度 | 中等（SWD 最高 24MHz） | 快（SWD 最高 50MHz） |
| 授权成本 | 免费 | 收费（3000-10000+） |
| 脚本能力 | CLI 基本够用 | .jflash 脚本功能强大 |
| 产线推荐 | ST 芯片产线首选 | 小批量/研发验证 |
3.3 OpenOCD：开源界的瑞士军刀
OpenOCD（Open On-Chip Debugger）是开源烧录调试工具。说实话，它的学习曲线有点陡，但一旦上手，你会发现它真的很强大。我个人的产线方案里，80% 的项目都用 OpenOCD 做烧录核心。
为什么我推荐 OpenOCD？
- 芯片支持极广：ARM Cortex-M/R/A、RISC-V、Xtensa、MIPS……几乎覆盖所有主流架构
- 调试器兼容：FTDI、CMSIS-DAP、ST-Link、J-Link（部分功能）、USB-JTAG 等
- 脚本化能力强：Tcl 脚本可以写复杂的烧录流程，包括校验、加密、序列号写入
- 跨平台：Windows/Linux/macOS 都能跑，产线服务器用 Linux 最稳
OpenOCD 烧录脚本示例：
# openocd.cfg 配置文件
source [find interface/ftdi.cfg]
source [find target/stm32f4x.cfg]
# 烧录命令
proc flash_firmware {} {
init
reset halt
flash write_image erase firmware.hex 0x08000000
verify_image firmware.hex 0x08000000
reset run
shutdown
}
我的习惯：产线用 OpenOCD 时，我会写一个 Python 包装层。Python 调用 OpenOCD 的子进程，然后解析输出日志。这样产线操作工只需要点一个按钮，后台自动完成烧录、校验、数据上报。
注意：OpenOCD 的配置很繁琐。不同调试器、不同芯片的配置文件差异很大。我建议你从官方示例配置开始改，不要自己从头写。另外，OpenOCD 的烧录速度一般比 J-Link 慢 30%-50%，大批量产线要考虑这个因素。
3.4 PyOCD：Python 工程师的烧录利器
PyOCD 是 ARM 官方推出的开源烧录工具，基于 Python 实现。如果你团队里 Python 工程师多，PyOCD 会是个好选择。我最近两年开始用它，主要是看中它的 API 设计——干净、好扩展。
PyOCD 的核心特点：
- 纯 Python 实现：pip install pyocd 就能装，依赖少
- API 友好：可以写 Python 脚本控制烧录流程，比 Tcl 好理解
- 支持 CMSIS-DAP：配合 DAPLink 调试器，成本极低（几十块钱）
- 调试功能强：支持断点、单步、内存读写，适合研发阶段
PyOCD 烧录脚本示例：
# Python 脚本烧录
from pyocd.core.helpers import ConnectHelper
from pyocd.flash.file_programmer import FileProgrammer
with ConnectHelper.session_with_chip("stm32f407vg") as session:
board = session.board
target = board.target
# 烧录固件
programmer = FileProgrammer(session)
programmer.program("firmware.hex")
# 校验
target.verify("firmware.hex", 0x08000000)
# 写入序列号
target.write_memory_block32(0x080FF000, [0xAABBCC01])
print("烧录完成！")
避坑指南：我曾经用 PyOCD 在产线上跑，发现烧录到 200 片左右就会报错。排查了半天，发现是 USB 供电不足——CMSIS-DAP 调试器在连续工作时电流会飙升。解决方案：用带外部供电的调试器，或者在 USB 口加一个带供电的 HUB。
3.5 工具选型决策矩阵
说了这么多，到底怎么选？我整理了一个决策矩阵，你对着自己的需求打勾就行。
| 需求场景 | 推荐工具 | 理由 |
|---|---|---|
| 研发阶段，烧录几片验证 | J-Flash / STM32CubeProg | GUI 操作快，上手简单 |
| 小批量产线（100-1000片/天） | OpenOCD + Python 包装 | 免费，脚本灵活，可定制 |
| 大批量产线（10000+片/天） | 专用烧录器 + OpenOCD | 速度优先，稳定性要求高 |
| ST 芯片专用产线 | STM32CubeProgrammer CLI | 官方支持，免费，稳定 |
| 多芯片混线生产 | OpenOCD / PyOCD | 芯片支持广，一套脚本跑多种芯片 |
| 研发团队 Python 技术栈 | PyOCD | API 友好，扩展性强 |
我的建议：不要在一棵树上吊死。我见过最稳的产线方案是：OpenOCD 做烧录核心 + Python 做流程控制 + 数据库做数据追溯。这套组合拳打下来，基本能覆盖 90% 的量产场景。
嗯，工具就介绍到这里。记住一个原则：工具是死的，产线是活的。选工具的时候，多想想你的产线操作工能不能用、出了问题好不好排查、换芯片时改配置方不方便。这些才是量产烧录的真功夫。