做嵌入式软件开发这关绕不过去代码写完了编译也通过了板子一上电灯不亮、串口没反应。你有再强的自信心也没用因为芯片根本没按你预期的跑。这时候你最需要的不是翻数据手册而是把烧录下载和仿真调试这套工具链彻底弄明白。烧录下载是把编译产物写进芯片Flash的那一步仿真调试是让芯片停下、跑起、把内部状态亮给你看的那套体系。这两个能力直接决定你的开发效率也决定你调试Bug时是瞎猜还是一招致命。这篇文章是我这些年折腾J-Link、ST-Link、OpenOCD、QEMU、各种ISP模式之后攒下来的经验总结适合两类人看一类是刚入门嵌入式开发、在怎么写进去、怎么跑起来上反复碰壁的新手另一类是准备嵌入式软件开发面试想把这几个基础议题系统梳理清楚的求职者。我会把选型逻辑、接线细节、IDE配置、命令行工具、经典故障排查一条龙讲完尽量不堆名词直接把能落地的做法给你。1. 先把底层的三件事说透烧录、下载、仿真调试各管什么1.1 烧录、下载、仿真调试不是一个意思很多初学者分不清这三个词觉得都是把程序弄进板子。实际区别挺大搞混了后面各种配置就会云里雾里。**烧录Programming**是把编译好的固件写入芯片的非易失存储介质对现代MCU来说就是Flash。它的核心动作是擦除、写入、校验。烧录完成后掉电不丢。你平时说的download固件烧程序刷机本质都是这个动作区别在于走什么通道调试器口、串口ISP、USB DFU还是网口后面会细讲。**下载Download**这个词在调试语境里稍微宽泛一点。调试器除了能写Flash还能往RAM里加载代码、读写寄存器和内存。KEIL里的Download按钮实际干的是把映像文件加载到目标存储并准备运行环境所以有时候你会看到RDI download和Flash download两种说法前者是下载到RAM调试后者才是真正烧Flash。仿真调试分两个层面。第一是仿真器层面用软件模拟CPU指令集和外设行为比如QEMU、Proteus虚构一个环境让你的代码在里面跑。第二是硬件调试器层面通过JTAG/SWD这类专用接口连到真实芯片上让它暂停、单步、任意读写内部寄存器。这两者在开发里的角色完全不同一个帮你快速验证逻辑一个帮你看清真机上的事故现场。1.2 一条完整的开发闭环长什么样说清楚了概念再看整体流程你就知道每个环节卡住会出什么问题。一个典型的嵌入式开发调试闭环是这样的写代码构建出.elf/.axf文件必要时转成.hex或.bin。通过IDE里的调试器插件或者命令行烧录工具把固件写入目标芯片Flash。启动调试会话复位运行、设置断点、单步执行、观察变量和寄存器。发现问题改代码重新构建再回到第2步。看起来很简单但坑全藏在细节里。比如第2步中如果Flash擦除算法选错会烧录失败如果忘了勾选Reset and Run烧录成功但程序并不跑。第3步里如果变量被编译器优化掉你看Watch窗口永远是optimized out如果开了看门狗断点一停狗就复位芯片整个会话乱套。不同场景下对这个闭环的要求也不一样我把常见情况捋了一下开发场景推荐工具核心关注点算法逻辑验证QEMU、Proteus快速、无需硬件驱动与外设联调J-Link、ST-Link IDE寄存器级观察、外设时序产线批量烧录脱机烧录器、命令行CLI速度、校验、防呆现场固件升级IAP Bootloader通信协议、签名鉴权后面所有内容都是围绕这张表展开的。不管你是做单片机裸机还是跑RTOS和Linux这套逻辑基本通用差别只在具体命令和引脚定义上。2. 烧录下载的选型逻辑接口、协议、硬件工具不能乱配2.1 先分清SWD、JTAG、ISP、Bootloader这几条路烧录通道看起来很多实际上就四大类理解了各自的物理基础选型就顺了。**SWDSerial Wire Debug**是ARM推的两线调试协议数据线SWDIO、时钟线SWCLK外加GND和参考电压就够干活了。特点是线少、速度快实际开发中跑到4~10MHz都有、占引脚少大部分ARM内核芯片的首选调试通道。你买一块STM32开发板板上那块小小的ST-Link走的就是SWD。JTAG是更老的通用标准至少需要TCK、TMS、TDI、TDO四根信号线。好处是通用性强FPGA、DSP、复杂SoC都能用还支持边界扫描能做板级测试。但线多、接线麻烦现在ARM芯片调试基本都被SWD取代了。很多开发板上的10pin调试座同时引出了SWD和JTAG信号就是为了兼容不同调试器。**ISPIn-System Programming**走的是芯片出厂时固化的ROM Bootloader。典型例子是STM32把BOOT0拉高、BOOT1拉低上电后芯片进入系统存储器这时通过USART1或其他指定接口接收固件并写入Flash。ESP32也类似把GPIO0拉低再复位就进入串口下载模式。它最大的价值是不需要调试器一根USB转串口线就能烧录救急和产线场景非常有用。**IAPIn-Application Programming**则是你自己写的Bootloader让程序能通过CAN、UART、USB或网络升级Flash。本质上就是程序自己烧自己现场设备的远程升级全指望它。我的选型建议很直接开发调试一律用SWD简单可靠手头没有调试器或者芯片被锁了走ISP救急要交付现场升级能力老实做IAP而且一定要做固件校验别只图快。2.2 硬件调试器怎么挑J-Link、ST-Link、CMSIS-DAP都得懂点市面上的调试器鱼龙混杂但底层协议就那么几套你只要分清下面三种就行。J-Link是SEGGER家的商业调试器优点是驱动成熟、速度快、支持的芯片厂牌极多Keil、IAR、GDB都能无缝接。如果你要在NXP、TI、瑞萨、ST这些厂牌之间横跳一个J-Link BASE就能省掉一堆适配烦恼。缺点是贵商用授权和仿真器特性要分版本预算有限的个人开发者可以先不用它。ST-Link是ST官方出的调试器STM32和STM8的标配。V2版本很便宜刷第三方固件还能当CMSIS-DAP用V2-1以上版本还带虚拟串口调试的同时直接看串口日志非常实用。如果你主要玩STM32ST-Link性价比极高没什么可犹豫的。CMSIS-DAP / DAP-Link是ARM开源的调试协议很多国产开发板板载的就是这类调试器比如GD32、APM32、国民技术这些。配合pyOCD、OpenOCD完全免费使用功能和稳定性在绝大多数场景下够用。我经常给预算敏感的项目推荐这个方案一颗几块钱的单片机自己做个DAP-Link代码开源、原理图公开办公室人手一个。选型我一般不迷信牌子而是看场景只想在一个系列芯片上做开发板载调试器就行要跨多厂牌J-Link省心要做自动化测试脚本OpenOCD配合任意SWD调试器都一样跑。2.3 上位机与命令行烧录工具的组合用法调试器硬件只是底层真正执行烧录动作的还是软件。图形界面工具适合人工操作命令行工具适合脚本化、自动化两边我都会用。地域化图形工具用得最多的就是STM32CubeProgrammer它支持SWD、串口ISP、USB DFU三条通道还能读写Option Bytes。产线和维修场景我常用它的CLI版本STM32_Programmer_CLI -c portSWD modeUR -p app.hex -v -rst这条命令的意思是用SWD连接UR表示Under Reset连不上的时候试它烧录app.hex校验-v然后复位运行-rst。如果是走串口ISP典型命令是stm32flash -w app.bin -v -g 0x08000000 /dev/ttyUSB0其中-w是写Flash-v是校验-g 0x08000000是烧录完直接跳到App起始地址运行。注意这里用的是.bin因为ISP方式通常按地址写裸二进制.hex里的地址信息有时候会喧宾夺主。USB DFU场景用dfu-utildfu-util -a 0 -D app.dfu -s 0x08000000:leave而OpenOCD是跨芯片、跨调试器的大杀器后面第6节我会给完整脚本。这里先记住它的核心用法openocd -f interface/stlink.cfg -f target/stm32f4x.cfg \ -c program app.hex verify reset exit一句话总结IDE里的图形烧录适合单机人工开发命令行工具适合批量、自动化、持续集成。实际项目里我通常两边都搭好开发用IDE回归测试用脚本。3. 仿真调试的边界能省时间但别指望它替你把关3.1 模拟器、仿真器、调试器三个词别混着叫这三个词在日常聊天里经常被混用但较真起来差别很大面试也爱问。**模拟器Simulator**是纯软件的比如QEMU它模拟的是CPU指令集和外设行为你的程序不需要真实芯片就能跑。它适合验证算法、状态机、协议栈逻辑。**仿真器Emulator**更接近替代真实硬件的实体设备早期ICEIn-Circuit Emulator就是插到目标芯片位置、代替CPU运行的东西价格昂贵。现在这个说法经常被拿来泛指能在线控制芯片的调试器但严格说J-Link不是仿真器它是调试器因为它只是通过调试口控制真实芯片并没有替代CPU。当然有些中文资料会把Proteus这类逻辑仿真也笼统叫仿真器你还得看语境。**调试器Debugger**是软硬件组合硬件部分是SWD/JTAG适配器软件部分是GDB、IDE里的Debug视图、OpenOCD这类GDB Server。它控制的是真实芯片能暂停CPU、读写寄存器、查看内存、设置断点。分清这三个词你才知道为什么QEMU跑通了程序上板却不跑因为模拟器永远给不了你真实的时序和电气行为。3.2 一套最省事的仿真环境配置如果你手头没有开发板或者只是想快速验证一段纯逻辑代码用QEMU搭一套Cortex-M仿真环境是最快的而且全免费。先装好ARM工具链比如arm-none-eabi-gcc然后写个最简单的main函数编译的时候加上-mcpucortex-m3 -mthumb -g -O0 -nostdlib链接脚本指向一个固定的RAM和Flash地址布局。编译出elf文件之后启动QEMUqemu-system-arm -machine netduino2 -nographic -kernel app.elf -gdb tcp::1234 -S-machine netduino2对应一块STM32F405板卡模型-gdb tcp::1234 -S表示启动时等待GDB连接并暂停在复位入口。另开一个终端连接GDBarm-none-eabi-gdb app.elf (gdb) target remote :1234 (gdb) load (gdb) break main (gdb) continue这样你就能在纯软件环境里单步、断点、查看变量了。VS Code的cortex-debug插件也支持直接配servertype: qemu图形界面下体验和连真机调试器几乎一样。如果不想本地装环境浏览器里的Wokwi也能模拟ESP32、Arduino这类平台教学演示方便。Proteus则是不少高校教材的选择能搭原理图、放单片机型、看波形适合课程设计但对复杂项目的仿真精度就不太够看了。3.3 仿真跑到飞起上板就翻车原因在这仿真环境最大的价值是快速反馈但我必须强调它的边界否则你会在错误方向上浪费大量时间。第一模拟器不模拟真实外设时序。ADC采样速度、PWM占空比抖动、DMA与CPU的总线竞争、中断响应延迟这些在QEMU里基本都是理想化的。你写一个电机驱动闭环算法在QEMU里PID调参调得再好上板依然可能振荡因为电流采样和PWM更新之间那个微妙的时间窗口仿真根本体会不到。第二编译器优化行为不完全一致。同一段代码arm-none-eabi-gcc在-O0和-O2下的行为差异仿真环境能暴露一部分但真实芯片上缓存、Flash等待周期、总线错误这类问题不会在模拟器里出现。第三电气问题永远模拟不了。电源噪声导致复位、引脚驱动能力不足、晶振起振失败、ESD打坏端口……这些只能靠示波器和真机调试器来查。所以我的习惯是仿真只用来跑逻辑正确性比如状态机迁移、帧解析、滤波算法这类与硬件弱相关的代码一旦涉及外设寄存器、中断、时序立刻转真机调试。仿真跑得再顺也不代表稳真机才是最终裁判。4. 硬件调试的实战链路从接线到断点命中4.1 SWD接线与电平匹配细节全在这很多朋友调试器连不上芯片第一反应是调试器坏了其实八成是接线或者电平问题。SWD虽然只有几根线但每根线都有讲究。标准SWD需要如下信号引脚作用注意事项SWDIO数据线双向别和SWCLK搞反SWCLK时钟线由调试器驱动GND共地不共地一切白搭VREF / Target VCC参考电压用于调试器判断目标电平不是供电RESET可选复位信号连接Under Reset时必需先说GND调试器和目标板必须共地否则信号根本没有参考基准表现就是时好时坏、偶尔能连上偶尔连不上。你换成示波器量SWDIO看到的信号全是乱的。再说VREF。有些调试器这个引脚不接也能工作因为芯片SWD引脚自身带3.3V电平但如果目标芯片是1.8V系统不少低功耗MCU和无线SoC就是这个电压调试器不知道目标电压输出3.3V逻辑就会超出芯片耐受轻则损坏重则整个调试口烧掉。正确做法是接上VREF线必要时加电平转换芯片比如TXS0108E这类双向电平转换器。最后说速度。SWD速度不是越快越好长杜邦线、高阻抗环境下把SWCLK拉到10MHz大概率连接不稳定。我的做法是先用1MHz验证线路稳定后再逐步拉高。如果怀疑信号完整性问题把速度压到400kHz往往就正常了。4.2 IDE里的调试配置逐项说明调试配置虽然各家IDE界面不同但核心选项就那么几项理解了之后换IDE只是找按钮的问题。以Keil MDK为例在Options for Target - Debug里选好调试器类型ST-Link或J-Link点Settings进去后必看三个地方Port选SW不要选JTAG除非你的板子只引出了JTAG。Max Clock调试器支持的SWD频率和IDE里显示的频率对应从1MHz起步最稳妥。Flash Download页签勾选Reset and Run这样烧录完成后芯片自动复位运行擦除选项选Erase Sectors比Erase Full Chip快得多量产时能省时间。STM32CubeIDE和VS Code的cortex-debug其实更透明因为配置是文本你能看到每个参数。下面是一个cortex-debug连接OpenOCD的配置示例{ type: cortex-debug, request: launch, servertype: openocd, device: STM32F103C8, interface: swd, executable: ${workspaceFolder}/build/app.elf, configFiles: [interface/stlink.cfg, target/stm32f1x.cfg], svdFile: ${workspaceFolder}/STM32F103xx.svd }注意svdFile这一项它就是片上外设寄存器的说明书配置之后你能在IDE里看到每个寄存器每一位的实时含义比对着数据手册猜值效率高一个量级。4.3 断点、Watch、内存窗口用起来才值钱把调试会话跑起来之后真正的功夫在于怎么用好断点和观察窗口。断点分硬件断点和软件断点。硬件断点是芯片调试单元直接实现的Cortex-M3/M4的FPB单元最多提供6个硬件断点所以Keil里你最多也就设6个Flash断点。为什么Flash上的代码只能用硬件断点因为软件断点的原理是把目标地址的指令临时替换成BKPT指令而Flash不能随意改写。如果你的代码在RAM里跑或者用仿真器软件断点数量就不受这个限制。变量被优化掉是我见过最多、也最容易误导新手的问题。编译开-O2之后Watch窗口里看不到变量是正常的因为它可能被优化到寄存器里、甚至被完全消除。调试时如果你确实要看这个变量两个办法一是临时用-O0编译二是给变量加volatile修饰。不过volatile是双刃剑别为了调试乱加否则会掩盖真实的优化问题。HardFault定位是嵌入式调试的必修课。程序进HardFault后先看栈回溯确认是从哪个函数跳进来的更可靠的做法是在HardFault_Handler里抓取返回地址LR和堆栈指针然后对照map文件锁定是哪一行。有些调试器会直接显示出错时的寄存器现场配合SVD文件甚至能看到具体是哪条总线上出问题。还有个坑必须提醒如果你代码里开了IWDG看门狗停在断点时不喂狗狗一复位芯片调试会话就乱了。调试阶段两个选择要么把IWDG临时关掉要么用STM32的DBGMCU_CR寄存器配置成内核暂停时冻结看门狗这也是生产代码里常见的调试配套手段。5. 烧录调试的经典翻车现场与完整排查链路5.1 提示No target connected我的一步步排查顺序这个错误几乎是每个嵌入式开发者的老朋友报错文本五花八门但本质都是调试器找不到芯片。我的排查顺序是固定的从不跳步供电万用表量目标板VCC和GND确认电压正常。见过太多人调试器插了一下午最后发现板子压根没上电。共地确认调试器GND和目标板GND之间有良好连接。杜邦线接触不良是重灾区。信号线检查SWDIO/SWCLK是否接反、插错很多排针座不标丝印最容易错在这里。复位状态目标芯片是不是被复位电路一直按在复位状态有些板子RESET引脚被外设拉低芯片永远起不来。参考电压VREF脚有没有接如果调试器支持独立供电模式确认它是否被错误地配置成了对外供电。读保护芯片之前是不是开过RDP读保护如果是用Under Reset连接方式再试。降低速度SWD速度压到最低比如400kHz避开长线和干扰。换板和换工具以上全查过还不行再怀疑芯片虚焊或调试器本身。注意这个顺序有讲究逻辑上要从最基本的电源往最复杂的芯片状态推进。我统计过自己遇到连不上的案例里一半以上是供电或者共地问题真正芯片坏掉的不到一成。你如果一开始就怀疑芯片很容易把简单的接触不良排查成复杂的电路问题。5.2 烧录成功但程序不跑先查这三处烧录过程看起来一切正常进度条走完但按复位后程序就是不跑。这个问题比连不上更让人窝火因为工具没报错说明通道是通的问题在芯片本身。第一个要查的是BOOT引脚。STM32的BOOT0如果被拉高上电后芯片进入ROM Bootloader而不是你的App表现就是烧录成功但程序不跑。用万用表量一下BOOT0电平或者看原理图上这个引脚是不是有上拉电阻。很多开发板原厂出厂时BOOT0通过跳线帽拨到了系统存储器模式你烧完App忘了拨回来就必然出现这个现象。第二个是IDE的Reset and Run开关。Keil和IAR默认都可以配置下载完成后的动作如果没勾选烧录完成后芯片还停在调试器的控制状态看起来就是没在运行。这时候你手动按一下复位键如果程序正常跑起来那么根因就是下载后的复位策略没配对而不是程序本身有问题。第三个是时钟配置。这是新手最容易忽略的坑你的程序里如果配置了PLL输入时钟源是外部晶振HSE而板子上根本没焊晶振或者晶振没起振那代码一跑就进HardFault。现象同样是程序没反应。排查办法很简单在调试器里复位看PC指针停在哪个地址再对照map文件判断是不是进了HardFault_Handler。另外说一句烧录后如果表现为能跑但几秒后自己复位多半是看门狗在捣乱跟不跑是两回事但排查思路类似先把外设初始化和看门狗喂狗逻辑检查一遍。5.3 芯片读保护锁死后的恢复办法芯片加密之后连不上调试器这个问题比前两个更吓人但恢复办法是有的前提是你在锁死之前没有开到最高等级。STM32的RDP读保护分两级。Level 1芯片可以用调试器连上但读不出Flash内容仿真也受限。解除办法是选择Remove Protection或者做一次全片擦除芯片会先擦掉全部内容再解除保护所以里面的固件数据会丢失但芯片本身还能用。Level 2永久保护任何调试接口都会失效只能换芯片。所以量产流程里的铁律是代码最终定版之前不要开RDP Level 2开了也要先备份固件。这个教训我是用真金白银买来的千万别犯。还有一种常见情况不是RDP而是代码里把SWD引脚复用成了GPIO导致上电瞬间调试器还没来得及接管程序就把SWD功能关了。这时候用Connect Under Reset连接方式让调试器在芯片复位期间完成挂接然后再去解除保护或者修改引脚配置。Keil里有这个选项STM32CubeProgrammer里的modeUR也是这个意思。OpenOCD下面的相关配置也差不多openocd -f interface/stlink.cfg -f target/stm32f4x.cfg \ -c reset_config srst_only -c init \ -c halt -c stm32f4x unlock 0注意unlock动作会触发全片擦除操作前确认你已经备份了该备份的东西。6. 进阶玩法与我个人的工作习惯6.1 OpenOCD脚本化让烧录进入流水线开发阶段用IDE烧录没问题但如果你想让固件构建、烧录、冒烟测试进入自动化流程命令行工具是必须的。OpenOCD在这方面几乎是万能钥匙支持大量调试器和目标芯片。我现在的一个标准回归脚本长这样#!/bin/bash set -e # 1. 构建固件 make clean make # 2. 通过OpenOCD烧录并校验 openocd -f interface/stlink.cfg -f target/stm32f4x.cfg \ -c init \ -c halt \ -c flash write_image erase build/app.hex \ -c verify_image build/app.hex \ -c reset run \ -c exit # 3. 串口冒烟测试等3秒检查启动日志 sleep 3 timeout 5 python3 serial_check.py | grep BOOT OKverify_image的意思是烧录完成后把Flash内容和文件比对防止静默写坏。这套脚本能直接怼进GitLab CI或者Jenkins每个MR合入前都自动烧一块测试板验证省下的人工时间比想象中多得多。如果你只需要bin格式别忘了arm-none-eabi-objcopy -O binary app.elf app.bin这条转换命令很多工具特别是有地址要求的烧录器只认bin。6.2 量产烧录和开发调试要分开两套方案这是我从很多制造项目里总结出来的血泪教训开发调试用的工具链直接拿到产线用一定会出事。开发阶段你用的是调试器IDE追求的是调试便利、断点、变量观察。但产线烧录讲究的是速度、一致性、可靠性、可追溯性。产线烧录一般这样做用脱机烧录器或一拖多载具烧录器里有预置固件插上板子按一下按钮就烧完不依赖电脑。烧录的同时写入唯一序列号或者读取芯片UID生成唯一身份标识方便售后追溯。设置好Option Bytes比如读保护等级、复位引脚功能、BOOT引脚默认状态。烧录后自动校验校验通过才允许进入下一道工序。命令行批量烧录的典型姿势STM32_Programmer_CLI -c portSWD -p firmware.hex -v \ -ob RDP0xAA SN0x00000001-ob写的是Option Bytes这里既设置了RDP读保护也写入了产品序列号。这一条命令做完固件进Flash、加密开好、身份信息落位一步到位。现场升级则是另一套逻辑走IAP Bootloader加应用自升级升级包必须有校验和签名。切记现场设备不要留调试口升级通道安全性和稳定性优先于一切便利性。6.3 面试里关于这类工具的高频考点顺带说几句既然文章开头提到了准备面试的事我顺手把真正的面试官爱问的问题整理一下。这些问题我面试别人时也问过确实能筛出背过资料和真干过活的差别。**SWD和JTAG有什么区别为什么现在主流都用SWD**答到线少、速度快、占用引脚少就合格能补一句JTAG还有边界扫描能力但嵌入式开发日常用不到就加分。**硬件断点和软件断点的区别Cortex-M3最多几个硬件断点**答到Flash代码只能硬件断点软件断点是替换BKPT指令是基础背出6个硬件断点FPB比较器就说明真看过手册。**芯片开了读保护连不上怎么办**这个问题非常考经验。能说出Level 1可以擦除后解除Level 2永久锁死已经不错再补上可以用Connect Under Reset抢救引脚复用造成的锁死基本就没什么可挑的了。**程序下载成功但没运行怎么排查**按照BOOT引脚、Reset and Run、时钟配置的顺序答就行能提到看门狗和外部晶振就更全。HardFault是怎么定位的看栈回溯、抓LR和堆栈指针、对照map文件是标准答案如果能说出用SVD文件看寄存器和外设状态会显得更有实战感。**ISP、IAP、SWD/JTAG三种烧录方式的区别**这是考察你是不是只会点IDE里那个按钮的经典题。答清楚ISP走ROM Bootloader、IAP是App内自更新、SWD/JTAG是调试器烧录再分别说出适用场景这题就稳了。最后说几个我自己的土办法文章写到这功能性的内容基本都覆盖了。最后分享几个我实际干活时离不开的小习惯不一定写在手册上但关键时刻很管用。我设计的所有自研板子不管多小的功能板都会预留一个标准SWD 10pin插针座并且丝印标清楚SWDIO、SWCLK、GND、VCC的顺序。这个习惯救过我无数次——项目中途要换MCU型号、要接逻辑分析仪、要连产线治具一个统一针序的调试座能把所有工具的适配成本降到最低。你永远不知道一块功能简单的板子后面会不会变成量产品。另一个习惯是调试阶段我会用串口打印做决策面的日志进入某个状态机、收到某帧数据、喂狗成功都留一行精简日志。原因是调试器断点会改变程序时序很多问题在断点观察下根本不复现而串口日志不打扰运行。我用J-Link配合SWOSerial Wire Output也能做无损日志但普通串口更通用。真到了数据量很大的时候再用逻辑分析仪抓总线。最后如果你刚接触这个领域我强烈建议你找一块便宜的STM32F103开发板强迫自己用命令行烧录一次、用GDB设一次断点、用OpenOCD读一次Flash内容。这个过程不需要IDE你会对程序到底怎么进去的有根深的理解。很多时候我们觉得烧录调试工具复杂不是因为东西难而是因为平时被IDE藏得太好没机会看清底层而已。把这层窗户纸捅破后面所有调试手段都只是参数问题。