企业官网建设流程全解析

芯片烧录这件事，做嵌入式的人几乎天天碰，但真被问一句“ISP、ICP、IAP到底啥区别”，很多写了好几年代码的人也会一时语塞。这三个缩写看起来像孪生兄弟，实际背后的工作机制、适用场景、踩坑方式完全不同。这篇文章想用最直白的大白话，把芯片烧录的原理、三种主流方式的本质区别、以及各自的实际玩法一次讲清楚。不管你是刚入行的学生、转行过来的工程师，还是想给产品规划固件升级方案的产品经理，看完应该都能对“程序是怎么进到芯片里的”“升级失败时到底卡在哪一步”有个清晰的认识。

1. 芯片烧录到底是什么：从一片空白到跑起程序

1.1 烧录的本质：往存储介质里写固件

芯片烧录，通俗讲就是把编译好的二进制程序文件（固件）写入芯片内部的存储介质中。常见的存储介质包括Flash、EEPROM等非易失性存储器。非易失性意味着掉电之后数据不会丢失，这样单片机下次上电才能直接从里面把程序读出来运行。

这里有个新手常犯的概念误区：很多人以为烧录就是“把代码复制进芯片”，实际上更准确的描述是“按照芯片的写入时序，把二进制数据逐字节或逐页地编程进Flash存储单元”。Flash编程和普通内存写入不一样，它通常必须先擦除（将存储单元置为1），再编程（将需要写0的位写0），所以烧录过程中“擦除—写入—校验”是三个固定动作。这也是为什么某些量产烧录工具看起来很慢，因为它在校验阶段会老老实实把每个字节读回来比对，而不是写完就走。

1.2 烧录、下载、调试这三个词的关系

在实际工作中，“烧录”“下载”“调试”经常被混着用，但严格来说它们不是一回事。烧录和下载都是往芯片里写程序，但烧录往往强调“把固件固化到非易失存储里这个完整过程”，下载则偏向于“通过调试器把程序加载到目标设备”这个动作。调试则更特殊，它需要在下载的基础上额外建立一套调试通信通道，让开发主机能够读取芯片内部寄存器、变量值，设置断点，单步执行。

很多新手拿到一块开发板，用Keil点了一下Download按钮，看到进度条走完就以为完成了。实际上调试器默认的Download动作往往只写了程序，并没有把调试所需的调试寄存器完全配置好。如果后面要挂上调试器做断点调试，还需要额外配置调试接口的初始化脚本，否则就会出现“程序跑起来了但Debugger连不上”的尴尬局面。这三种能力的区分，后面讲ICP时会再展开。

1.3 为什么会有这么多种烧录方式

这也是一个值得想明白的问题。早期单片机大多使用专用编程器，把芯片从电路板上取下来，放到一个独立的座子里烧录。这在小批量时代还能接受，但到了批量生产阶段，从“把芯片焊上板子”变成“先烧录再焊接”，不仅流程割裂，还容易在搬运、插拔过程中损伤引脚。于是工程师们开始想：能不能让芯片待在电路板上就能完成编程？

这就催生了ISP和ICP两种“在线编程”方案，它们的共同点是“不用拆芯片，通过特定接口直接从外部把程序写进目标芯片”。再后来，物联网设备大量铺开，设备装到用户家里、装在野外基站上之后，总不能为了升级一个固件把设备拆回来。于是IAP这种“让程序自己更新自己”的方案就成了必选项。所以这三种方式本质上对应了三种需求：开发调试需求、生产烧录需求、现场升级需求。

2. ISP / ICP / IAP 一张表看懂本质区别

2.1 一句话记住三者的核心差异

先给一个最粗暴但有效的记忆方法：ISP靠芯片出厂固化的引导程序来下载外部程序，ICP靠外部调试器直接访问芯片内部总线来编程，IAP靠用户自己写的应用程序去更新Flash里的程序。从“写程序的主体”这个维度看：ISP是“出厂自带的小管家帮忙装”，ICP是“外人直接进仓库搬货”，IAP是“仓库里的老员工自己换货架上的货”。

这个类比虽然粗糙，但能帮新手快速定位三者的边界。ISP需要芯片出厂时预留了一段引导代码（BootROM），ICP需要芯片设计时开放了调试访问接口（JTAG/SWD），IAP则需要用户自己编写并预先烧录一段引导程序（Bootloader）。它们的启动条件、占用资源、应用场景都截然不同。

2.2 三种方式工作机制对比

• ISP（In-System Programming，在系统编程）：芯片上电后，执行固化在ROM里的引导程序，引导程序通过UART、SPI、I2C、USB等接口接收来自主机的固件数据，然后调用芯片内部的Flash编程算法，将数据写入应用区。整个过程不需要外部调试器，只要一根数据线就能完成。
• ICP（In-Circuit Programming，在电路编程）：通过JTAG或SWD接口，外部调试器直接控制芯片内核，让内核执行一系列Flash擦写指令来编程。它不依赖芯片出厂引导程序，因为调试器可以直接访问芯片的调试端口，强制内核运行。这也是它最强大、最通用的原因。
• IAP（In-Application Programming，在应用编程）：用户在应用层自己实现Flash擦写逻辑。芯片先运行Bootloader，Bootloader通过通信接口接收新固件，写入Flash中的应用分区，然后跳转到新程序运行。真正的亮点在于，更新时应用软件本身就参与其中，甚至可以只更新部分代码段。

2.3 别被同名术语带偏

在下文深入讲解前，必须先提醒一点：在嵌入式圈子里，“ISP”这个词还有另一层完全不同的含义——Image Signal Processor，图像信号处理器。手机相机、安防摄像头、车载摄像头里都有一个ISP图像处理单元，负责去噪、色彩校正、3A（自动曝光、自动白平衡、自动对焦）等任务。网上搜“isp pipeline”“fpga isp”“富瀚isp”时，跳出来的基本都是图像处理相关的内容。

同样，“ICP”在计算机视觉领域还代表Iterative Closest Point（迭代最近点），是点云配准的经典算法。所以当你查资料时如果发现内容完全对不上号，先别怀疑自己，大概率是碰到了同名缩写。记住：烧录语境下的ISP是In-System Programming，ICP是In-Circuit Programming，IAP是In-Application Programming，三条别混。

3. ICP在电路编程：调试器直连芯片，开发者的万能钥匙

3.1 ICP为什么最“万能”

ICP的核心是使用SWD或JTAG接口，通过调试器（如ST-Link、J-Link、DAP-Link）直接连接目标芯片。调试器并不是简单地把数据“喂”给芯片，而是通过调试端口访问芯片内部的调试总线，强制控制内核执行特定的操作，比如暂停程序运行、读写内存、擦除Flash、写入固件。

正是因为这个机制，ICP有很多天然优势：

• 基本不受芯片厂商限制，只要芯片支持标准JTAG/SWD协议就能用；
• 可以对芯片内部任意地址的Flash进行编程，不需要芯片预置任何引导程序；
• 烧录的同时就能调试，打断点、看变量、单步执行一条龙；
• 即使芯片里已经写满了错误的程序，也能通过ICP擦除并重新烧录。

这也是为什么STM32生态里绝大多数开发者和量产产线都选择SWD接口做编程。SWD只需要两根线（SWCLK和SWDIO），加上GND和VCC最多四根线，布线难度低，烧录速度却能达到几MB每秒，比串口ISP快得多。

3.2 SWD接口的连接与配置细节

实际操作中，用ICP方式烧录的硬件连接并不复杂，以最常用的ST-Link为例：

这里有一个非常典型的坑：很多人只接了SWDIO、SWCLK和GND三根线，却发现连接器偶尔能识别、偶尔报错，尤其在芯片程序里关掉了调试端口或进入了低功耗模式的情况下。最稳妥的做法是把NRST线也接上，并在调试器的连接设置里勾选“Connect under Reset”或“Reset after Connect”这类选项，让调试器先拉低复位引脚，再发起调试连接请求。因为有些芯片上电后程序会很快把SWD引脚复用成GPIO，导致调试器无法抢占连接，加了复位控制就能绕开这个问题。

3.3 ICP在生产烧录中的表现

量产烧录时ICP也承担了重要角色。虽然它需要额外采购调试器，但效率极高。产线上常用方法是“一拖多”烧录器，一个控制器同时接四路、八路甚至更多SWD接口，把固件同时写入多个芯片。配合工装治具，操作员只需把待烧录的电路板放到指定位置，按下按钮，几秒后指示灯变绿即可取下下一块。

但ICP也有它的局限性。第一，调试器成本不低，正版J-Link动辄上千，即便使用国产DAP-Link，批量采购也需要一笔费用。第二，烧录效率受限于调试接口速度，部分芯片的调试口时钟最高只有几MHz，烧大固件时仍然需要等待。第三，它要求电路板上必须预留SWD/JTAG接口，在一些体积极小的消费电子产品上，连调试触点都放不下的情况并不少见。这时候就该考虑ISP方式了。

4. ISP在系统编程：一根串口线走天下，成本低到极致

4.1 隐藏在芯片里的“出厂引导程序”

ISP的核心是芯片出厂时预置于ROM区的一段引导程序，很多芯片的叫法不太一样，但作用一致。STM32叫System Bootloader，STC叫ISP监控程序，GD32也内嵌了类似的BootROM。

芯片上电时，先运行这段引导程序，它会检查特定引脚的电平状态或者特定寄存器的值。如果条件满足，就进入ISP模式，等待外部主机发送命令；如果条件不满足，就跳转到应用区去执行用户程序。

举个例子，STM32F103上电后会根据BOOT0和BOOT1引脚的电平决定启动位置：BOOT0=1且BOOT1=0时从系统存储器（System Memory）启动，也就是进入ISP模式。此时芯片的USART1会以固定波特率（通常是9600或115200）等待接收数据，上位机软件（如STM32CubeProgrammer、FlyMcu）就能通过串口把HEX或BIN文件发送给它，引导程序负责接收并写入Flash。

4.2 零成本烧录：STC单片机的ISP传统

国内很多工程师的第一块单片机是STC89C52，当时烧录工具就是一根USB转TTL串口线。STC的ISP软件通过串口给芯片发送特殊的数据帧，触发芯片片内的ISP引导程序，然后按协议上传固件。整个过程完全不需要专用调试器，几块钱的CH340模块就能搞定。

但用过的朋友一定都懂STC ISP软件的“个性”：界面复古，操作按钮隐藏较深，默认还会弹一些推广窗口。网上流传的“stc isp去弹窗”话题，说的大多是如何关闭这类软件启动时的广告或更新提示。这里我的实际经验是：与其折腾各种修改版，不如直接用官方新版软件，在设置里把“每次启动显示欢迎界面”勾掉，把“检查更新”改为手动，体验会清爽很多。更重要的是，新版软件对新型号芯片的协议兼容更好，用旧版容易出现“写超时”这种让人抓狂的问题。

4.3 ISP与ICP如何选择

搞清楚原理后，两者的取舍就很清楚了：

实际项目里经常是两者并用：开发阶段用ICP/DAP调试器加速迭代，量产阶段若产品没有预留SWD接口就用ISP方案来烧录。尤其是那些电池供电、PCB面积抠到极致的穿戴设备和传感器节点，往往整板只有VCC、GND、TX、RX四个测试点，这时候ISP是唯一选择。

5. IAP在应用编程：程序自己更新自己，远程升级全靠它

5.1 IAP打破了“必须借助外部工具”的格局

ISP和ICP都有一个共同前提：必须有外部设备（PC、烧录器）与芯片连接。但物联网设备一旦部署出去，现场根本不会有人带着烧录器去升级。IAP就是为了解决这个痛点而设计的，它的核心思想是：把芯片Flash划分成多个区域，其中一部分存放一段用户自己写的引导程序（Bootloader），另一部分存放真正的应用程序（App）。芯片上电先运行Bootloader，Bootloader判断是否需要升级，需要就从UART、CAN、USB、以太网、Wi-Fi等通道接收新固件并写入App区，然后跳转执行App。

更妙的是，App本身也可以接收升级指令，把新固件暂时存放在外部存储或RAM里，做好标记后复位重启进入Bootloader，由Bootloader完成最后的刷写。这样即便升级中途断电，Bootloader也能保证至少还能再进一次升级流程，不至于把设备变砖。这种“双保险”机制是整个IAP设计的灵魂。

5.2 Bootloader与App的内存规划

要实现IAP，第一步是合理规划Flash地址空间。以STM32F103RCT6（256KB Flash）为例，一个经典的分区方案是：

这个分区不是随便定的，有几个关键约束：

• Bootloader大小必须留足，因为升级协议处理、Flash驱动、通信驱动都塞在里面，空间太小会编译不过；
• App的起始地址要按Flash扇区对齐，STM32F103的扇区大小不一，前4个扇区各4KB、后面都是16KB/64KB，对齐出错会导致擦写覆盖到错误区域；
• 参数区要独立放在最后一页，避免App升级时把校准数据覆盖掉；
• 中断向量表需要重映射。App编译时必须把起始地址改为0x08008000，同时把向量表偏移寄存器（SCB->VTOR）设为App地址，否则中断一进来就跑到Bootloader的向量表里去了。

这里有一个入门者最容易踩的雷：Keil里改了IROM1的起始地址，却忘了在代码启动时重新设置VTOR，结果程序下载进去后所有中断都不响应，系统看似“跑起来”了，实际一按按键就死机。STM32F1系列某些型号没有VTOR寄存器，还需要通过复制中断向量表到RAM等传统方式处理，这一点查芯片手册时要格外留意。

5.3 一个完整的串口IAP升级流程

把理论与实践结合，一次典型的UART自动升级流程大致是：

1. App正常运行，接收到上位机发送的“升级请求”命令；
2. App校验命令合法性后，向主机发送“准备就绪”应答；
3. 主机开始分包发送新固件，每包通常包含地址、长度、数据和CRC校验值；
4. App每收完一包就写入外部存储或内存缓冲区，并回送确认帧；
5. 主机发送“结束”包后，App做整体校验，校验通过则置位升级标志位，然后执行NVIC_SystemReset()复位；
6. 芯片重启后进入Bootloader，Bootloader读取升级标志位，从存储区读取固件，擦除App区并逐包写入；
7. 写入完成后再校验一次，成功则清除升级标志并跳转到App；失败则保留标志，等待下一次升级尝试。

这个流程里有几个容易出问题的地方：

• 升级标志位的存储位置很讲究。如果放在普通RAM里，复位后变量就丢了，必须在复位前把标志写进备份寄存器或Flash指定区域。备份寄存器（如STM32的RTC Backup Register）在系统复位时不会丢失，是最常用的方案。
• 固件包的校验不能只靠CRC16，恶意环境下建议至少加上CRC32或SHA256，防止固件被篡改或传输损坏。
• 跳转函数要用函数指针跳回App的ResetHandler，而不是直接调用main()，否则全局变量没初始化、堆栈没重设，App必然跑飞。

5.4 不同芯片做IAP的差异点

IAP的思路是通用的，但落到具体芯片上，坑各不相同。

• STM32F103：经典Cortex-M3核，Flash扇区小，容易做灵活分区，但要注意部分型号在擦写Flash时不能同时从同一块Flash取指，所以擦写函数通常要拷贝到RAM里执行（即RamFunc技巧）。
• GD32F103：和STM32F103引脚兼容，但Flash擦写时序、选项字节、主频都有差异。直接照搬STM32的IAP库往往不行，推荐使用GD32官方提供的Firmware Library来写Bootloader。还有个容易忽略的点：GD32的Flash擦写粒度虽然与STM32类似，但选项字节的解锁序列不同，贸然网上下载通用代码可能触发HardFault。
• HC32L136：小华半导体的低功耗MCU，主打低功耗场景。IAP时需要特别注意Flash编程器的手动操作流程，官方库里对“擦、写、加锁”三步分得很细，少一步都会导致校验失败。
• STM32H750VBT6：这是个比较特殊的芯片，标称128KB片内Flash，实际很多板子外挂QSPI Flash存储代码。做IAP时除了常规Flash分区，还要处理QSPI映射地址、XIP执行、启动时的重映射问题，比F1系列复杂不少。不少网上的“H750 IAP工程”看起来简单，实际跑通后才发现它把大部分代码放在外部Flash，Bootloader里要做QSPI初始化，步骤多、时序敏感，必须花时间调。

5.5 Bootloader里定义的变量复位后到底会怎样

这个问题在开发社区里讨论热度很高，因为在IAP跳转失败排查时，很多人会怀疑Bootloader内部变量状态不对。先说结论：不能简单说“会清零”还是“不会清零”，要分情况。

情况一：Bootloader重新上电或从App执行系统复位后进入Bootloader。此时芯片走完整的启动流程，启动代码会把BSS段清零、把DATA段从Flash复制到RAM，然后才进入main。所以Bootloader里的全局变量会被重新初始化，局部变量如果依赖“上一次遗留的值”就是幻想，它必然是最新的初值。

情况二：App直接通过函数指针跳转到Bootloader，中间没有复位。这时Bootloader所在内存区域里的全局变量在跳转前依然保留着原有数据，如果Bootloader代码设计得不够严谨，在main入口处没有主动初始化某些关键标志，就可能会出现“上次剩余值干扰本次逻辑”的怪问题。所以正经工程里Bootloader都要求自己初始化所有关键状态，绝不允许依赖跳转前残留值。

情况三：Bootloader变量定义在普通RAM，但跳转到App后，App的RAM布局把Bootloader变量所在地址覆盖了。App运行时往里写数据，再跳回Bootloader时这些变量已经面目全非。这就是为什么很多人发现Bootloader“明明没改代码，升级多几次后行为却变了”的根本原因。

最稳妥的做法是：所有跨IAP流程的关键信息（升级标志、固件长度、固件版本等）都不要放在普通全局变量里，统一存到备份寄存器、Flash末页专用参数区或RTC SRAM中。这样无论从哪里跳转、是否复位，读写到的都是预期数据。

6. 量产烧录与现场升级：怎么选对方案

6.1 开发调试阶段：优先ICP

个人开发、团队联调阶段，无脑选SWD调试器。理由很简单：你能打断点、看寄存器、实时刷新变量，这些能力是串口ISP完全给不了的。哪怕你只是做纯软件逻辑不涉及硬件故障排查，debugger仍然是效率最高的工具。建议每个工位上至少常备一个ST-Link/V2或DAP-Link，成本不高，省下来的排查时间价值远超这点钱。

6.2 批量生产阶段：分条线走

产线烧录策略要根据产量、成本、产品形态综合决定。

• 大批量标准板卡（如开发板、工业控制板）：优先上多路SWD烧录架，人工放板、自动烧录、自动校验，一台机器一天烧上千片不成问题。
• 小批量或异形板（无SWD接口预留）：用ISP串口烧录方案。产线工人只需要插入USB转TTL连接器，运行烧录脚本即可。注意提前在工装里把波特率固定下来，并加入烧录后的自动校验步骤。
• 高可靠性产品（汽车电子、医疗设备）：除了烧录动作本身，还要做固件指纹比对，甚至要求每片芯片烧录CFG区域时写入唯一序列号、校准参数。这种需求更适合在ICP环节通过脚本配合完成，因为调试器可以直接访问选项字节和唯一ID寄存器。

6.3 远程升级规划：IAP是基础，OTA是上层建筑

很多人把IAP和OTA（Over-The-Air，空中升级）划等号，这其实不太严谨。OTA是远程升级的完整业务形态，IAP只是其中的烧录落地手段。一套完整的OTA方案还要包括固件签名、后台管理平台、设备端升级策略、断点续传、失败回滚等。

我在产品上设计IAP时有一条经验：永远保留一个“绝不出错的兜底跳转逻辑”。即使App区固件已经被擦坏，Bootloader也要能通过固定串口接收新固件重新刷写。这个兜底逻辑绝不依赖任何App状态，不依赖任何外部存储，只依赖最简单、最稳定的通信方式。宁可升级功能简陋，也不让设备失去再次升级的能力。

另外，从App跳转到Bootloader时，通信外设的硬件状态要提前做清理。比如UART的DMA还没关闭、中断没有屏蔽，Bootloader初始化时会读到一堆残留状态，轻则串口乱码，重则进中断死循环。常见的做法是：跳转前关全局中断、关外设时钟、把DMA失能、把引脚全部恢复默认状态。

7. 常见问题排查与避坑清单

7.1 调试器连接失败：先从硬件三要素查起

SWD连接失败是群里被问烂的问题，排查顺序我是这么固定的：

1. 量供电：目标板VDD是否为芯片要求的电压，GND是不是真的和调试器共地。很多板子只靠调试器供电，负载一重电压就塌了。
2. 查引脚：SWDIO和SWCLK是否被板上的其他器件占用，比如串联了电容、电阻，或者被复用为普通GPIO。
3. 看复位：在调试软件里选择“Connect under Reset”，拉低NRST再连接。能解决很多“程序已跑飞”导致的连接失败。
4. 降频率：部分国产芯片的SWD时序兼容性一般，把调试器频率从4MHz降到1MHz甚至500kHz，成功率会明显提升。

以上四步都试过还不行，再怀疑调试器固件问题或PCB虚焊。

7.2 程序能下载但跑不起来

这种问题在ICP烧录后最容易出现。芯片里确实有固件，但一复位就跑飞或卡死。原因通常是这几类：

• 启动文件选错：器件型号和启动文件不匹配，中断向量表起始地址错乱；
• 晶振没起振：HSE外部晶振配置错误，代码卡在等待时钟就绪的循环里；
• Boot引脚状态不对：芯片上电从系统存储器或SRAM启动，没走Flash启动路径；
• 看门狗没喂：程序里打开了独立看门狗，但初始化后没有及时喂狗，反复复位。

排查方法是：把调试器连上，在复位后停在main入口，单步看卡在哪里。如果连main都进不去，重点检查启动文件和芯片选择；如果卡在时钟初始化，重点检查晶振和配置代码；如果跑飞进HardFault，可以把链路寄存器LR的值反汇编，定位爆掉的那条指令。

7.3 IAP跳转不成功的经典原因

跳转是IAP里最玄学的环节，代码明明没错，跳过去就是死。结合我自己的调试经验，排名前三的原因：

• 堆栈指针没设好：跳转前没有从App起始地址的前四个字节加载新的MSP值。跳转函数必须这样写：

void jump_to_app(uint32_t app_addr) { uint32_t app_stack_addr = *(volatile uint32_t *)app_addr; uint32_t app_reset_addr = *(volatile uint32_t *)(app_addr + 4); if (((app_stack_addr & 0xFFF00000) == 0x20000000) && ((app_reset_addr & 0xFFF00000) == 0x08000000)) { __disable_irq(); // 跳转前恢复默认时钟也是很多芯片必须做的 SystemClock_SetToDefault(); // 函数指针跳转 void (*jump)(void) = (void (*)(void))app_reset_addr; __set_MSP(app_stack_addr); jump(); } else { // 地址校验失败，不执行跳转 } }

• 中断向量表没重定向：App编译地址已改，但VTOR没写，或写的位置不对，导致App一进中断就跑回Bootloader。
• Flash写保护处于使能状态：芯片选项字节里开了Flash写保护，Bootloader写完第一个扇区后写第二个扇区直接失败，升级进度条走到一半就报错。

7.4 Flash擦写保护与解除

Flash写保护（RDP级别）是量产保护的重要手段，但也是烧录失败的一大来源。芯片一旦设了最高级别的读保护，调试器就无法通过SWD读取Flash，甚至连接时直接报“Cannot access Memory”。解除方式也不同：如果是可逆的Level 1保护，可以通过调试器发送解除命令；如果是不可逆的Level 2保护，芯片生命周期直接结束，只能换新。

所以在量产时切勿随意设置高等级保护，必须确认后续确实不再需要调试访问，否则品控和返修阶段会非常痛苦。很多厂家只在最终出厂前最后一道工序设置保护，就是这个原因。

7.5 关于STC ISP下载的一些小事

最后聊点轻松但实用的：STC单片机的ISP串口下载在国内覆盖面极广，但它有个特色——下载时需要冷启动（先断电再上电）触发引导程序。很多新手第一次用就把供电一直开着，点“下载”按钮后毫无反应。正常流程是：先点下载，等软件提示“正在检测目标单片机”后，再给单片机重新上电，这个瞬间芯片冷启动，引导程序检测到上位机请求，烧录才开始。

另外，国产USB转TTL芯片的驱动兼容性也值得注意。CH340在老旧Windows系统上经常蓝屏，换成CP2102或FT232芯片会稳定很多。如果企业产线用到STC ISP方案，建议专门做一个小工装，用继电器控制目标板电源，让机器自动完成“断电—上电—烧录—校验”的时序，能显著减少人工操作失误。

说实话，写了这么多年固件，回头看ISP、ICP、IAP这三兄弟，虽然原理上都不复杂，但真正吃透还是靠一次次的返工和调试堆出来的。我最深的体会是：不要追求“万能方案”，每个项目在开局时就应该想清楚代码怎么烧、升级怎么升、量产怎么保。把烧录这件事放在系统设计的最前端去考虑，后面能少走很多弯路。尤其是IAP这种涉及启动流程和内存布局的设计，早期多花一小时规划分区，比后期在产线上救砖划算得多。希望这篇文章能帮你在烧录这条路上少踩几个坑。