1. Jlink到底是什么：烧录、仿真、调试一个不落

做嵌入式开发，尤其是单片机这一行，绕不开两件事：一是把代码写出来，二是把代码跑起来。而“把代码跑起来”之前的最后一公里，就是烧录。烧录这个词听起来有点古老，但本质就是把编译好的固件文件（一般是hex或bin）通过某种方式写进芯片的Flash里。早期玩51单片机，大家用串口下载线、USB转TTL，后来玩STM32，更多人开始接触Jlink。

Jlink是德国Segger公司出的一套调试烧录工具，它最核心的价值就俩字：连接。通过JTAG或SWD协议，把电脑上的开发环境（比如Keil、IAR）和芯片内部打通，让你能把程序烧进去，能单步调试看变量，还能在运行时读取寄存器。说人话就是：没有Jlink，你可能只能把程序“扔”进芯片里跑，结果对不对全靠猜；有了Jlink，你能扒开芯片的“脑壳”，看它执行到哪一步、卡在哪个循环、变量变成多少。

这篇博文适合谁？如果你正在用Keil5配合STM32写程序，烧录时总报错；或者你连SWD接口线都不会接，搞不清SWDIO和SWCLK有什么区别；或者你手头有一个Jlink但不知道怎么更新驱动、怎么和Keil版本匹配——那这篇文章就是给你写的。哪怕你是刚接触单片机的学生，我也尽量不堆术语，争取让你照着操作就能把程序烧进去。

先说一个很多人都会误解的点：Jlink不只是“下载器”。它还有一个很重要的功能是仿真调试。所谓仿真，就是让CPU停下来看你程序的执行状态，比如设置断点、单步运行、查看全局变量。没有调试器的开发者，写代码就像蒙着眼睛走路；有了调试器，你至少能拿根棍子在前头探路。所以这类工具的全称叫“烧录仿真工具”，而不是简单的“烧录器”。

1.1 JTAG和SWD：Jlink支持的两种连接协议

Jlink通过两种协议和目标芯片通信：JTAG和SWD。

JTAG是古早的老人了，历史很长，占用引脚多——一般需要TMS、TCK、TDI、TDO四根信号线，再加上电源和地就是六根。好处是通用性强，很多芯片、CPLD、FPGA都认它，还能支持链式多设备。坏处是引脚紧张时你很想骂人，因为有些MCU本身引脚就少，你再占四根做调试，功能模块都快没地方接了。

SWD（Serial Wire Debug）是ARM自家推的轻量级调试接口，只需要两根线：SWDIO（数据）和SWCLK（时钟），再加一个GND就能工作。这就非常香了，省引脚、接线简单、速度也不慢。STM32全系列基本都支持SWD，所以现在玩ARM芯片，绝大多数人都是走SWD。

这里要说明一下，很多第三方兼容Jlink的把SWDIO标成DIO，SWCLK标成CLK，甚至还有标成DATA和CLOCK的，接线时要认准芯片那一侧的引脚定义，别被丝印带偏了。

1.2 Jlink能干的活比你想象的多

很多人以为Jlink就是烧程序用，其实它的功能拆开来看可以列一长串：

• Flash烧录：把hex、bin、mot等格式的固件写入芯片内部Flash或外部SPI Flash
• 在线调试：配合IDE实现断点、单步、查看变量、反汇编等调试手段
• RTT（Real Time Transfer）：一种轻量级日志输出方式，用SWD接口就能把printf重定向到电脑，不占用串口
• 虚拟串口：部分Jlink型号（比如J-Link PLUS）支持将调试接口虚拟成一个COM口，省掉USB转TTL
• JFlash独立烧录：不开IDE，直接用Segger的JFlash软件批量烧录固件，产线用得非常多
• 命令行烧录：通过JLink.exe脚本方式，实现自动化烧录，适合集成到生产测试流程里

不过要注意，不同的Jlink版本、不同的授权等级，功能会有差异。很多便宜的“兼容版”阉割掉了RTT甚至虚拟串口，或者固件升级后就“变砖”。买之前要先想清楚自己是只烧录还是也要调试，如果只是烧录，几十块的ST-Link其实也够用；但如果做正经开发调试，一个正版Jlink的价值还是体现在稳定和功能完整上。

2. 驱动安装与版本匹配：最容易翻车的第一关

很多人拿到Jlink后做的第一件事是插上USB，然后就傻眼了——电脑提示“无法识别的USB设备”，或者设备管理器里出现一个黄色感叹号。别急着退货，先看看驱动装了没有。

Jlink的驱动不像普通USB转串口那样Windows自带，必须从Segger官网下载。我去官网的次数很多，路径是segger.com，找到“Downloads”页面，在里面挑对应操作系统的J-Link Software Pack。这个安装包不是单纯的驱动，它里面包含了USB驱动、JLink Commander、JFlash、RTT Viewer、GDB Server等一系列工具。

2.1 Jlink驱动安装完整步骤

驱动安装其实没什么技术含量，但有几个小细节容易出问题。我给一个我自己反复用过的流程：

第一步：去Segger官网下载最新的J-Link Software Pack，文件名类似“JLink_Windows_V796e.exe”，这个数字越大，版本越新。如果公司网络访问外网费劲，国内一些半导体厂商的论坛、博客也会放历史版本，但尽量用官方版本，避免安全风险。

第二步：安装时尽量用默认路径，不要改盘符改目录。因为后续Keil、IAR会按默认安装路径去找Jlink的动态库“JLinkARM.dll”，你装到奇奇怪怪的位置，后面IDE找不到就得手动复制DLL，很麻烦。

第三步：插上Jlink，电脑会提示安装驱动。如果没自动弹出来，到设备管理器里找到带感叹号的设备，右键更新驱动，手动指向刚才安装目录下的驱动文件夹。其实新版Segger安装包会自动把驱动注册好，但有时候Windows的驱动签名策略会拦住它，这时候可以试试：设备管理器里卸载设备，勾选“删除驱动程序软件”，然后重新插拔。

安装完成后，怎么确认驱动正常？打开设备管理器，能看到一个“J-Link”相关的设备，名称通常带版本号，比如“J-Link V10”之类。更稳妥的做法是打开Segger安装目录里的“JLink.exe”，也就是JLink Commander，它会显示连接的Jlink型号、固件版本、支持的接口等。如果这里能正常显示，说明驱动和硬件都OK。

2.2 版本匹配问题：jlink v5.10h device selection报错

很多人烧录失败不是硬件问题，而是驱动装好了、Keil却报一个莫名其妙的错。最常见的一句话长这样：

“Error: J-Link V5.10h device selection is not supported in this version of Keil”

这个报错的含义是：你的Keil版本太老，它内置的Jlink ARM DLL版本跟不上你这颗Jlink固件版本。Keil软件并不能“直接用”Jlink，它是通过一个叫JLinkARM.dll的中间动态库来和Jlink硬件通信的。Keil自带了一个JLinkARM.dll，但版本往往是它发布时固定好的旧版。而新买的Jlink固件比较新，接口协议变了，旧DLL就没办法匹配。

解决办法有两个方向。

方向一：更新Keil的DLL。可以去Segger官网下载“J-Link DLL Updater”，安装后它会自动把新版JLinkARM.dll替换掉Keil安装目录下的旧版。这里有一个安全提示：替换前先备份原来的DLL文件，万一新版DLL有兼容性问题还能换回去。

方向二：直接用Segger自带的DLL文件覆盖到Keil目录下。安装完J-Link Software Pack后，在安装目录里能找到JLinkARM.dll，把它复制到Keil的ARM目录（一般是Keil_v5/ARM/Segger），覆盖同名文件。我实测下来这种做法比Updater更直观，毕竟DLL文件就在面前，心里踏实。

但要注意，覆盖DLL之后，Keil里的Jlink型号列表和旧硬件之间也可能出现兼容性问题。比如老版Jlink V8，新版DLL已经不再支持它的固件升级了，用V8的朋友只能匹配旧版DLL。这块确实是历史遗留的大坑，如果碰到了，我建议老老实实按自己的Jlink硬件型号去找匹配版本的驱动和DLL，别一味的追求最新。

2.3 固件升级与“克隆版锁死”的坑

Jlink有个特性：连接电脑后可以升级固件。Segger官方会不定期更新固件，修复bug、增加对新芯片的支持。正版Jlink升级固件没有任何顾虑，但很多淘宝几十块买的“兼容Jlink”用的是反向破解方案，升级固件后极容易变成“假砖”——表现为插上电脑灯不亮、设备管理器不识别、Keil也不认。

我的建议是：如果你用的是兼容版Jlink，绝对不要点击固件升级。无论是Keil弹出来的升级提示，还是JLink Commander里出现的“Update Firmware”，一律点No或者Cancel。顺手把安装目录下的“J-Link”相关设置里自动更新检查也关掉，免得哪天手滑点了Yes，第二天就开始怀疑人生。

这里也说一句掏心窝的话：兼容版Jlink用于学习、个人DIY项目，完全够用，我最早也是这么入门的。但如果你要量产、做产品测试，哪怕买一个入门级正版Jlink EDU版本，都比顶着兼容版的随机性风险强。因为产线烧录最怕的就是工具突然罢工，一停就是整条线的工时损失。

3. SWD接口定义与接线：连线正确比什么都重要

烧录失败的原因里，至少有三分之一根本不是软件问题，而是接线错了。Jlink的接口看起来就几根线，但搞错一根，轻则连不上，重则烧坏芯片。所以我在这一节把SWD接口的定义掰开了讲透。

3.1 标准SWD引脚定义与Jlink引脚对应

Segger Jlink的引脚定义遵循一个常见的20Pin标准接口（也有10Pin、9Pin等变体），但我们用SWD时实际上只需要关注几个关键引脚：

这里特别强调VTref这一脚。Jlink会通过VTref来判断目标板有没有上电、参考电平是多少。很多Jlink接口上这一脚接到了3.3V，如果你的目标板是5V供电，那么这一脚应该接5V；如果目标板是3.3V，就接3.3V。有些兼容版Jlink干脆不管这一脚，只接GND也能用，但我不建议省掉，因为Vtref是Jlink内部电平判断的重要依据。

常见的接线组合就是四根线：SWDIO、SWCLK、GND、VTref。只要能把这四个对应对了，90%的板子都能连上。有些板子设计得很省事，直接把SWD接口做成4Pin排针，只引出SWDIO、SWCLK、GND、3.3V，那就不需要外部供电了，直接用Jlink的供电能力。

3.2 目标板供电方式与Jlink的“参考电压”逻辑

接SWD线之前先搞清楚一个问题：目标板是不是独立供电？

如果目标板已经通过USB、电源适配器、调试接口等方式单独供电，那么Jlink只需要接SWDIO、SWCLK、GND，外加VTref引到板子的主电源轨。这时候VTref的作用就是告诉Jlink“板子现在是3.3V，你的IO电平应该匹配3.3V”。

如果目标板没有独立供电，想靠Jlink供电，那就得额外接一根线：从Jlink的VTref/VCC引脚引到目标板的电源引脚。不过我要提醒一句：Jlink USB口的供电能力很弱，电流顶多几百毫安，带动一片STM32空载跑没问题，但如果你的板子上有其他外设、传感器、灯珠，很容易电压被拉垮，导致芯片复位、烧录中途失败。保险的做法是：目标板尽量独立供电，Jlink只作为调试工具，不承担供电任务。

还有一个很容易被忽视的细节：如果你同时接了Jlink供电和目标板USB供电，两者电压有细微差（比如Jlink出3.3V，USB出3.29V），可能导致电源从Jlink倒灌到USB口，轻则电压跌落，重则烧毁USB口。所以接线前建议用万用表量一下电压，两个源的压差别超过0.1V。

3.3 用杜邦线连接时出现的诡异故障

初学者喜欢用杜邦线连接Jlink和目标板，因为方便快捷。但杜邦线的质量参差不齐，有几种典型故障我碰到过很多次：

接触不良。杜邦线插在排针上看起来紧了，实际虚接。特别是SWCLK线松了，会表现为“有时能识别，有时不能”。排查方法很简单：用手轻轻拽一拽每根线，看设备管理器或者JLink Commander里的连接状态是否变化。

线序搞反。有些板子的SWD接口丝印印得不清不楚，或者根本没有丝印，就很容易把SWDIO和SWCLK接反。一旦接反，Jlink会报告“Cannot connect to target”或者卡在初始化阶段。识别方法：仔细看板子原理图、用户手册或者PCB背面丝印，不要靠猜。

线太长导致信号变形。SWCLK是一个高频时钟信号，杜邦线如果拉到15厘米以上，信号完整性问题就开始显现。表现为：频率调低能连上，调高就连不上；或者烧录到一半失败。我自己调试时习惯把杜邦线控制在10厘米以内，能短则短。如果你必须把线拉长（比如夹具离得远），那就把SWCLK速率在Keil里调低。

4. Keil5结合Jlink烧录：从配置到下载全流程

Jlink的使用场景里，Keil5是最常见的搭档。尤其是STM32开发，Keil+Jlink的组合几乎成了教科书级搭配。这一节我讲完整烧录流程，从工程配置到下板子，一步不落。

4.1 Keil5的Debug设置与Utilities设置

Keil5里和烧录相关的设置散落在两处：Options for Target的“Debug”选项卡和“Utilities”选项卡。

先看Debug选项卡：

• 右上角选择“Use”，下拉框里选“J-LINK/J-LINK TRACE”
• 如果下拉框里是灰色的或者找不到，多半是DLL版本问题，回去看第2节
• 点旁边的“Settings”，弹出Jlink调试设置窗口
• 在“Debug”页里，能看到连接的Jlink设备信息、接口类型（SW或JTAG）、最大时钟等

这里我要多说一句：Debug选项卡里的“Download to Flash”选项要勾选。否则Keil只调试不烧录，程序下载后断电就没了。它的勾选框就在Settings窗口的下方或者Debug页的“Download Options”里，具体位置跟Keil版本有关，找一下就能看到。

再看Utilities选项卡：

• 同样选“Use”，下拉框选“J-LINK/J-LINK TRACE”
• 点“Settings”，有一个“Flash Download”按钮，点进去是烧录算法选择界面
• 这里要添加对应芯片的烧录算法，比如STM32F103C8T6对应的是“STM32F10x Flash”算法

很多人把Debug和Utilities搞混，以为只设置了Debug就行。其实如果你用的是“LOAD”按钮下载，Keil会先通过Debug配置去连接调试器，再通过Utilities配置去执行Flash擦除和编程。两个设置都正确，才能保证下载顺畅。

4.2 Flash Download里的关键参数：烧录算法、擦除方式

Utilities设置里的“Flash Download”窗口是烧录的核心，里面有几个选项值得掰扯：

Programming Algorithm（烧录算法）：这其实是Keil用来操作芯片内部Flash的一段小程序。不同芯片Flash操作逻辑不一样，所以必须选对。选错了典型报错是“No Algorithm found for address range”或者说“Flash Download failed - Could not load file ‘xxx.FLM’”。解决办法就是打开这个下拉框，选对芯片型号对应的FLM文件。

Erase Full Chip vs Erase Sectors：一个是整片擦除，一个是按扇区擦除。量产或调试初期，选Erase Full Chip最省心，虽然时间长一点，但能避免“上次烧的程序残留占用空间导致这次写入失败”的问题。日常调试追求快，选Erase Sectors，只擦会写入的扇区。我建议每次大版本更新时用Full Chip，平时小改动用Sectors。

Programming vs Verify：Program就是写入，Verify就是写完后再读出来检查一遍。这个一定要勾选Verify，因为调试时最怕“烧进去了但实际数据不对”，后面运行异常时你都不知道是代码问题还是烧录问题。多花几秒钟的校验时间，能省几个小时的排查时间。

4.3 烧录过程全解：擦除—编程—校验“三步曲”

当你点下Keil里的“LOAD”按钮后，实际发生的事比你想的要多得多：

首先是复位并停止CPU。Jlink通过SWD接口把一个复位信号给到芯片，让它停在执行任何程序之前的初始状态，防止芯片上正在跑的程序干扰Flash的操作。

然后是擦除Flash。Keil调用你选择的烧录算法，把芯片内部Flash里旧内容清空。这一步如果是在片子上已经跑着程序的情况下进行，最好不要断电，否则容易出现“只擦了一半”的尴尬局面，重启后芯片变成半砖或全砖。

接着是写入固件。把编译好的hex文件数据按照地址逐块写入Flash。Jlink会通过SWCLK时钟逐位移入数据，芯片内部的Flash控制器负责真正的编程动作。写入速度取决于SWCLK的时钟频率以及Flash编程算法本身。

最后是校验。固件写完，Jlink将Flash里的数据重新读一遍，和电脑里的目标文件进行比较。如果全部一致，Keil会显示“Application running”之类的内容，同时自动复位并运行目标程序。

整个流程通常在几秒钟内完成。如果中途报错，绝大多数卡在“擦除”或“写入”环节，这时候不用慌，按第5章的排查顺序走就行。

4.4 Keil5烧录失败典型报错一览

把我在社区和实际项目中见到的高频报错整理成一个速查表：

碰到这些报错，我的经验是：先看接线，再看供电，最后才怀疑软件。因为软件问题往往有更明确的报错文本，电脑硬件或接线问题反而容易伪装成各种“Error”。

5. SWD不识别与连接失败：实战排查思路

这一节是给“卡在连接阶段”的朋友准备的。你程序写得好好的，编译也通过了，结果点下载，Jlink提示连不上目标芯片，这时候最容易让人抓狂。我按实战顺序给你列一套排查套路。

5.1 SWD不识别的最常见原因与排查顺序

先说你最该怀疑的三件事：

一、目标板没电。这是新手第一坑。Jlink接上了，电脑也识别Jlink了，但目标板根本没上电，VTref检测不到电压，自然连不上芯片。排查：万用表量目标板电源引脚有没有达到期望电压。如果目标板靠USB供电，确认USB线是真的通电了，有些USB线只能传数据不能供电。

二、SWDIO和SWCLK接反。我上面说过，这是第二高频问题。接反的典型表现：Jlink能识别自身，但初始化SWD时序后无法收到芯片的IDCODE。注意，STM32芯片如果有正常工作，SWD接口在复位释放后会返回一个IDCODE（比如0x1BA01477，不同型号有差异）。如果读不到IDCODE，大概率就是线序错了。

三、芯片被读保护或锁死。STM32如果之前被写入过读保护（RDP级别1甚至级别2），SWD接口会被禁止。级别1还能通过整片擦除解除，级别2基本就是永久锁死，只能换芯片。这种场景多发生在调试时误写选项字节，或者芯片程序里故意开了RDP。排查方式：用ST-Link Utility或者JLink Commander尝试连接，看是否报“target is secured”“RDP level”之类。

如果以上三个都没问题，再往下走：

降低SWCLK频率。重点是：Jlink默认SWCLK速率可能太高，连接到某些板上会因为干扰连不上。在Keil的Settings里，把Max Clock从默认的几MHz降到100kHz左右再试。我遇到过一个极端案例：一块电磁环境很差的板子，用4MHz怎么也连不上，降到100kHz秒连。频率低了只是慢，不是不能用。

检查RESET引脚。SWD协议本身不需要RESET引脚就能连接，但当芯片处于低功耗模式或者SWDIO意外被复用为GPIO时，外部拉低RESET并初始化连接，再释放RESET，是一种经典的“救砖”手法。有些Jlink接口支持硬件RESET控制，但很多情况下软件控制不了，需要手动把RESET引脚拉低再上拉。

5.2 一个真实案例：S32K148擦除0x400区域后连接不上

这个案例是我在一次汽车电子相关的调试中遇到的。有一块NXP S32K148的板子，本意是擦除某个Bootloader区域（地址0x400附近）再烧新程序，结果操作完，Jlink彻底连不上了。

原因分析：S32K148内部的Flash控制器有自己的保护机制，如果错误地擦除了包含Flash配置或启动代码的区域，芯片复位后可能无法进入正常的SWD调试模式，或者Flash控制器进入一种“不可忙”状态。Jlink连接时，会尝试读取芯片的Flash配置，结果读到的是一堆垃圾，初始化就卡死了。

当时的解决思路：在Jlink Commander里执行“unlock Kinetis”命令，也就是通过SWD调试口对芯片做整片擦除。对于NXP的Kinetis系列，这个方法非常常用，命令格式是：

unlock Kinetis

执行完再尝试连接，就能识别到芯片了。需要说明的是，这个命令会清空整片Flash，你的程序全没了，但芯片能活过来。

这个案例给我们的教训是：不要随便擦除低地址区域的Flash。有些同学在调试Bootloader或Flash算法时，会手动用JFlash勾选地址范围擦除，一个手误刚好把启动代码、向量表或Flash配置字删了，很容易遇到“芯片变砖”的假象。实际上，大部分情况下不是硬件坏了，而是Flash内容损坏导致调试口无法正常握手。

5.3 SWD引脚被复用：怎么救回“装死”的芯片

还有一种高频事故：程序里把SWD引脚（PA13/PA14）配置成了普通GPIO，下载完新程序后，调试口就废了。Keil再想连接，自然会失败，因为芯片跑着自己的程序，把连接调试器的“门”给关了。

遇到这种情况，有几种自救手段：

方法一：按住复位键，点下载，在芯片刚复位还没跑新程序时快速释放Reset。 操作细节是：先按住目标板Reset键不放，点Keil的LOAD，进度条刚开始，马上松开Reset。有的板子设计得不好，这个窗口期很短，得多试几次。原理是芯片复位后默认引脚是SWD功能，只要在它跑飞之前让Jlink连上，就能趁早把它停住。

方法二：把Boot0引脚拉高，强制从系统存储区启动。STM32的Boot0=1时，芯片启动时跑的是内置Bootloader，而不是Flash里的应用程序，这样SWD引脚就不会被用户程序占用。Jlink就能正常连上，接着把Flash全片擦除，再恢复Boot0为0，重新烧录正常程序。

方法三：用JLink Commander加“halt”命令。如果你的Jlink支持硬件复位，在命令行里执行：

connect halt erase

原理其实和方法一一样，都是在复位后立刻停止CPU执行用户程序，然后执行擦除。

这三种方法能救回绝大多数“看起来死了”的芯片。如果都不行，再考虑用ST-Link或者其它调试器交叉验证，排除Jlink自身故障。

5.4 烧录过程中的异常断电：教训与应对

我在群里见过太多因为烧录中途拔线、断电导致的“砖机”案例。给大家一个非常朴素的提醒：烧录过程不要断电，不要拔USB线，不要碰目标板电源。

为什么烧录中途断电危害大？因为Flash编程是“先擦后写”，擦除操作是把大量块位从1翻成0。如果擦除到一半断电，这部分Flash处于“空”的状态，虽然没有数据，但设备上电后没有有效程序，表现就是一片空白。更糟的是，如果芯片的Flash配置或加密位正好在这一段，恢复的难度会陡增。

应对异常断电的办法，说起来就一条：养成先备份再烧录的习惯。在JFlash里，有一个“Backup”功能，可以先读出芯片现有Flash内容存成bin/hex文件。这样哪怕烧录失败、固件丢了，你还能把备份内容烧回去，至少恢复到“烧录前”的状态。备份文件虽然占不了多少空间，但关键时刻能救命。

6. 进阶玩法与扩展：Jlink不只是Keil的配角

讲完基础用法，再聊几个Jlink常见的进阶玩法。这些内容未必每个人都会用到，但知道了以后，遇到产线烧录、批量生产、自动化测试这些场景时，你会有更多工具可用。

6.1 JFlash独立烧录固件

Jlink本身配套的JFlash软件，是专门用于独立烧录的工具。它的好处是不需要打开IDE，直接加载hex/bin文件，点击Program就烧。产线上常用的流程是：

1. 打开JFlash，创建一个Project，选择目标芯片型号
2. 通过“Data File”加载固件文件
3. 连接Jlink，确认芯片已识别
4. 点“Program Device”

JFlash里的一个重要概念是“Project”。它会记住你选了哪颗芯片、用什么接口、加载过哪个固件，下次打开直接调用。产线换不同板子时，切换Project就能换对应的固件和配置，比每次从头设置强得多。

需要注意的一点是，JFlash执行Production Programming时，默认会执行“整片擦除 → 编程 → 校验”，安全但速度慢。如果你的产线追求效率，可以把擦除方式改成“按需擦除”，或者把校验关掉——但我个人强烈不建议关校验，烧录错误是产品质量红线，校验不过就是在帮产线排雷。

6.2 用JLink命令行实现自动化烧录

除了图形界面，Jlink还提供了命令行工具JLink.exe，可以在脚本里实现全自动烧录。我在这里给一个简单的示例脚本：

device STM32F103C8 si SWD speed 4000 connect loadfile firmware.hex r g exit

这段命令的意思是：指定芯片型号为STM32F103C8，使用SWD接口，速度4MHz；然后连接芯片，加载firmware.hex，复位运行，退出。在Windows命令行里执行：

JLink.exe -CommanderScript flash.jlink

自动化脚本最适合的应用场景是产线批量烧录，或者CI测试流程里在编译完成后自动烧录到测试板。配合Python脚本还可以做更复杂的控制和结果解析。对个人玩家来说，它的意义在于“可重复”：你写了一个烧录脚本，以后每次烧同样的固件，不用打开IDE，双击一下就好。

6.3 RTT调试：最轻量的日志输出方案

最后聊一个很多人在用了之后真心回不去的小功能：RTT（Real Time Transfer）。它的原理很简单——通过SWD接口，在芯片内存里开一块缓冲区域，微控制器往这块缓冲写日志，Jlink实时把内容显示到电脑的RTT Viewer上。因为不走串口，所以不占用UART，速度还比串口快得多。

使用方式很直接：在工程代码里包含Segger官方提供的RTT源码文件（在Jlink安装目录的Samples/RTT里），然后直接用SEGGER_RTT_printf()代替printf()，打开RTT Viewer选择对应的Jlink设备，连接后就能实时看到输出。

我自己在调试一些时序敏感的代码时，特别喜欢用它，因为串口在波特率低的时候会拖慢程序执行，RTT基本做到零开销。有些实时性要求极高的场景，串口printf甚至会导致程序跑飞，RTT则几乎没有这种问题。

不过要注意，RTT需要芯片能正常跑起来才能用，如果芯片根本连不上SWD，RTT自然也起不了作用。所以RTT更适合代替“串口打印”，而不是代替“调试器”。

最后说一点个人感受。很多人第一次接触Jlink时，觉得它就是一根数据线、一个小盒子，没什么技术含量。但真的把这根线用明白——知道它为什么能烧录、为什么有时连不上、怎么救砖、怎么自动化——之后，你对嵌入式开发从“代码写好就完事”到“调试、烧录、量产全链路掌控”的理解，会上一个台阶。别小看这个不起眼的调试工具，它反而可能是你把嵌入式做扎实的重要一课。