1. 从能跑就行到可以出厂量产烧录这道坎到底卡在哪我接触ESP32做产品开发有几年了见过太多这样的情况实验室里用Arduino IDE点一下上传按钮板子跑得好好的代码没问题功能也验证完了。然后厂长或者老板问一句这批一百台怎么烧人就愣住了。这个卡点非常真实也非常普遍。开发阶段我们用USB线连着电脑Arduino IDE在后台把编译产物、分区表、引导程序、烧录地址这些东西全部自动处理掉了我们看不见也不需要看见。但到了量产环节你不可能给每台设备配一台电脑、一个人、一根USB线去点上传按钮。你要的是一份或者几份固件文件配合一个烧录工装或者一台脱机烧录器几秒钟出一台。所以这篇文章要解决的核心问题就三件事第一搞清楚Arduino IDE编译之后那几个bin文件分别是什么、分别烧到哪里第二怎么把Arduino的编译产物完整地导出成可以脱离工程环境使用的烧录文件集合第三怎么用这些文件做批量烧录包括量产时的地址合并、脱机烧录器的使用、以及一些批量烧录时才暴露出来的坑。我默认读者是有一定Arduino和ESP32基础的至少点亮过一个LED、跑通过串口打印。如果你是纯新手也没关系涉及基础概念的地方我会补一句解释。但对ESP32的Flash分区结构完全没概念的人建议先补一下这块否则后面讲地址的时候会有点晕。需要先明确一点ESP32的烧录不是一个bin文件烧进去就完事它至少涉及四个部分——bootloader、分区表、应用程序、以及可选的引导参数和文件系统镜像。这四个东西烧录地址各不相同任何一个烧错位置设备都起不来。这就是为什么直接从Arduino的临时编译目录随便捞一个bin文件出来往往烧进去不工作。提示本文所有操作基于Arduino IDE搭配ESP32开发板支持包的环境不同版本IDE的临时编译目录路径会有差异但文件结构是一致的。2. Arduino编译ESP32时那堆bin文件到底是什么2.1 先把Arduino藏起来的编译过程摊开看Arduino IDE对ESP32的编译本质上是在背后调用了一套完整的构建链条。你点验证/编译按钮的那一刻它做的事情大致是这样的先编译你的.ino文件Arduino会自动把它包装成一个.cpp文件然后连同你引用的库、ESP-IDF的核心组件一起编译成静态库链接阶段把所有目标文件链接成.elf可执行文件最后用esptool.py的elf2image能力把.elf转换成可以直接烧进Flash的二进制镜像。关键就在于最后这一步之后产物不会留在你的工程目录里。Arduino IDE把所有的中间产物和最终产物都放在一个系统的临时目录里。Windows下通常在C:\Users\你的用户名\AppData\Local\Temp\arduino下面或者在arduino-build-xxxx这样的文件夹中macOS和Linux则在/tmp或者/var/folders下面的深层目录里。这个临时目录的路径有个规律以工程文件名加上一串哈希值命名。同一个工程、同一台电脑路径基本稳定换台电脑或者改了工程名路径就变了。所以想靠去临时目录复制文件来做量产在小批量阶段勉强能用但绝不能作为长期方案因为路径不可控、文件可能被IDE清理、而且换个人操作就找不到。2.2 bootloader、分区表、应用程序、文件系统各自的角色要导出正确的烧录文件集合必须先理解这四类文件各自是什么缺一个会怎样。bootloader.bin是ESP32上电后第一段真正执行的代码。ROM里的引导代码会把Flash特定地址的内容加载进来这就是二级引导程序。它负责初始化基本的Flash访问、读取分区表、然后跳转到应用程序入口。Arduino默认生成的bootloader烧录到0x1000对于大多数ESP32型号这个地址是芯片ROM硬编码去读取的改不了。partitions.bin是分区表描述Flash这块存储空间怎么划分。里面定义了应用程序从哪开始、占多大NVS存储在哪OTA备份区在哪SPIFFS或LittleFS文件系统在哪。默认分区表烧录地址是0x8000。这个地址同样由bootloader约定不能随便改。你如果自定义过分区方案这个文件的内容就和你写的一致如果没动过就是Arduino为你选的那套默认方案。应用程序bin也就是你的固件本体文件名通常和工程名一致比如Blink.ino.bin。它烧录的地址由分区表决定默认双OTA方案下通常是0x10000。注意这里有个新手常踩的坑很多人以为应用程序是烧到0x0的其实0x0一般是留给别的用途的应用程序从0x10000开始。这个地址如果和分区表不匹配设备就是无限重启。boot_app0.bin是引导参数这个文件特别容易被忽略。它决定OTA机制下当前应该从哪个应用分区启动。默认烧录地址是0xe000大小0x2000。即使你不用OTA功能Arduino生成的镜像通常会把这个文件也烧进去因为bootloader会读它来确认启动哪个app分区。少了它某些版本下设备会出现启动异常。如果你用了SPIFFS或者LittleFS存网页文件、配置文件那还会多出一个文件系统镜像比如spiffs.bin烧录地址和大小同样由分区表定义。用一个表格把默认情况整理清楚文件名内容默认烧录地址是否必须bootloader.bin二级引导程序0x1000是partitions.bin分区表0x8000是boot_app0.binOTA引导参数0xe000通常必须工程名.ino.bin应用程序固件0x10000是spiffs.bin / littlefs.bin文件系统镜像由分区表定视需求注意上表是针对常见的ESP32双OTA分区方案的默认值。如果你用的是ESP32-S3、C3这些型号或者自定义了分区表地址会有差异务必以你实际编译出的分区表为准。2.3 为什么不能只拷贝一个ino.bin去量产理解了上面四类文件之后答案就明显了这四类文件共同构成一份完整可启动的固件。只烧应用程序bootloader和分区表是空的或者不匹配芯片根本不会运行你的代码。而且不同批次的芯片出厂时Flash内容可能不同有的带厂商测试数据量产前通常需要整片擦除再烧。反过来如果你把四个文件全部用工具合并成一个大bin从0x0开始整片烧那就省事多了。这是量产里最常用的做法后面会详细讲合并。还有一个现实问题Arduino编译出来的.ino.bin里OTA相关的元数据、分区校验信息都是按编译时的分区表生成的。如果量产时你临时换了分区方案bin和分区表就对不上了。所以量产固件一旦定版分区表、bootloader、应用程序三者必须一起冻结、一起烧。3. 把编译产物导出来两条路选哪条3.1 开启Arduino的详细编译输出定位临时目录最直接的办法是让Arduino IDE告诉你编译产物在哪。打开Arduino IDE进入文件 - 首选项找到显示详细输出这一栏勾选编译。然后回到工程按住Shift点验证或者直接点验证不同版本行为略有差异你会发现下方的输出窗口开始刷大量命令行信息。在这些信息里仔细找每一行编译命令。ESP32的构建系统会打印出实际调用的命令行你能从中看到.elf文件的完整路径比如C:\Users\xxx\AppData\Local\Temp\arduino\sketches\XXXX\Blink.ino.elf。找到这个elf文件所在目录同一目录下就有我们要的所有bin文件。这种方法的好处是零成本、马上能用适合单次导出、验证阶段。坏处也明显路径是随机的哈希目录不可复现IDE清理临时文件后就没了团队协作时每个人路径不同。所以我只推荐它用于我第一次导出想看看这些文件长什么样。3.2 用编译输出的复制二进制文件或导出功能Arduino IDE 2.x版本在编译成功后输出窗口附近有一个导出二进制文件的能力不同小版本位置和叫法略有变化有的在 Sketch 菜单下的导出已编译的二进制文件。点了之后IDE会把该工程编译出的所有bin文件复制到你工程目录下一个新建的文件夹里通常叫build。这个方式比手动翻临时目录靠谱得多导出后的文件是显式存在工程目录里的路径固定、可打包、可入版本管理。我日常导出量产候选固件时基本都是走这条路。导出之后你会看到一个类似这样的文件集合build/ ├── Blink.ino.bin ├── Blink.ino.bootloader.bin ├── Blink.ino.partitions.bin ├── Blink.ino.elf └── ...注意文件名里的前缀是你的工程名不是标准的bootloader.bin。这个命名对烧录本身没影响只要地址对就行但为了量产工装配置清晰我习惯把文件名规整成统一形式避免操作员混淆。3.3 用arduino-cli把导出流程脚本化如果你要做的不是一次导出而是持续集成、每改一版代码就要出一份量产固件那手动点按钮就太落后了。这时候该上arduino-cli。arduino-cli是Arduino官方的命令行工具功能和IDE一致但没有图形界面。基本用法是这样# 编译工程指定输出目录 arduino-cli compile --fqbn esp32:esp32:esp32 --output-dir ./firmware_out ./MyProject # 参数说明 # --fqbn 指定开发板标识esp32:esp32:esp32 是通用ESP32 Dev Module # --output-dir 指定编译产物输出目录执行完之后firmware_out目录里就是完整的bin文件集合路径固定、可脚本化、可接进CI流水线。生产环境里我强烈推荐这种方案它能保证同一份代码任何时候编译出的固件地址和结构都一致这对量产可追溯性非常重要。一个实际经验--output-dir里的产物在你下次编译同一工程时会更新但不会主动删除旧文件。如果你工程名改过旧bin可能残留打包前记得清理目录或者用脚本校验文件清单避免把上一版固件混进去。提示arduino-cli需要先安装对应的开发板支持包命令是arduino-cli core install esp32:esp32。这一步和IDE里装开发板支持包是同一个来源装一次即可。4. 量产烧录实操从四个文件到一条产线4.1 为什么量产更推荐合并成整片镜像前面说了四类文件分别烧四个地址。理论上你在烧录工装里配四条烧录项就能工作很多烧录器也支持这种多文件多地址模式。但我做量产时几乎总是先把它们合并成一个大bin原因有三条。第一容错率。四条烧录项意味着四个地址配置任何一条地址填错、文件选错产线上就是一批不良品而且不良原因还不好查。合并成整片镜像后只有一条烧录项从0x0开始地址填错的可能性极低。第二可校验。合并后的大bin可以做完整的MD5、SHA校验。产线烧录完成后回读校验只要校验值对不上就报警比逐段校验更简单可靠。第三效率。部分烧录工装在对多文件分别烧写时会引入额外的Flash操作开销整片烧写往往更快更直接。合并用esptool.py的merge_bin子命令就能完成不需要额外安装什么esptool.py --chip esp32 merge_bin -o firmware_merged.bin \ --flash_mode dio --flash_freq 40m --flash_size 4MB \ 0x1000 bootloader.bin \ 0x8000 partitions.bin \ 0xe000 boot_app0.bin \ 0x10000 app.bin几个参数要盯着看--flash_mode、--flash_freq、--flash_size这三个会写进镜像头部决定芯片上电时怎么访问Flash。它们必须和你的实际硬件、分区表设置匹配。比如你的模组是4MB Flash这里写8MB合并出来的镜像头部信息就是错的虽然大部分情况下能跑但属于隐患。判断方法很简单看你Arduino里选的开发板型号对应的Flash大小或者直接查模组丝印。0x10000 app.bin这里的app.bin就是前面导出的工程名.ino.bin我建议在合并前统一重命名让命令更清楚。4.2 脱机烧录器和烧录工装怎么配合并出整片镜像之后量产烧录就有几种形态了。小批量几十到几百片最经济的方式是脱机烧录器。这类设备自带Flash存储你把合并好的bin拷进去配好烧录起始地址0x0然后把芯片或模组放到烧录座上按一下按钮就烧一片。好一点的脱机烧录器支持自动序列号烧写能把芯片唯一ID或者递增序号写进指定Flash地址这对需要唯一标识的设备很关键。中等批量几千到几万通常上烧录工装一次烧多片配合夹具同时压接多个模组。工装的核心是治具的接触可靠性我踩过的坑里接触不良导致的烧录失败至少占了三成。判断方法同一批料如果失败率忽高忽低且重试又能成功八成是接触问题而不是固件问题。这时候要查探针是否氧化、压力是否够、定位是否偏。大批量就是芯片厂或者模组厂代烧了你把整片镜像和烧录地址给过去他们用在线烧录设备处理。这种模式下你要重点确认的是镜像的Flash参数和芯片型号完全一致。4.3 用esptool直接批量烧适合开发和试产在产线工装到位之前或者试产阶段几十片用esptool.py配一个脚本就能批量烧。基本命令esptool.py --chip esp32 --port COM3 --baud 921600 \ write_flash -z 0x0 firmware_merged.bin-z表示压缩传输大镜像下能明显提速。--baud 921600在大多数USB转串口芯片上稳定如果你用的是CH340有时需要降到460800或者更低才能稳定CP2102一般能上921600。这个速度差异在量产时非常关键一个镜像按1MB算115200波特率下要一分多钟921600下十几秒差距是数量级的。批量的话写个循环脚本依次遍历串口号或者配合USB HUB多口同时烧。Windows下可以用Python的pyserial配合esptool的API或者直接调用命令行。要注意的是同时烧多路时USB带宽和主机性能要够否则会出现超时。注意批量烧录脚本里一定要加烧录后回读校验。esptool.py的write_flash默认不校验加--verify参数部分版本是默认开启的不同版本行为不同建议显式确认能读回比对。这一条能拦住绝大多数量产事故。4.4 量产时的地址与参数核对清单每次量产固件定版我都会过一遍这张清单你也可以照着做核对项检查内容出错后果芯片型号镜像按esp32还是esp32s3生成完全无法启动Flash大小合并时--flash_size与模组一致分区越界或空间浪费Flash模式dio/qio与硬件匹配启动不稳定分区表版本与应用程序同批编译地址错位、反复重启烧录起始地址整片镜像从0x0无法启动波特率与烧录器/USB芯片兼容反复超时回读校验烧录后必须校验不良品流出序列号逻辑是否需要唯一ID写入设备标识重复这张表里分区表版本和序列号逻辑是最容易被忽视的两项。分区表换了但应用程序没重编就会出现一种很隐蔽的故障设备能启动但一进某个功能就崩因为app读到的分区布局和它编译时假设的不一致。序列号这块如果你靠软件在首次启动时写那就要确保Flash里那段区域确实是可写的、不被后续固件升级覆盖。5. 那些只有真上过产线才会遇到的事5.1 能烧进去但起不来的三种典型原因第一种地址错。整片镜像本该从0x0烧工装里手滑写成了0x1000bootloader被烧到了app位置。现象是烧录成功、校验通过但设备毫无反应或者无限重启。排查方法用esptool.py read_flash 0x0 0x1000 dump.bin把芯片头部读出来和一个正确的镜像比对看开头的magic byte对不对。第二种Flash参数不匹配。合并镜像时--flash_size填的和实际芯片不一致。比如实际8MB但你填了4MB镜像头部的Flash容量字段就错了bootloader按错误信息去初始化Flash可能直接卡住。这个坑特别隐蔽因为烧录过程一切正常。第三种boot_app0缺失或地址错。设备可能启动后跑到一个空分区然后卡在bootloader里。表现是串口没有任何应用日志输出但用抓取工具能看到bootloader的启动信息。这三种情况排查思路一致先用串口抓启动日志看bootloader阶段有没有报错再读Flash头部比对参数最后核对分区表地址与app地址是否对应。不要一上来就怀疑代码量产阶段的故障九成在烧录配置不在代码。5.2 串口号漂移与工装接触问题多台设备同时接在一台电脑上批量烧时Windows给每路分配的COM号是动态的。你脚本里写死了COM3、COM4下次插拔顺序一变对应关系就乱了可能出现两个进程抢同一个口、烧到一半互相打架。稳妥做法是脚本里通过设备的VID/PID或者USB物理端口路径来识别而不是COM号。CP2102和CH340的VID/PID不同可以用这个过滤。更土但有效的办法是每个USB口固定接一路在设备管理器里把COM号手动固定下来插拔后依然有效。工装接触问题前面提过这里补一个排查技巧在烧录脚本里记录每次的连接握手信息。esptool.py连接时会打印芯片型号、MAC地址、Flash大小。如果某一路经常在连接阶段就失败基本就是接触问题如果能连上但烧写中途断可能是接触电阻变化或者电源不稳。给工装单独供电、加滤波电容往往能改善后者。5.3 固件版本管理和量产追溯这一条经常被小团队忽略但出问题时最要命。你的产线上同时在烧几个不同版本的固件烧完之后没有任何记录过两个月客户反馈某批设备有问题你连那批烧的是什么版本都查不到。我的做法是每一版量产固件合并后计算SHA256连同Arduino源码的commit号、编译时间、分区表版本一起记录在一个清单文件里。烧录工装尽量选支持记录每片芯片烧录日志的型号把芯片MAC和固件版本对应起来。这样追溯时能精确到片。如果烧录器不支持退而求其次可以在固件里编入版本号让它启动时通过串口打印出来或者提供一个查询接口。产线烧完抽检几片记录版本号。成本很低但关键时刻能救命。5.4 一个容易被忽略的细节Flash内容的初始状态新芯片出厂时Flash不是全空的也不是全0xFF可能带厂商的测试数据。如果你的固件没有覆盖到某些地址而那些地址残留着测试数据某些情况下会影响启动或者NVS初始化。这就是为什么量产时我坚持先整片擦除再烧。esptool.py的erase_flash能擦整个Flash或者用write_flash的时候加--erase-all不同版本参数名略有差异有的叫-e。擦除会多花几秒但能消除所有残留带来的不确定性。代价是擦除会清掉出厂校准数据吗不会芯片的校准数据在eFuse和ROM里不在这块可擦除Flash里。所以放心擦。还有一个细节如果你的产品需要保留某些Flash区域比如预置的配置文件、密钥整片擦除会把它们也擦掉。这种场景下就不能整片擦要先读出原始区域、擦除、再回写。量产前把这块逻辑想清楚别到产线才发现。6. 我实际做量产固件时的固定动作走到这里一套完整流程已经清楚了。我把自己每次出量产固件的固定动作串一遍你照着做能少走很多弯路。先把源码冻结确认分区表版本用arduino-cli compile --output-dir出一份产物然后清理输出目录里的旧文件确认bin文件清单和文件时间戳都是本次的接着用esptool.py merge_bin按正确地址合并参数和实际硬件严格对齐合并后自己先拿一块样品板从0x0整片烧录、擦除、再烧跑一遍完整功能确认无误后计算SHA256存档。到了产线先小批量试烧二十片全部做回读校验同时记录芯片MAC和版本号。试烧没问题再放量。放量过程中每过一个班次抽检一片做完整校验。这个抽检习惯帮我拦下过至少两次因为工装接触劣化导致的批量不良。最后分享一个小技巧把合并命令、参数、文件清单全部写进一个.bat或.sh脚本里存进工程。每次出固件就是改一下版本号然后双击运行既不会漏参数也不会记错地址还能把命令本身纳入版本管理。量产这事能交给脚本的绝不要交给人的记忆。