ESP32固件烧录核心工具：Flash Download Tool原理与量产实践

1. 为什么是 Flash Download Tool——不是“又一个烧录工具”而是ESP32量产级固件交付的底层锚点你手头那块ESP32开发板刚焊好、刚采购回来、刚从流水线上下来它出厂时芯片内部Flash是空的。它不认识WiFi协议栈不理解HTTP请求更不会驱动OLED显示温湿度——它只是一块沉默的硅片。让这块硅片“活过来”的第一步不是写代码不是配环境而是把第一段可执行机器码稳稳地、可重复地、可验证地塞进它的物理存储空间里。这个动作叫固件烧录而支撑这个动作最底层、最可靠、最贴近芯片手册的工具就是Espressif官方提供的Flash Download Tool常被简称为ESP-IDF Flasher或esptool GUI版。我做过三年ESP32模组产线技术支持经手过超过17个不同封装的ESP32-WROOM、ESP32-WROVER、ESP32-S2/S3模组也帮客户调试过基于ESP32的智能电表、工业网关和医疗传感器终端。所有这些项目无论最终用Arduino IDE、PlatformIO还是VS Code ESP-IDF烧录环节的最终落点95%以上都回归到Flash Download Tool或其命令行内核esptool.py。这不是因为其他工具不好而是因为Flash Download Tool直接调用Espressif芯片底层ROM Bootloader协议绕过了所有中间抽象层——它不依赖你的IDE是否装对了Python包不关心你的CMakeLists.txt有没有写错路径甚至不需要你电脑上装了ESP-IDF环境。只要串口能识别、供电稳定、接线无误它就能把.bin文件一帧一帧地发进芯片校验、写入、复位干净利落。很多人第一次接触ESP32会下个Arduino IDE点一下“上传”以为烧录就完成了。但当你开始做批量测试、做OTA升级验证、做硬件兼容性排查或者遇到“上传成功但板子不启动”这种经典问题时就会发现Arduino IDE背后的烧录逻辑像一层毛玻璃你能看到结果但看不清过程。而Flash Download Tool就像给你配了一副高倍放大镜示波器——它把烧录拆解成“连接→擦除→写入→校验→复位”五个原子操作每个步骤的状态、耗时、地址偏移、CRC校验值都清清楚楚列在界面上。比如你烧录失败它不会只报“Error”而是明确告诉你“Failed to connect: No serial port found” 或 “Write timeout at address 0x00010000”这比Arduino IDE的“Timed out waiting for packet header”有用十倍。它解决的从来不是“能不能烧进去”的问题而是“烧进去的是不是 exactly what I intended, and where I intended it to be”。你看热搜词里反复出现的“怎么看esp32的烧录地址”、“esp32烧录方式”、“esp32硬件调通测试”背后全是地址映射、分区表、bootloader配置这些硬核细节。而Flash Download Tool的界面就是你和ESP32 Flash物理布局之间最直接的对话窗口。它强制你面对这些细节你必须手动指定每个bin文件的烧录起始地址0x1000、0x8000、0x10000……必须理解bootloader.bin、partition-table.bin、firmware.bin三者如何在Flash中拼成一块完整的“可执行地图”。这种强制性的透明恰恰是避免后续无数玄学问题的起点。适合谁来认真对待它不是只有资深嵌入式工程师。如果你正在做毕业设计用ESP32做环境监测想确保每次烧录后传感器读数稳定如果你是创客买了块二手ESP32-WROVER不确定它之前烧过什么固件需要彻底擦除再刷如果你是小厂硬件工程师要给100块新PCB做首板验证需要一份可复现、可记录、可交接的烧录流程——那么Flash Download Tool不是备选而是必选项。它不炫技不自动不隐藏但它给你绝对的掌控感。这种掌控感在嵌入式开发里比任何“一键搞定”的便利都珍贵。2. 核心设计逻辑与方案选型为什么不用Arduino IDE上传为什么不用esptool命令行2.1 三层烧录架构GUI层、协议层、物理层的职责分离Flash Download Tool绝非一个孤立的.exe程序。它的价值深植于Espressif为ESP32系列芯片构建的三层烧录架构之中物理层Physical Layer这是最底层由ESP32芯片内置的ROM Bootloader固件实现。它在芯片上电或复位时自动运行监听UART0默认或USB-JTAG/Serial接口等待特定握手协议如SYNC、CHIP_ERASE等。它不依赖任何外部固件是芯片出厂即有的“生命维持系统”。Flash Download Tool的所有操作最终都是向这个ROM Bootloader发送原始指令流。协议层Protocol Layer这是esptool.py的核心。它将人类可读的命令如esptool.py --port COM3 write_flash 0x1000 bootloader.bin翻译成ROM Bootloader能理解的二进制指令包并处理超时重传、CRC校验、地址对齐等底层通信细节。它是连接GUI与芯片的“翻译官”。GUI层Graphical User Interface Layer这就是Flash Download Tool本身。它不处理任何通信逻辑只是esptool.py的一个可视化前端。它把协议层的复杂参数波特率、擦除模式、地址偏移、校验开关转化为直观的下拉菜单和输入框并将返回的状态码如Connecting...Erasing flash...Writing at 0x00010000...实时渲染成进度条和日志窗口。理解这三层就明白了为什么“不用Arduino IDE上传”Arduino IDE的上传功能是在其内部集成了esptool.py或精简版但它把上述三层全部封装在一个黑盒里。你点击“上传”它自动调用esptool.py --chip esp32 --port COM3 --baud 921600 --before default_reset --after hard_reset write_flash -z --flash_mode dio --flash_freq 40m --flash_size detect 0x1000 bootloader.bin 0x8000 partitions_singleapp.bin 0x10000 firmware.bin。这个命令是固定的、预设的你无法轻易修改其中任何一个参数。当你的项目需要自定义分区表比如增加OTA分区、需要使用QIO模式而非默认DIO、或者需要在0x0地址烧录自定义bootloader时Arduino IDE的黑盒就卡住了。而Flash Download Tool让你直接站在协议层之上自由组合每一个参数。2.2 与纯命令行esptool.py的对比GUI不是“简化”而是“聚焦”有人会问既然底层都是esptool.py那直接敲命令行不更高效这要看场景。我统计过自己过去一年的烧录操作单次调试占比约30%用命令行更快。比如快速验证一个修改后的firmware.binesptool.py -p COM3 -b 460800 write_flash 0x10000 firmware.bin敲完回车10秒搞定。首次烧录/量产准备占比约50%GUI不可替代。原因有三多文件协同烧录一个标准ESP32固件至少包含3个bin文件bootloader、partition table、application它们必须按严格顺序、精确地址烧录。命令行需要写一长串极易出错漏掉一个空格地址写错一位整个烧录就失败。GUI则用表格形式清晰列出每个文件、对应地址、是否启用加密一目了然。参数可视化验证波特率选多少460800是通用值但某些劣质CH340串口芯片在921600下会丢包。GUI里下拉选择比记命令参数可靠得多擦除模式选“Do not erase”还是“Erase only specified region”GUI用复选框标注比命令行的--erase-all或--no-stub更不易混淆。状态反馈即时性命令行输出是滚动文本关键错误信息可能一闪而过。GUI的日志窗口固定高度错误行会高亮红色且进度条直观显示当前操作阶段连接中→擦除中→写入中→校验中这对新手和产线工人极其友好。故障排查占比约20%GUI是“显微镜”。当烧录失败GUI日志会完整记录每一帧通信包括收到的响应字节。我曾用它抓到一个硬件问题某批次PCB的USB转串口芯片RX引脚虚焊导致ROM Bootloader发出的SYNC响应包丢失前两个字节GUI日志里清晰显示Received: 0x07 0x07 ...应为0x07 0x07 0x12 0x20...而命令行只报A fatal error occurred: Failed to connect to ESP32线索就此中断。所以GUI不是为了偷懒而是为了在需要“确定性”和“可追溯性”的场景下把协议层的复杂性收敛成一个可控的操作界面。它牺牲了一点命令行的极致速度换来了极高的操作容错率和问题定位能力。2.3 方案选型的硬性约束芯片型号、Flash大小、Bootloader版本选型不是凭感觉而是受三个硬性物理参数约束Flash Download Tool的界面设计完全围绕它们展开芯片型号Chip TypeESP32、ESP32-S2、ESP32-S3、ESP32-C3它们的ROM Bootloader指令集、内存映射、安全启动机制完全不同。Flash Download Tool启动时会自动检测芯片型号通过发送CHIP_ID指令并据此加载对应的通信协议。如果你强行用ESP32的配置去烧录ESP32-S3工具会直接报错“Unsupported chip type”这是硬件层面的保护。Flash大小Flash Size常见有2MB、4MB、8MB。这个参数决定了分区表partition-table.bin的最大容量和地址范围。例如一个4MB Flash的典型分区表会把ota_0分区放在0x100000而2MB Flash则可能放在0x80000。Flash Download Tool要求你手动选择Flash size因为它要据此计算擦除区域的边界避免误擦除不该动的区域比如NV存储区。Bootloader版本Bootloader VersionEspressif持续更新ROM Bootloader修复安全漏洞、提升稳定性。新版本Bootloader可能支持新的烧录指令如ESP_FLASH_ENCRYPT。Flash Download Tool内置了多个Bootloader版本的兼容逻辑。当你烧录一个启用了Flash加密的固件时工具会自动检测芯片是否支持该加密指令并在不支持时给出明确提示而不是盲目发送导致芯片锁死。这三个参数就是你打开Flash Download Tool后第一眼看到的“芯片型号”、“Flash size”、“Crystal frequency”晶振频率影响波特率稳定性下拉菜单的底层依据。它们不是可选项而是你和芯片对话前必须达成的“协议共识”。忽略它们就像用中文语法去跟一个只会法语的人谈判——沟通必然失败。3. 核心实操细节与关键参数解析从零开始一次成功的烧录全过程3.1 环境准备三步到位拒绝“环境玄学”很多初学者卡在第一步工具打不开或连不上板子。这不是运气问题而是环境准备没做到位。我总结出三步铁律亲测有效第一步驱动安装——认准CH340/CP2102拒绝“万能驱动”绝大多数国产ESP32开发板如NodeMCU-32S、ESP32 DevKitC使用CH340G或CP2102 USB转串口芯片。Windows系统去官方渠道下载驱动。CH340去南京沁恒官网wch.cnCP2102去Silicon Labs官网silabs.com。网上流传的“CH340万能驱动”往往混杂了旧版、盗版会导致串口识别不稳定或波特率不准。验证方法设备管理器中查看端口号如COM3右键属性→端口设置→高级→将“IRQ”设为“0”勾选“使用FIFO缓冲区”。这能显著降低高波特率下的丢包率。macOS/Linux通常免驱但需确认用户权限。macOS Catalina及以上需在“系统偏好设置→安全性与隐私→通用”中允许CH340驱动Linux下执行sudo usermod -a -G dialout $USER然后重启终端。第二步接线确认——TX/RX交叉GND共地VCC慎用标准接法USB转TTL模块 → ESP32USB模块的GND→ ESP32的GNDUSB模块的TXD→ ESP32的GPIO3 (RX0)USB模块的RXD→ ESP32的GPIO1 (TX0)关键禁忌提示绝对不要将USB模块的VCC接到ESP32的3.3V引脚大多数USB转TTL模块的VCC输出是5V会直接烧毁ESP32的3.3V电源域。ESP32开发板自身有稳压电路应由板载USB供电或外接3.3V稳压电源。仅在调试无USB供电的裸片时才谨慎使用外部3.3V。模式切换重中之重ESP32烧录需要进入“Download Mode”。方法是按住开发板上的BOOT按钮或GPIO0按钮按一下RESET按钮或断电再上电松开RESET按钮松开BOOT按钮。 此时ESP32的ROM Bootloader启动等待串口指令。Flash Download Tool连接时会自动尝试发送SYNC指令若成功日志显示Connecting...否则报错Failed to connect。第三步软件获取——只认Espressif官网拒绝第三方打包版去Espressif官网espressif.com→ Downloads → “ESP32 Download Tool”。下载最新版目前是v3.12.1解压后直接运行flash_download_tool.exeWindows或Flash Download Tool.appmacOS。警惕网上所谓的“绿色版”、“破解版”、“集成版”它们可能捆绑恶意软件或修改了底层esptool.py导致烧录行为异常如跳过校验、强制覆盖。3.2 界面详解与参数配置每个输入框背后都是芯片手册打开Flash Download Tool主界面分为四大区域。我们逐个拆解告诉你每个控件的真实含义区域一芯片与连接设置Top BarChip Type下拉选择你的芯片型号。务必与实物一致。ESP32-D0WDQ6双核、ESP32-PICO-D4SiP封装、ESP32-S2FH4S2系列选项不同选错无法通信。COM Port选择正确的串口号。Windows下是COM3/COM4macOS下是/dev/cu.SLAB_USBtoUARTLinux下是/dev/ttyUSB0。不确定时拔插USB线观察设备管理器或ls /dev/tty*的增减。Baud Rate波特率。460800是黄金值。它足够快比115200快4倍又足够稳921600在部分劣质线材上易丢包。除非你确认硬件支持且测试稳定否则不要盲目追求更高。区域二烧录文件配置表Main Table这是核心区域以表格形式呈现。每一行代表一个要烧录的bin文件及其属性No.ESP32 Download Tool File PathDownload AddressSPI SpeedSPI ModeFlash SizeEncrypt1bootloader.bin0x100040mDIO4MBNo2partition-table.bin0x800040mDIO4MBNo3firmware.bin0x1000040mDIO4MBNoFile Path点击右侧文件夹图标浏览选择bin文件。注意路径不能含中文、空格、特殊字符。Download Address烧录地址这是最易出错也最关键的参数。0x1000bootloader固定起始地址。所有ESP32固件bootloader必须从此处开始。0x8000partition table标准地址。它定义了Flash中各个分区app、ota、nvs、spiffs等的布局。0x10000application固件起始地址。这是你的main()函数所在位置。切勿随意更改此地址否则链接器生成的代码会跳转到错误位置。SPI Speed SPI Mode控制Flash读写速度和时序。40m40MHz和DIODual Input/Output是绝大多数ESP32模组的默认配置。QIOQuad Input/Output更快但需硬件支持Flash芯片必须是QSPI类型。Flash Size必须与你开发板上焊接的Flash芯片容量一致。选小了烧录会失败选大了浪费空间但不影响功能。Encrypt是否启用Flash加密。生产环境强烈建议开启但需提前配置密钥并烧录eFuse。新手请保持No。区域三操作按钮与全局设置Bottom BarStart执行烧录。点击后工具按表格顺序依次执行擦除、写入、校验。Stop紧急中止。烧录中途出错时使用。Clear Log清空日志窗口。Settings全局设置入口。Erase Before Programming擦除模式。Do not erase仅擦除目标区域、Erase only specified region擦除表格中所有地址范围、Erase all擦除整个Flash。量产首烧推荐Erase all确保干净。Verify After Programming烧录后校验。必须勾选它会读回Flash数据与源bin文件做CRC32比对确保一字不差。这是质量保障的最后防线。Auto-Connect自动重连。勾选后若连接断开工具会自动重试对不稳定串口很有用。区域四日志窗口Log Window这是你的“手术室监控屏”。所有操作、状态、错误都实时打印于此。成功日志示例Connecting... Detecting chip type... ESP32 Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None Crystal is 40MHz MAC: 24:0a:c4:xx:xx:xx Uploading stub... Running stub... Stub running... Changing baud rate to 460800 Changed. Configuring flash size... Auto-detected Flash size: 4MB Erasing flash (this may take a while)... Chip erase completed successfully in 1.2s Writing at 0x00001000... (100 %) Wrote 15872 bytes (9111 compressed) at 0x00001000 in 0.3 seconds (effective 423.2 kbit/s)... Hash of data verified. Writing at 0x00008000... (100 %) Wrote 3072 bytes (1722 compressed) at 0x00008000 in 0.1 seconds (effective 245.8 kbit/s)... Hash of data verified. Writing at 0x00010000... (100 %) Wrote 229376 bytes (129220 compressed) at 0x00010000 in 5.2 seconds (effective 352.9 kbit/s)... Hash of data verified. Leaving... Hard resetting via RTS pin...关键成功标志Hash of data verified.出现三次每个bin文件一次且最后Leaving...表示ROM Bootloader退出芯片复位运行。3.3 实操全流程演示以ESP32-WROOM-32为例从空白板到LED闪烁假设你有一块全新的ESP32-WROOM-32开发板4MB Flash目标是烧录一个最简的“Blink”固件让板载LED通常接GPIO2闪烁。Step 1获取标准固件文件去Espressif GitHub仓库github.com/espressif/esp-idf→ examples → get-started → blink。用ESP-IDF编译此例程需先搭建IDF环境生成的bin文件位于build/目录下bootloader/bootloader.binpartition_table/partition-table.binblink.bin即application固件Step 2配置Flash Download ToolChip Type:ESP32COM Port:COM3根据实际选择Baud Rate:460800在文件表中添加三行Row 1: Filebootloader.bin, Address0x1000Row 2: Filepartition-table.bin, Address0x8000Row 3: Fileblink.bin, Address0x10000Settings → 勾选Erase all,Verify After Programming,Auto-ConnectStep 3进入Download Mode并烧录按住BOOT按钮按RESET松开RESET松开BOOT。点击Start按钮。观察日志窗口等待Hash of data verified.出现三次。最后一行Hard resetting via RTS pin...后板子自动复位。Step 4验证结果板载LED应开始以1秒间隔闪烁。若不亮检查日志是否有Failed to connect→ 重做模式切换。日志是否有Invalid head of firmware→blink.bin地址写错应为0x10000不是0x0。LED不闪但串口有输出→ 可能固件中LED引脚定义错误WROOM-32的板载LED通常是GPIO2但有些山寨板是GPIO5。这个过程看似简单但每一步都踩在芯片硬件特性的刀锋上。它不是魔法而是对物理世界的精确操控。4. 常见问题深度排查与独家避坑技巧那些官方文档不会告诉你的细节4.1 典型问题速查表症状、原因、解决方案症状可能原因解决方案我的实操心得Failed to connect: No serial port found串口驱动未安装或失效USB线接触不良开发板未上电重新安装CH340/CP2102驱动更换USB线推荐带磁环的短线用万用表测开发板5V/GND是否正常驱动问题占此类错误的70%。我有个习惯每次新电脑装驱动后立刻用mode COM3Windows或stty -f /dev/cu.SLAB*macOS测试端口是否存在比等工具报错快得多。Connecting... - A fatal error occurred: Failed to connect to ESP32BOOT模式未正确进入TX/RX接反串口被其他程序占用如串口助手、Arduino IDE严格按“按住BOOT→按RESET→松RESET→松BOOT”顺序操作用万用表蜂鸣档测TX-RX是否导通任务管理器/活动监视器关闭所有串口相关进程这是最常见的“玄学”问题。我的独家技巧在按住BOOT的同时用另一只手快速短接GPIO0和GND如果开发板没有BOOT按钮这能100%强制进入Download Mode。Erasing flash... - Write timeout at address 0x00010000波特率过高导致通信丢包Flash芯片损坏烧录地址超出Flash物理范围将Baud Rate从921600降至460800用esptool.py --port COM3 flash_id命令读取Flash ID确认型号检查firmware.bin地址是否大于Flash容量如4MB Flash最大地址为0x400000波特率是隐形杀手。我曾为一块“假”ESP32-WROOM-32实为ESP32-D2WD调试一周最终发现它只支持最高115200波特率921600必然超时。Hash of data verified. - But LED doesnt blink / Serial prints nothing分区表不匹配如用2MB分区表烧录4MB板application固件地址错误应为0x10000误写0x0bootloader.bin与芯片不兼容用esptool.py --port COM3 read_flash 0x8000 0x200 partition-table.bin读回分区表用文本编辑器打开确认app分区起始地址是0x10000检查blink.bin是否真的生成在0x10000地址这是“烧录成功但功能失效”的经典陷阱。我的经验永远用esptool.py --port COM3 read_flash 0x10000 0x1000 test.bin读回前4KB用hexdump -C test.bin | head看开头是否是e9 f0 0d 00ESP32 application header这是最直接的验证。Tool hangs at Uploading stub...USB转串口芯片固件bugWindows快速启动功能干扰USB供电不足更新CH340固件官网提供禁用Windows“快速启动”控制面板→电源选项→选择电源按钮的功能→更改当前不可用的设置→取消勾选“启用快速启动”给开发板外接5V电源快速启动是Windows的隐藏杀手。它会让USB设备在休眠后无法被正确枚举。禁用后所有USB设备连接都变得稳定。4.2 独家避坑技巧来自产线和Debug现场的血泪经验技巧一建立“烧录快照”档案告别重复踩坑每次成功烧录一个新固件立即用Flash Download Tool的Save Project功能保存一个.dlp项目文件。这个文件记录了所有参数芯片型号、串口号、波特率、每个bin文件的路径和地址、擦除模式、校验开关。下次同一块板子、同一个固件双击.dlp文件点Start即可无需重新配置。我在产线做首板验证时为每个模组型号建立了独立的.dlp档案库效率提升3倍。技巧二用esptool.py做终极验证不轻信GUIGUI成功不代表万无一失。烧录完成后立即执行esptool.py --port COM3 read_flash 0x1000 0x4000 bootloader_check.bin esptool.py --port COM3 read_flash 0x8000 0x1000 partition_check.bin esptool.py --port COM3 read_flash 0x10000 0x10000 app_check.bin然后用md5sum或sha256sum对比bootloader_check.bin与原始bootloader.bin的哈希值。完全一致才是真正的成功。这是我在交付客户前的强制Checklist。技巧三处理“半砖”板子的急救术如果烧录了错误的bootloader或启用了错误的安全配置导致板子无法进入Download Mode按BOOT无反应别急着扔。尝试更低的波特率在Flash Download Tool中将Baud Rate设为115200再按BOOTRESET。或者用esptool.py强制进入esptool.py --port COM3 --baud 115200 --before no_reset --after no_reset chip_id如果能读到chip_id说明ROM Bootloader还在只是通信参数不对。此时用esptool.py --port COM3 --baud 115200 erase_flash彻底擦除再用正确参数重烧。技巧四理解“地址偏移”的物理意义避免OTA灾难热搜词里有“esp32接入米家mesh”、“ros 2 humble micro-ros esp32”这些项目必然用到OTA空中升级。OTA要求application固件必须烧录在ota_0分区通常地址0x10000或ota_1分区通常地址0x110000。如果你把固件直接烧到0x10000但分区表里ota_0定义在0x20000那么OTA服务会找不到应用升级失败。我的建议永远用esptool.py --port COM3 partition_table partition-table.bin命令将分区表烧录到0x8000然后用esptool.py --port COM3 read_partition_table读回用文本编辑器打开确认ota_0的offset字段与你烧录固件的地址完全一致。这是OTA项目上线前的必检项。这些技巧没有一条来自官方文档。它们是我和团队在无数个凌晨、在客户现场、在产线流水线上用万用表、示波器和耐心一点一点抠出来的。它们不 glamorous但无比真实且每一次都能救命。5. 场景延展与工程化实践从烧录到量产交付的完整链条5.1 从单板调试到小批量生产的自动化演进Flash Download Tool的GUI界面天然适合单板调试和首板验证。但当你的项目从“做个Demo”走向“交付100台样机”手动点击就变成了瓶颈。这时就需要把它纳入自动化链条。阶段一批处理脚本Batch Script / Shell Script将Flash Download Tool的GUI操作转化为命令行调用。工具本身不提供CLI但其底层就是esptool.py。编写一个flash_all.batWindows或flash_all.shmacOS/Linux#!/bin/bash esptool.py --port /dev/cu.SLAB_USBtoUART \ --baud 460800 \ --before default_reset \ --after hard_reset \ write_flash \ --flash_mode dio \ --flash_freq 40m \ --flash_size 4MB \ 0x1000 bootloader.bin \ 0x8000 partition-table.bin \ 0x10000 firmware.bin运行此脚本效果与GUI点击Start完全一致但可以集成到CI/CD流程中。阶段二Python自动化脚本PySerial esptool对于更复杂的逻辑如自动检测串口号、烧录前读取芯片MAC、烧录后运行简单AT指令验证用Python控制。核心库pyserial控制串口、esptool调用烧录逻辑。示例片段import serial import esptool from esptool import ESPLoader # 自动查找可用串口 ports serial.tools.list_ports.comports() target_port [p.device for p in ports if CH340 in p.description][0] # 构建烧录命令 cmd [ esptool.py, --port, target_port, --baud, 460800, write_flash, --flash_mode, dio, --flash_freq, 40m, --flash_size, 4MB, 0x1000, bootloader.bin, 0x8000, partition-table.bin, 0x10000, firmware.bin ] # 执行并捕获输出 result subprocess.run(cmd, capture_outputTrue, textTrue) if result.returncode 0: print(烧录成功) else: print(烧录失败, result.stderr