1. 先把工具链的定位讲清楚为什么是 J-Link Commander 和 JFlash1.1 三种烧写方式的真实差别做 STM32F103C8T6 开发的人手上大概率同时存在三套下载通道IDE 里点一下的下载按钮、串口 ISP 的 flash loader还有 J-Link 这一套。很多新手会觉得我 Keil 里点 Download 就完了为什么还要折腾 J-Link Commander 和 JFlash——这个问题我当年也问过直到产线上要烧两百块最小系统板Keil 一块一块点点到怀疑人生才明白这两种工具的定位完全不同。IDE 内置下载的本质是把 J-Link 或者 ST-Link 的驱动当作一个普通调试器调用烧写流程被 IDE 封装死了编译、下载、复位、启动全部打包你只能看到结果。它的好处是顺手坏处是你根本不知道到底发生了什么一旦报 Flash Download failed - Target DLL has been cancelled就只能干瞪眼。J-Link Commander 是 SEGGER 官方提供的命令行交互工具它把连接目标、擦除、写入、校验、复位、运行这些动作拆成一条条独立的命令交到你手上每一步成功还是失败都清清楚楚。JFlash 则是同一套底层引擎的图形化封装适合批量生产、需要保存工程配置、或者不习惯敲命令的场景。换句话讲J-Link Commander 解决的是可控和可脚本化JFlash 解决的是可复用和可批量。STM32F103C8T6 这块芯片本身没有太多烧写上的花样64KB Flash 从 0x08000000 开始SWD 两条线加复位和地就够用正因为简单才特别适合拿它来把这两个工具彻底摸透。摸透之后你换成 STM32F407、换成 GD32 或者国产替代型号思路是一致的只是器件名和 Flash 算法换一下而已。1.2 什么时候你一定会用到这两个东西我梳理了一下自己实际遇到的场景大概有这几类第一程序里误把 PA13、PA14 配置成了普通 GPIO 或者复用成了别的功能导致常规方式连不上芯片这时候需要在连接方式上动脑筋第二板子上没有留串口也没有 ST-Link只有一根 J-Link 的排线第三需要把别人给的一个裸 .bin 文件烧进去手上根本没有工程源码Keil 里连下载按钮都没法点第四产线小批量需要把烧写动作做成一条命令交给操作员甚至需要按序列号写入不同的东西第五怀疑芯片被读保护锁了或者需要主动给程序加上读保护。这几类场景里前两类是调试阶段的常态后三类是工程化和生产阶段绕不开的。JFlash 自带一个 Flash 工程文件.jflash把器件型号、接口类型、速度、Flash 算法、连接方式全部固化下来下次双击打开就能直接烧哪怕换个人来操作也不会设错参数。J-Link Commander 则更适合写进批处理脚本配合-CommandFile或者-CommanderScript参数一句命令跑完全流程出错了还能看日志。这两种用法的差别我后面会用具体命令和界面参数讲清楚包括哪些参数是必须改的、哪些保持默认就行。另外提一句STM32F103C8T6 的最小系统板在市面上流通量极大板子质量参差不齐我遇到过 USB 口虚焊、3.3V 稳压芯片输出只有 2.9V、复位电容焊成了 100nF 导致上电复位不干净等情况。这些问题在 IDE 里表现为偶尔能下载偶尔不能在 J-Link Commander 里会表现得更直接反而更容易定位——这也是我更推荐用命令行先做一次连通性验证的原因。2. 硬件侧的准备接线、供电和最小系统板上的坑2.1 J-Link 与 STM32F103C8T6 的接线对照STM32F103C8T6 的 SWD 接口只有两根信号线加上电源和地一共四根就能工作但真正接的时候有几个细节决定了你能不能一次连上。JTAG 那套 20 针排线在最小系统板上根本没有对应插座所以必须用 20 针转 SWD 的转接小板或者用杜邦线直接从 J-Link 的 20 针插座上引出来。标准接法是这样的J-Link 的 pin1VTref接目标板的 3.3Vpin7SWDIO接 PA13pin9SWCLK接 PA14pin4、pin6、pin8、pin10 等接地脚接目标板的 GNDpin15nRESET接目标板的 NRST。VTref 这根线特别关键它不是一个可选的参考电压而是 J-Link 用来判断目标板是否上电、以及按照什么电平标准驱动信号的依据。很多人只接了 SWDIO、SWCLK 和 GND 三根线结果 J-Link Commander 里一直提示 Cannot connect to target就是因为 VTref 空着J-Link 认为目标板没供电。我实测下来把 VTref 接到 3.3V 之后再连成功率立刻从一半变成稳过。J-Link 20 针脚位信号名接到 STM32F103C8T6pin1VTref3.3V必须接pin4 / pin6 / pin8 / pin10GNDGND至少接两根pin7SWDIOPA13pin9SWCLKPA14pin15nRESETNRST建议接pin5可选一般悬空关于 nRESET我的建议是必须接。STM32F103C8T6 在程序运行起来之后如果固件里把 SWD 引脚复用掉了、或者进了某种低功耗等待状态SWD 接口可能会响应不上。这时候只要有 NRST 控制权就能在连接时把芯片按住复位再接管总线成功率天差地别。另外有些板子的 NRST 上并了一个 100nF 电容这个电容对 J-Link 的复位驱动来说属于轻负载问题不大但如果有人焊了 10uF复位信号边沿会变得很慢可能导致连接不稳定。2.2 供电、BOOT 跳线和共地问题供电这件事看着简单实际上是我踩过最多次的坑。常见做法有两种一是目标板自己通过 USB 或外部电源供电J-Link 只接 VTref、SWDIO、SWCLK、GND、NRST二是直接用 J-Link 输出的 3.3V 给目标板供电。第一种做法更安全但要求两个电源必须共地否则信号电平没有公共参考通信会时好时坏。第二种做法省事但要注意 J-Link 的 3.3V 输出电流能力有限最小系统板本身加上一个 OLED 或者几个 LED 大概一百多毫安还能撑住如果板子上还挂了电机驱动、WiFi 模块这类耗电大户就千万别指望 J-Link 供电会表现为烧写中途失败或者校验不过。BOOT0 跳线是另一个隐蔽的坑。STM32F103C8T6 上电时根据 BOOT0 和 BOOT1PB2的电平决定从哪里启动BOOT0 接 3.3V 进入系统存储器启动也就是串口 ISP 模式。如果你上一次做串口下载把跳线帽挪到了 1 的位置忘了挪回来J-Link 还是能连上也能擦除和写入但写完复位之后程序不跑你会以为是烧写失败其实是芯片压根没从 Flash 启动。我自己定了个习惯只要用 J-Link 烧写先把 BOOT0 跳线帽短接到 GND 那一侧再开始操作能省掉大量明明烧进去了为什么不亮的排查时间。还有一点关于杜邦线长度这个属于实战经验。SWD 在 4MHz 下对线长和线材质量比较敏感市售那种几十厘米的彩色杜邦线随便盘成一团再接到板子上很容易出现 RDDI-DAP Error 或者 Could not connect to target。我的做法是把线剪到 15 厘米以内SWCLK 和 GND 尽量挨着走实在需要长线就把速度降到 1000kHz 甚至 500kHz牺牲一点烧写时间换稳定批量烧写时这点时间完全可以接受因为一个 64KB 的固件在 500kHz 下也就两秒左右。2.3 连接方式的选择普通连接和 connect under resetJ-Link 连接目标有两种典型策略。一种是普通连接J-Link 直接把芯片 halt 住然后接管 SWD另一种是复位下连接即 J-Link 先拉低 NRST 把芯片按在复位状态在复位释放的瞬间抢占总线。两者的区别在芯片跑飞或者固件里有异常配置时才体现出来。我举个例子曾经写过一段测试代码把 PA13 配置成了普通的推挽输出用来点灯验证引脚复用结果代码下载进去之后第二次连接就开始报错。这种情况在普通连接下基本无解因为芯片一上电就跑进你的程序几毫秒内就把 SWD 引脚改成了 GPIOJ-Link 根本没有窗口期抢到总线。此时在 JFlash 的工程设置里把连接方式改成 Connect under Reset或者在 J-Link Commander 里用connect命令时配合硬件复位、甚至用-JTAGConf之类的参数调整问题就能解决。JFlash 界面里对应的选项通常在 Target Interface 页面的 Reset 策略下拉框可选 Normal、Reset Halt、Connect under Reset 等实测 Connect under Reset 对付这类情况的成功率最高。提醒如果芯片已经被读保护锁死普通连接和复位下连接都可能失败这时候需要走解保护流程那个过程会整片擦除 Flash具体操作我放在第 5 节讲。3. J-Link Commander 命令行烧写全过程3.1 连接与器件选择的关键交互安装好 J-Link 的官方软件包之后在安装目录下能找到 JLink.exe直接双击就进了交互界面。第一步永远是把固件和芯片型号对上号再连接顺序错了会浪费很多时间。输入connect回车工具会依次问你三件事器件型号、目标接口类型、接口速度。器件型号这一栏输入STM32F103C8即可注意很多老教程写的是STM32F103C8T6实际上 SEGGER 的器件库里通常只登记到 C8 这一级T6 是封装和温度等级后缀不影响内核和 Flash 结构。如果拿不准填什么输入一个问号?会弹出一个选择列表可以在里面搜 STM32F1 系列实在找不到完全匹配的退一步选Cortex-M3也能连上但 Flash 算法需要另外指定不太推荐。接口类型这里选S也就是 SWD。JTAG 需要五根线以上最小系统板没这个必要而且 SWD 引脚少、抗干扰相对好一些。速度这一栏默认给出的是 4000kHz接线短的板子可以直接回车线比较长或者板子上有干扰源就手动敲1000或者500。这三项确认完如果连接成功你会看到一串设备信息包括 CoreSight 组件、AP 索引、Flash 容量之类如果失败会明确告诉你卡在哪一步比如 Could not find core in Coresight setup 或者 Cannot connect to target。连接成功后第一件事建议先跑一条erase把整片 Flash 擦干净。STM32F103C8T6 是 64KB 空间页大小 1KB全片擦除耗时大约一两秒。这么做的原因是你手上的 .bin 文件很可能不是全片镜像只覆盖了前面一部分地址尾部残留着上一版程序的代码如果只用局部擦除会有脏数据留下某些情况下会干扰运行。全片擦除最省心代价只是多等一秒。3.2 烧写、校验、运行三步走擦除完成后就可以写入了。命令格式是loadbin 文件路径, 起始地址注意中间有空格地址部分习惯写成十六进制并带 0x 前缀J-Link loadbin C:\fw\demo.bin, 0x08000000 Downloading file [C:\fw\demo.bin]... Comparing flash [100%] Done. Erasing flash [100%] Done. Programming flash [100%] Done. Verifying flash [100%] Done. O.K.这里有个细节值得说一下J-Link Commander 的loadbin在写入之后会自动做一次校验所以一般不需要额外再敲verifybin。但如果你的固件是别人给的、来源不太可靠或者传输路径上经过了网络共享目录我还是建议再手动跑一次verifybin做双重确认命令格式和 loadbin 一样只是把动作换成比对。写完之后不要急着拔线还要让程序跑起来。r是复位go是继续运行。这两条一般连着用r之后芯片停在复位向量处go才真正开始执行。我见过有人只敲了loadbin就拔线结果程序没启动跑来问我为什么烧录失败——其实一点都没失败只是芯片还停在调试器拉住的状态。另外如果想停下来检查内存可以用h让芯片 halt再用mem 地址, 个数查看内容比如mem 0x08000000, 8看 Flash 开头的几个字。3.3 读回数据与常用调试命令J-Link Commander 里我最常用的一个命令是savebin它能把目标芯片里的内容读回来存成文件。做逆向分析、比对两块板子固件是否一致、或者怀疑烧写数据被改这招都很管用。格式是savebin 文件路径, 起始地址, 字节数例如读回整片 64KBJ-Link savebin C:\dump\readback.bin, 0x08000000, 0x10000 Reading 65536 bytes from address 0x08000000读回来之后用任意二进制比较工具跟原始文件对比字节完全一致才算真烧进去了。这里有个前提如果芯片启用了读保护读回会全部是 0 或者直接报错这是正常的保护行为不是工具问题。还有几个命令值得记住。w4 地址, 数据是写 32 位字调试时临时改个变量或者改个跳转很方便但要注意它写的是 RAM 还是 Flash写 Flash 需要先擦页。unlock这个命令在老版本里用于解锁某些型号的芯片STM32 系列不一定支持用之前建议先看当前版本的帮助。exit和qc都是退出区别是qc会静默关闭适合写在脚本最后一行。另外每次连接都会自带一些信息输出把窗口内容重定向到日志文件对排查间歇性故障特别有用。3.4 脚本化与自动化一条命令跑完整个流程真正的效率提升来自把命令写成脚本。J-Link 支持两种脚本方式用错了参数会白折腾半天我把它们的区别讲清楚。第一种是-CommandFile它的内容是连接完成之后依次执行的命令适合你已经在命令行里把器件和接口都指定好了的场景第二种是-CommanderScript它模拟的就是你在交互界面里从头敲的过程所以脚本里第一行通常要写connect以及后续的型号、接口、速度选择。我常用的写法是前者命令行一次性把参数带全JLink.exe -device STM32F103C8 -if SWD -speed 4000 -autoconnect 1 ^ -CommandFile flash.jlink -ExitOnError 1对应的 flash.jlink 内容如下erase loadbin C:\fw\demo.bin 0x08000000 verifybin C:\fw\demo.bin 0x08000000 r go qc这里-autoconnect 1让工具启动后自动连接省去了交互输入-ExitOnError 1保证任何一步失败就退出并返回非零错误码方便上层批处理判断结果。批量烧写时我会在外面套一层 bat 脚本遍历固件目录把每个文件都跑一遍日志统一输出到一个文本文件里。注意loadbin后面的路径如果带空格一定要用引号括起来否则参数会被截断报找不到文件。4. JFlash 图形化烧写从建工程到批量生产4.1 新建工程与参数设置JFlash 的界面比 Commander 友好很多第一次用它建一个 STM32F103C8T6 的工程大概三分钟就能完成之后这个 .jflash 文件就固化了所有配置传给同事或者产线操作员直接双击即可。打开 JFlash选择 File → New Project会进入一个向导。第一步选器件输入 STM32F103C8 搜索选中之后下面的 Flash 大小、页大小、RAM 信息都会自动带出来注意确认 Flash 是 64KB。这里我要多说一句市面上流通的 STM32F103C8T6 里有相当一部分实测可用容量超过标称的 64KB社区里也常有讨论。但工程上不要依赖这个现象选芯片时老老实实按 64KB 规划测试阶段可以用 savebin 从 0x08010000 往后读一下看看有没有内容作为了解即可产品设计上千万别越界。第二步选接口也就是 SWD 和速度。速度我在图形界面里通常填 1000 到 4000kHz如果现场连接不稳就降到 500。同一页还有复位策略前面提到的 Connect under Reset 就在这里设置。第三步是 Flash 算法选中 STM32F103C8 之后算法一般会自动匹配如果没匹配上手动在列表里找 STM32F10x 系列对应的算法文件添加。全部设置好之后点 Test Connection能读回芯片 ID 就说明通了这时候把工程保存成 .jflash 文件。设置项推荐值说明器件型号STM32F103C8不要写全称 C8T6后缀会影响匹配接口类型SWD两线制接线最省接口速度1000~4000kHz线长时降到 500kHz复位策略Connect under Reset固件占用 SWD 引脚时必备Flash 算法STM32F10x 对应算法选完器件一般自动带出4.2 加载固件与烧写校验工程建好之后接下来就是打开固件。File → Open Data File 选择 .bin 文件JFlash 会弹出一个对话框问你地址填 0x08000000这一步填错的概率很高有人顺手填了个 0x00000000烧进去之后程序完全不跑因为 Flash 映射在 0x08000000从 0 地址启动是别的东西。填完之后界面上会显示出固件在地址空间里的占用范围我可以直观看到这份固件大概有多大如果显示长度明显超过 64KB那就得回头看看用的芯片型号是不是选错了。烧写就是点 Target → Program Verify或者直接按快捷键。JFlash 会依次完成擦除、编程、校验进度条走完弹出一个成功提示。它的一个好处是日志区域会给出详细耗时和每一步的结果出问题时比 IDE 里的那句下载失败信息量大得多。如果想在烧完之后立刻看到效果可以在工程设置里勾选 Start Application after programming或者手动点 Target → Reset Run。关于校验我建议一直保留 Verify 这个动作。JFlash 默认就是 Program Verify别为了省那零点几秒把校验关掉。实测校验能抓出相当一部分隐蔽问题比如目标板供电不稳导致个别字节写入失败、杜邦线接触不良导致数据错位这些问题如果不校验程序可能能跑但存在偶发异常排查起来极其痛苦。4.3 生产模式与命令行自动化JFlash 有一个专门的 Production 页面这个功能对做小批量的人非常有用。它可以把烧写流程配置成一键操作连上板子点一个按钮自动完成擦除、编程、校验、复位然后弹出请更换下一块板的提示操作员按空格继续。它还支持序列号自动递增可以写到芯片内部的某块区域或者选项字节里做产线溯源用。虽然 STM32F103C8T6 的选项字节空间有限但如果只是存一个递增编号到指定的 RAM 或 Flash 保留扇区完全没有问题。自动化方面JFlash 同样支持命令行启动典型写法是把工程、固件、自动执行、退出这几个参数串起来JFlash.exe -openprjC:\proj\stm32f103c8.jflash -openC:\fw\demo.bin,0x08000000 -auto -exit参数之间的空格和逗号位置比较讲究-openprj后面直接跟文件路径不加空格-open后面的地址用逗号分隔。不同版本的参数支持不太一样写脚本之前先用-?看一下本机帮助以实际输出为准不要照抄网上的老教程。在产线环境下这一条命令可以写进批处理文件配合扫码枪读入固件路径实现不同产品共用一套烧写工位。经验如果要把烧写工位交给不熟悉技术的人操作建议把 .jflash 工程和固件路径都固定好写成 bat 脚本双击运行日志自动写到带日期的文件里。一旦出现批量不良翻日志能快速判断是工具问题还是板子问题。5. 选项字节、读保护与加密那些事5.1 读保护到底保护了什么很多人问 STM32F103C8T6 怎么加密其实这块芯片没有一个真正意义上的硬件加密引擎所谓加密通常指的就是 Flash 读保护也就是 RDP。它的作用机制很直接一旦置位读保护通过 SWD 或者 JTAG 读取 Flash 内容时返回的数据会被硬件屏蔽同时禁止从 RAM 启动、禁止调试器查看代码区。但要注意读保护只是防止别人把固件读出来复制它并不能阻止别人整体擦除芯片也不能阻止别人重新烧一份自己的程序进去。所以如果你的诉求是防止竞争对手抄板抄代码读保护能用但别指望它坚不可摧真正的商业保护还得靠外置加密芯片、唯一 ID 绑定之类的组合手段。STM32F103C8T6 内部有一个全球唯一的 96 位 ID存放在系统存储区地址在 0x1FFFF7E8 附近。一个很常见的做法是固件启动时读取这个 ID用自家算法做一次映射把结果和某个存储位置里预先写入的校验值比对不匹配就不让主程序跑起来。这样即使固件被完整复制到另一块芯片上因为 ID 不同程序也不会正常工作。这个方案不需要额外的硬件成本为零我做过好几个小项目都在用。5.2 加保护与解保护的实际操作和代价在 JFlash 里读保护的开关在 Target 菜单下的选项字节区域一般叫 Option Bytes 或者 Security 相关条目。操作方式是先在 Target → Connect 连上芯片然后打开选项字节编辑界面把读保护相关的位勾上写入并确认芯片会自动复位生效。在 J-Link Commander 里也可以直接对选项字节区域做读写STM32F1 的选项字节在 0x1FFFF800可以用mem命令读出来看看当前状态但写入涉及解锁序列操作不当有一定风险新手建议还是走 JFlash 的图形界面。解保护的代价必须说清楚这是最容易出事的地方。解除读保护的同时芯片硬件会强制擦除整片 Flash也就是说你加锁的固件会一起消失而且这个过程不可逆。我见过同事为了对比两块板子的固件随手点了解除保护结果把一块已经调试好的成品板清空了只能重新烧。所以加保护之前一定要留好源码和固件备份解保护之前要确认这块板子上的程序不需要保留。还有一个细节加了读保护之后用 savebin 读回来的数据会全部是零或者直接报错这不是工具坏了是硬件在起作用。同样加了读保护的芯片J-Link 连接时可能会提示一些额外的警告信息比如提醒你目标芯片受保护这是正常现象。提醒给量产板加读保护之前先在废弃板或者空板子上练习一遍加锁、解锁的完整流程确认你能熟练解除再上真实产品。这一步花十分钟能省下很多麻烦。6. 常见问题速查与排查思路6.1 连接类报错逐条拆解连接问题占了实际故障的七成以上我把常见的几条按出现频率排一下。第一条是 Cannot connect to target绝大多数情况下是接线问题VTref 没接、GND 没共地、SWDIO 和 SWCLK 接反了、或者杜邦线中间断了。排查方法是拿万用表量一下 J-Link 的 pin1 到目标板 3.3V 之间是否导通再量 pin7 到 PA13、pin9 到 PA14 是否导通。我遇到过一根杜邦线外皮完好但内部铜丝断了的情况量了才发现这类问题没有任何软件手段能解决。第二条是 RDDI-DAP Error 或者 Could not find core in Coresight setup通常是速度太高或者线太长。把速度从 4000kHz 降到 1000kHz再不行降到 500kHz多数能解决。另外目标板供电电压偏低也会触发这个错误尤其用 J-Link 直接供电时板子上挂的负载一多电压被拉到 3.0V 以下SWD 时序就开始出问题。这时改用外部电源供电只保留信号线和共地。第三条是程序烧进去之后连不上了常见于固件把 PA13、PA14 改作他用或者进了深度睡眠。解决办法是切换到 Connect under Reset 模式或者在连接时按住板子的复位键点下连接按钮再松手人为制造一个抢占总线的窗口。这个方法土但有效我救过好几块被自己代码锁死的板子。报错信息高概率原因优先处理动作Cannot connect to targetVTref 未接、未共地、线序错逐根量通断补接 VTrefRDDI-DAP Error速度过高、线过长、供电低降速至 500~1000kHzCould not find core芯片未上电、复位异常量 3.3V检查 NRST烧录后再次连接失败固件占用 SWD 引脚改用 Connect under Reset6.2 烧写与校验类报错烧写阶段的错误相对好定位因为工具给的信息比较具体。出现 Programming target failed 时先看是不是 Flash 地址超出范围比如器件型号选成了容量更小的版本。STM32F103C8T6 是 64KB如果误选成 STM32F103C4 那种小容量型号写到 0x08004000 之后就会报错。反过来选成了 128KB 或者更大的型号工具不会报错但写到超出真实容量的地址时数据实际上是丢掉了这时候必须靠 verifybin 才能发现。校验失败 Verify failed 的原因分成两类数据类问题和硬件类问题。数据类包括固件文件本身损坏、路径指向了旧版本文件、地址填错硬件类包括供电不稳、Flash 擦除不干净、芯片本身有坏块。我遇到过一块二手最小系统板反复校验失败换了三根线、两个 J-Link 都没用最后用 savebin 读回对比发现固定某一段地址写进去的值和原值差一位判断是芯片那个扇区有问题直接换板子解决。这种硬件缺陷靠软件折腾是没用的学会读回比对能省很多时间。还有一个隐蔽的坑部分国产替代型号或者翻新片子在擦除和写入时序上跟原厂存在细微差异用原厂参数烧写偶尔会失败。遇到这种情况可以试试降低速度、增加擦除次数或者在 JFlash 里给 Flash 算法加一点延时参数。如果确认是替代型号最好在 J-Link 的器件库里直接选对应的型号识别率和烧写稳定性都会更好。6.3 一些没人告诉你但很关键的实操心得第一条心得永远保持一份可回退的固件。每次烧写前用 savebin 把当前芯片内容读出来备份尤其是板子上的程序已经没有源码的时候。这个操作只要几秒钟但价值极高。我自己养成了一个习惯给每块工作板在本地建一个目录按时间戳存 dump 文件出错时能立刻对比上次正常的是什么样。第二条心得把 J-Link 的固件更新提示看清楚再点。J-Link 会提示固件版本与软件不匹配需要升级。原厂设备升级一般没问题但一些非官方渠道的仿真器升级后可能无法识别这个风险是存在的升级前先确认手头设备来源是否可靠。如果你只有一块设备又不确定可以先在一台闲置电脑上验证不要在主工作机上贸然操作。第三条心得烧写速度不是越快越好。产线上追求节拍很多操作员喜欢把速度拉满。实测 4000kHz 对一个 64KB 固件的总耗时影响很小反而是速度过高导致的偶发连接失败会让单块板子的平均处理时间更长。我的经验是 1000kHz 是个甜点值连接稳定、速度够用。第四条心得学会看 J-Link 的连接日志。JFlash 下面的日志窗口和 Commander 的输出会告诉你具体在 CoreSight 的哪一步失败、读到的 ID 是什么、电压检测结果是多少。这些信息比报错本身有价值得多。我习惯把 JFlash 的日志自动保存到文件出现批量问题时翻一次日志就能判断是共性还是个别。第五条心得给烧写工位准备一份环境说明。写在纸上贴在工作台旁边内容就是J-Link 型号、软件版本、器件型号、接口速度、是否勾选 Connect under Reset、工程文件路径。看起来啰嗦但换人操作、或者隔了三个月自己再上手的时候这份说明能让你五分钟回到状态而不是重新试错半小时。最后分享一个我用了很久的小技巧把 J-Link Commander 的脚本和 JFlash 工程各准备一套。脚本用于快速验证和自动化工程文件用于给别人用和长期存档。两者用的底层引擎是同一套往往一个连得上另一个就连得上遇到疑难杂症时两边交叉验证能很快判断是工具配置问题还是板子硬件问题。我在实际使用中发现绝大多数J-Link 怎么又连不上的情况最后查出来都是那根十厘米的杜邦线、或者那个忘了挪回来的 BOOT0 跳线帽。