从STM32无缝迁到GD32F103这事儿圈里传了很久有人说“直接烧啥都不用改”也有人说“坑多到想砸板子”。我自己的看法是两者同属 Cortex-M3 内核外设寄存器大部分兼容整体迁移成本确实低但“无缝”俩字得加个引号。真正的门槛不在代码而在烧录和启动这一层——偏偏网上教程多半只讲“Keil 里选个芯片型号就完事”把 ST-Link 在 GD32 上遇到的 BOOT0 相关怪问题一笔带过。这篇我就把从接线、驱动、MDK 配置到算法下载、Flash 锁死、BOOT0 各种坑的完整流程拆开讲保证你照着走一遍就能把程序烧进去顺带搞明白背后到底是怎么回事。这套方案适合谁手上有 STM32F103 老项目想平移到国产替代方案的工程师实验室里买了 GD32F103 核心板但被烧录卡住的学生以及纯粹想搞明白 BOOT0 到底是什么、为什么有时要拉高有时要拉低的好奇派。不绕弯子直接上干货。1. 迁移前的核心认知为什么 GD32F103 能“无缝”接 STM32 的班1.1 内核同源指令集天然兼容先放下烧录的事说说本质。STM32F103 和 GD32F103 用的都是 ARM Cortex-M3 内核这意味着两者执行 ARMv7-M 指令集机器码层面完全互通。你为 STM32F103 编译出来的 .hex 或 .bin 文件GD32F103 的 CPU 可以直接取指执行不需要重新编译也不需要做指令翻译。这是“无缝”二字的物理基础也是整个迁移故事最硬核的底气。但内核一样不代表整颗芯片一样。GD32F103 由国内厂商兆易创新设计虽然 pin-to-pin 兼容 STM32F103也就是引脚定义基本对齐但内部外设USART、SPI、I2C、定时器等的寄存器布局并非 100% 复制而是“高度相似 少量差异”。相似到什么程度呢大多数情况下ST 的标准外设库代码可以原样编译运行差异到什么程度呢某些外设的时钟分频系数、某些寄存器的默认值、某些标志位的清除方式会有细微不同。所以聪明人的做法是先平行烧录验证硬件再逐个外设做回归测试而不是天真的以为“烧进去能跑就万事大吉”。烧录只是第一步但第一步都走不顺后面全是空中楼阁。1.2 FLM 烧录算法ST-Link 能烧 GD32 的关键黑盒接下来的问题是ST-Link 明明是意法半导体的调试器凭什么能给 GD32 烧程序答案藏在 Keil MDK 的“烧录算法”Flash Loader Algorithm后缀 .FLM机制里。Cortex-M 内核的芯片内部 Flash 编程逻辑并不直接暴露给调试器。调试器只是通过 SWDSerial Wire Debug或 JTAG 接口对一个叫“Flash 控制器”的外设寄存器做读写。而不同厂商的 Flash 控制器寄存器地址、操作时序、解锁密钥都不一样所以调试器必须配合一个特定于芯片的 .FLM 文件才知道“擦除整个扇区时该往哪个地址写什么值”“编程一页数据时要不要先发解锁命令”。Keil MDK 的通用流程是点击 Download 按钮后MDK 先把 FLM 算法加载到芯片的 SRAM 中然后通过调试器控制 CPU 执行这个算法从而完成擦除、编程、校验。也就是说只要某个 FLM 文件适配 GD32 的 Flash 控制器ST-Link 就能烧 GD32。这就是整个流程跑得通的核心机制。而 GD32F103 之所以能复用 STM32F103 的 FLM是因为——至少在设计意图上——GD 的 Flash 控制器很大程度上参考了 ST 的实现。但这不等于 100% 保险后面我会讲我在实践中遇到的一个 Flash 校验失败的坑就是从这里来的。1.3 迁移前的准备清单动手之前先把家伙备齐避免烧到一半找东西。物料型号/规格作用与说明目标板GD32F103C8T6 最小系统板或自制板建议先用核心板验证流程别直接上产品板调试器ST-Link V2 或 V2 Clone淘宝几十块的克隆版也能用但驱动兼容性看人品杜邦线母对母 4 根以上连接 SWDIO、SWCLK、GND、3.3V开发环境Keil MDK 5.x建议 5.30项目编译和烧录主战场驱动ST-Link 驱动安装 MDK 时可选装装不上驱动后面全卡住辅助工具STM32 ST-LINK Utility / STM32CubeProgrammer读保护、整片擦除、查看选项字节时用得上顺带提醒一句如果你用 STM32CubeProgrammer简称 STM32CubeProg烧 GD32它自带的 STM32 系列 FLM 列表里本来就有 STM32F10x 的算法但能不能覆盖 GD32 的内部 Flash取决于 GD32 的 Flash 控制器的兼容程度。实测下来ST-Link Keil MDK 的组合兼容性最好这也是为什么我强烈推荐用这条路线而不是 J-Flash 或者 CubeProgrammer 单独硬上。2. 烧录环境搭建与 ST-Link 接线实操2.1 接线方式四条线的事别搞复杂STM32F103 和 GD32F103 都支持 SWD 和 JTAG 两种调试接口。JTAG 要占用 5 个引脚而 SWD 只要 2 根信号线SWDIO、SWCLK加电源和地省引脚、省线序绝大多数场景用 SWD 就够了。标准接法如下ST-Link V2 GD32F103 目标板 3.3V ---------- 3.3V (VDD) GND ---------- GND SWDIO ---------- PA13 (SWDIO) SWCLK ---------- PA14 (SWCLK)注意几个要点供电策略如果你的目标板上有自己的稳压电路比如 AMS1117 从 5V 转 3.3V最好用目标板自供电ST-Link 只接 GND、SWDIO、SWCLK 三根线。如果目标板是裸的最小系统没有板载稳压器可以让 ST-Link 的 3.3V 输出给它供电但要确认板子总电流不大ST-Link V2 的 3.3V 输出能力一般只有 50mA 到 100mA 左右带个最小系统没问题带带 LCD 背光、Wi-Fi 模块就吃力了。线长控制SWD 的时钟频率通常跑 4MHz 到 8MHz杜邦线超过 20cm 就容易出现信号反射导致连接不稳定。我习惯把 SWD 线控制在 10cm 以内这是吸取了当年在飞线上踩信号的教训。勿热插拔烧录最好在断电状态下完成接线再上电。热插拔有可能导致 SWD 引脚电平冲突轻则烧录失败重则损坏调试器 IO。2.2 驱动安装与设备管理器验证ST-Link 插上电脑后正常会弹出驱动安装提示。如果设备管理器里出现“STM32 STLink dongle”或者“STM32 ST-LINK”相关设备说明驱动正常。如果出现黄色感叹号手动装一下 Keil MDK 安装目录里的驱动即可。顺带说一句淘宝便宜 ST-Link V2 的驱动兼容性是个大坑。有些山寨版在 Win10/Win11 下会识别成“Unknown Device”怎么装驱动都没用。我的建议如果你要长期在 GD32 上调试买正版 ST-Link/V2 或者国产的 DAP-LinkCMSIS-DAP 协议后者在 Keil 里同样是免驱即用而且便宜又稳烧 GD32 也是一把好手。对你没看错DAP-Link 也能烧只要 Keil 里能识别调试器走的都是 FLM 算法烧录这条路。2.3 Keil MDK 工程配置要点打开你的 Keil MDK 工程按下图思路逐项配置Device 芯片型号选择点魔术棒Options for Target在 Device 页签里选择 STMicroelectronics STM32F1 Series 下的 STM32F103C8 或你实际使用的型号。这里不需要选 GD32原因后面会说。Debug 页签右栏下拉框选择“ST-Link Debugger”点击旁边的 Settings。弹出的窗口中确认 SW Device 能识别到 Cortex-M3 SW-DP如果识别不到先别急着烧录查线序和供电。Utilities 页签勾选“Use Debug Driver”因为我们要用 ST-Link 作为烧录器下面 Flash Download 选项框里点击 Settings 查看当前烧录算法列表。Flash Download 框里就是 FLM 算法的管理界面。如果你当前列表里没有 STM32F10x Flash 相关的算法点 Add 添加STM32F10x Flash 512kB (或者根据容量选对应的)重点来了这里选择 STM32F10x Flash 512kB 的算法对应的 Flash 起始地址是 0x08000000容量 512KB扇区大小 1KB 到 4KB 不等。GD32F103C8T6 内部 Flash 只有 64KB但算法选择 512KB 的也没问题因为实际烧录时是根据代码大小来操作扇区的只要不超过片上 Flash 物理容量就行。如果你的 GD32 是 C 系列64KB但程序超了 64KB那别折腾烧录了是选型问题。2.4 Keil 中 ST-Link 的 SWD 速度设定前面提到 SWD 线长会影响稳定性那么具体怎么调在 Debug 页签的 Settings 里找到 Max Clock 下拉框默认可能是 4MHz 或 1.8MHz。如果你的板子布线质量一般飞线、面包板、长排针把 SWD 时钟降到 1MHz 或 500kHz 再试往往能解决一大半“连接不上”的报错。这个经验我反复验证过SWD 通信速度不是越快越好它取决于信号完整性和目标板复位电路的质量。GD32 的复位电路和 STM32 参考设计几乎一致但如果你板子上的复位电容取值偏大比如 1uF可能会拖慢 SWD 的复位时序这时候降速就非常管用。3. 核心烧录流程从编译到固件落板3.1 代码编译与输出文件设置烧录之前先确认工程能编译通过。点击 BuildF7生成目标文件。Keil 默认会生成 .axf 文件同时根据配置会生成 .hex 文件。在魔术棒 Output 页签里勾选“Create HEX File”否则烧录时会出现“No Flash Device”或者没有可烧录文件的情况。验证输出文件的方式有两种编译信息窗口会显示 Program Size 的具体值比如 Code、RO-data、RW-data、ZI-data 四项。打开工程目录下的 Objects 或 Listings 文件夹查看 .hex 是否存在。烧录前心里要有数你的程序占多大 Flash、多少 RAM别等下载时报溢出才回头砍功能。GD32F103C8T6 的 64KB Flash 和 20KB SRAM 比我 10 年前用 STM32F103C8T6 时紧张多了做 Bootloader App 方案时这个容量预算必须提前算好。3.2 点击 Download 前后发生了什么按下 F8Keil 的 Download 快捷键整个烧录流程大致如下初始化调试器ST-Link V2 复位、连接目标板。通过 SWD 读取目标板内核信息确认是 Cortex-M3。将 FLM 算法加载到 SRAM 中通常加载到 0x20000000 起始的 RAM 区域。执行 FLM 算法的 Init 函数初始化 Flash 控制器。根据 MDK 的配置执行 Erase擦除操作通常选择“Erase Full Chip”或“Erase Sectors”。逐页编程Program每页通常为 1KB 或 2KB。编程完成后执行 Verify校验逐字节读回 Flash 内容与缓冲区比对。复位目标板并运行用户程序。每一步背后都有对应的寄存器操作和时序要求。如果中途任何一步失败Keil 会弹窗报错。这就是为什么有些现象看起来“烧录失败但代码能跑”——有时候程序其实写进去了只是 Verify 环节因为 Flash 控制器差异读回结果不对而 CPU 已经能从 Flash 取指执行了这种情况最迷惑人。3.3 实测烧录演示与现象记录拿我手上一块 GD32F103C8T6 蓝色核心板做示范。板子上电后3.3V 供电正常复位键按下可以复位。ST-Link V2 接好后设备管理器识别正常。Keil 工程配置好 ST-Link Debugger选 STM32F103C8 芯片Flash 算法选 STM32F10x Flash 512kB。点击 Download 后输出窗口打印Load C:\\project\\GD32_Test\\Objects\\GD32_Test.axf Programming Done. Verify OK.三行输出干净利落。这说明 GD32 的 Flash 控制器对于 ST-Link 标准 FLM 算法是完全兼容的在不碰 BOOT0 的情况下BOOT0 默认拉低程序正常烧录并运行。但这里有个特别容易让人困惑的现象——你在 Keil 里选中了 STM32F103C8 芯片__STMicroelectronics__宏定义的是 ST 的标准外设库但你拿它编译出来的代码能烧进 GD32。这说明两个厂商的寄存器定义在绝大多数路径上是一致的但别忽略我在 1.1 节说的“细微差异”。比如 GD32 的 USART0 时钟使能位在 RCC_APB2ENR 的位 14和 STM32F103 相同但 GD32 的 ADC 时钟分频在某些型号上默认值不同这就可能导致 ADC 采样率偏差需要通过配置代码显式修正。3.4 代码层面的“无缝”迁移实践既然烧录打通了代码怎么迁我的习惯做法是保持工程芯片型号不变直接替换启动文件与系统初始化文件。具体来说从 GD32 官方固件库GD32F10x Firmware Library中复制system_gd32f10x.c和gd32f10x.h等核心文件到工程中替代 ST 的对应文件。将启动文件startup_stm32f10x_hd.s替换为startup_gd32f10x_hd.s也可以不换实测 ST 启动文件在 GD32 上也能跑但换了更规范因为 GD32 启动文件里向量表对应的中断处理函数名称是 GD32 库的命名。编译。大部分功能代码GPIO、USART、I2C、SPI、定时器因为寄存器兼容无需改动。逐个外设做验证重点测时钟频率是否准确用定时器测量 1ms 是否真 1ms因为 GD32F103 的主频虽然也可以跑到 72MHz但它的时钟树配置和 PLL 倍频系数需要按 GD 的库来初始化用 ST 的 SystemInit 代码虽然也能跑到 72MHz但某些外设时钟分频会出现偏差。这套流程走下来比直接硬怼 ST 库代码在 GD32 上跑要省心不少。因为 GD 的固件库更新维护是针对自家芯片的寄存器差异都处理过了你不需要自己去翻手册逐条排查。4. BOOT0 深度避坑为什么有时要拉高有时要拉低4.1 BOOT0 和 BOOT1 的作用机制现在聊标题里点名的 BOOT0。很多新手烧录失败最后发现是 BOOT0 的问题但你要是问他 BOOT0 到底干嘛的他说不清楚。STM32/GD32 的启动模式由 BOOT0 和 BOOT1注意GD32 中通常叫 BOOT1对应芯片引脚 PB2两个引脚的组合决定。F103 系列常见配置BOOT0BOOT1启动模式起始地址0X任意从主 Flash 启动0x0800000010从系统存储器启动ISP 引导程序0x1FFFF00011从内置 SRAM 启动0x20000000这句话翻译成大白话BOOT00芯片上电后从你烧程序的那块 Flash 开始执行BOOT01、BOOT10芯片上电后执行芯片出厂固化的一段引导程序System Bootloader它可以通过串口等接口接收数据并写入 FlashBOOT01、BOOT11芯片从 SRAM 执行相当于临时跑一个“内存中的程序”。这里有一个致命的理解误区不少人以为 BOOT0 拉高了就能烧录烧的时候把 BOOT0 接 3.3V烧完跑程序发现没动静然后陷入“为什么我烧录了不运行”的困惑。真相是通过 ST-Link/SWD 烧录根本不需要动 BOOT0。SWD 调试接口直接控制 CPU把 FLM 加载到 SRAM 后执行 Flash 编程和 CPU 从哪启动没有半毛钱关系。也就是说BOOT0 维持默认低电平接 GNDST-Link 照烧不误。那 BOOT01 的串口 ISP 模式什么时候才用当你没有 SWD 调试器、只能用串口烧录时必须把 BOOT0 拉高、BOOT1 拉低让芯片进入系统存储器引导模式然后通过串口把固件发给内置 Bootloader。这就是很多“只有 BOOT0 的情况如何下载固件”这类问题的答案。4.2 烧录时 BOOT0 到底该拉高还是拉低让我把这个场景讲透。场景一你有 ST-Link 或 DAP-Link 这类 SWD 调试器。BOOT0 拉低默认状态不需要任何额外操作。ST-Link 烧完直接运行程序从 Flash 启动。这是最推荐的实践。场景二你没有调试器只有 USB-TTL 串口模块。BOOT0 拉高、BOOT1 拉低上电进入系统 Bootloader。用串口工具如 FlyMcu、MCUISP选择对应串口发送固件。完成后把 BOOT0 拉低复位程序开始运行。场景三你的固件是做 IAPIn-Application Programming升级的也就是要通过 App 自己升级自己。这时候 BOOT0 必须保持低从主 Flash 启动因为 IAP 的主机一般是 Bootloader 程序就写在 Flash 里。你如果上电拉了 BOOT0系统跑的是厂家的串口 Bootloader而不是你自己的 IAP 主机升级流程就跑乱了。经常有人在 GD32 论坛问“GD32F103 无法通过串口 ISP 下载”排查一大圈后发现是串口 TX/RX 接反了或者BOOT1 没接对。GD32 的 ISP 串口是 USART0PA9 TX、PA10 RX别接错。4.3 BOOT0 拉高后出现的“程序不运行”怪象有几次用户描述的问题几乎一模一样烧录成功但板子上电没反应。远程看不到硬件我只能引导他测量 BOOT0 引脚电平结果十有八九 BOOT0 被拉到了 3.3V。原因通常是他在面包板/核心板上飞线调试BOOT0 默认有下拉电阻或者核心板设计时已经固定拉低但他在之前尝试串口 ISP 时把 BOOT0 接到了 VCC烧录完成后忘了改回来。上电后 CPU 进入系统存储器启动模式你的 App 在 Flash 里躺着一个字节都没执行。这里有个很隐蔽的小技巧如果 BOOT0 在 3.3V 而你的芯片里有有效程序上电后程序不会从 Flash 启动但如果你在 Keil 里点调试DebugST-Link 连接后默认行为是复位并从复位向量执行我实测很多情况下程序是能跑起来的这会让问题更加扑朔迷离。最终判断标准只有一个检查 BOOT0 电平。4.4 核心板与自制板的 BOOT0 设计差异市售的 STM32F103C8T6 蓝色核心板BOOT0 默认通过 10K 电阻下拉到 GND板上自带一个跳线帽或按钮用于切换。GD32F103 的核心板比如某些国产蓝色板设计思路相同。但自制板就未必了。如果你画的是自己的小板子BOOT0 引脚的处理有两种常见方案方案 A推荐BOOT0 经 10K 电阻下拉到 GND同时预留一个 2.54mm 跳线针需要 ISP 时用跳线帽短接到 3.3V。这样默认从 Flash 启动调试和 IAP 都顺畅。方案 BBOOT0 直接接 100nF 电容到 GND再串联一个 0 欧电阻可调接到 3.3V。这种方式适合生产定型产品出厂后不再进 ISP 模式的场景。BOOT0 悬空是大忌。有些所谓“最小系统板”偷工减料BOOT0 只挂了个电容依靠内部弱下拉维持低电平。这种板子在实验室常温下没事但环境一变或引脚受干扰BOOT0 可能误触发高电平表现就是“程序莫名其妙不跑了”。5. 烧录失败、Flash 锁死与读保护ST-Link 常见故障排查实录5.1 “No Target Connected” 连接失败怎么查这是 ST-Link 烧录最常见的报错没有之一。Keil 提示 “Cannot connect to target”或者 ST-Link Utility 提示 “No target connected”。排查顺序我列一下按优先级从高到低检查接线SWDIO 接 PA13SWCLK 接 PA14GND 必须共地。我见过一半以上的情况是杜邦线松了或者插错排针。检查供电目标板有没有上电测 3.3V 引脚电压是否正常。ST-Link 的参考电压检测引脚VTREF在某些版本上是独立的如果你的调试器要求 VTREF 接入目标板供电只有 GND/SWDIO/SWCLK 三根线是不够的——ST-Link V2 的 3.3V 引脚就是 VTREF所以三根线通常也能用但克隆版不好说。降速把 SWD 时钟从 4MHz 降到 1MHz 以下试试。很多“线太长、板子太差”的连接问题降速就解决了。复位电路检查目标板复位引脚是否被外部器件拉低如果复位一直被拉低CPU 始终处于复位状态SWD 也无法正常工作。拔掉复位引脚上的外部电容/按键测试一下。内核是否进入低功耗如果你的程序已经运行起来并且进入了 STOP/STANDBY 模式SWD 会失效。这时需要把 BOOT0 拉低并强制复位连接到调试器。这里有个非常容易踩的坑GD32F103 的 SWD 引脚在程序里被重映射或禁用了。比如你在代码里调用了GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE);这会把 PA15、PB3、PB4 释放为普通 IO但 PA13/PA14SWDIO/SWCLK不受影响。如果你把整个 SWJ 都禁用GPIO_Remap_SWJ_Disable那 PA13/PA14 都变成普通 IOST-Link 就彻底连不上了。解决办法是用串口 ISP 模式整片擦除或者按住复位键的同时点击连接如果运气好 Flash 里跑的程序还没把引脚全占了。“程序烧录一次成功第二次就连接不上”的经典案情十有八九是这个原因。5.2 “Flash Download Failed - Device ID incorrect” 怎么破另一个高频报错Device ID incorrect器件 ID 不正确。出现这个错误一般是调试器读到了目标芯片的 Device ID但和你 Keil 工程里选的芯片型号不匹配。比如你选了 STM32F103C8Device ID 应为 0x410而 GD32F103 某些批次返回的 Device ID 是 0x411 或 0x413。这种情况下 Keil 会先拉响警报。解决办法很简单在 Device 页签里选择“更大的兼容型号”。比如选 STM32F103RB 甚至 STM32F103ZE让 Keil 对 Device ID 的校验范围更宽松。如果你用的是 STM32F103C864KB选 STM32F103RB128KB算法和 Flash 范围都能覆盖编译出来的代码也能烧进 GD32。注意 Flash 大小不能超过目标芯片物理容量否则校验阶段可能出现地址越界。如果你用 STM32CubeProgrammer 连接它比 Keil 更严格会在连接阶段就校验 Device ID 与型号是否匹配所以我才说 Keil 路线更省事它给了你“换个大型号蒙混过关”的操作空间。还有一个衍生坑如果你把 GD32 的读保护RDP打开了ST-Link 连接时会被拒之门外。左侧选项字节里 RDP Level 设成了 1芯片的调试接口基本瘫痪任何调试器都无法直接读 Flash。解除方法是整片擦除Mass Erase让 RDP 回到 Level 0。注意整片擦除会清掉所有 Flash 内容包括你的 Bootloader。5.3 “Programming failed at address 0x08000000” 的 Flash 校验失败烧录到一半报 “Programming failed at address 0x08000000”让人头大。这个问题的根源我在 1.2 节埋了伏笔GD32 的 Flash 控制器和 STM32 并非完全一致。标准 STM32F10x FLM 算法在擦除和编程时序上和 GD32 兼容度 99%但遇到某些特定操作序列时可能触发 GD32 Flash 控制器的状态机异常。解决方法按优先级排序检查供电稳定性Flash 编程时内部电荷泵需要较稳定的电压3.3V 如果被拉低到 3.0V 以下Flash 控制器很容易编程失败。用万用表量一下目标板 3.3V不要在 USB 供电不稳的扩展坞上调试。更换擦除方式在 Flash Download 设置里把 Erase Full Chip 改回 Erase Sectors或者反过来试试。有些 GD32 批次对全片擦除命令的某些中间态处理异常逐扇区擦除更稳。启动文件与算法不符如果你追加了其他厂商的 FLM 算法比如顺手加了 GD32 的官方 FLM建议删除只保留 STM32F10x Flash 算法。叠加多个算法在 Keil 里基本没意义还可能因算法选择逻辑错乱导致烧录失败。降低 SWD 速度上面说了Flash 编程期间如果调试链路本身就不稳校验回读数据出错也会报 Programming failed。降到 1MHz 试试。5.4 一个真实翻车案例烧录“成功”但程序跑飞分享一个我印象很深的案例。用户用 ST-Link 给 GD32F103C8T6 烧自己写好的点灯程序Keil 提示 “Programming Done. Verify OK.”但板子上的 LED 就是不闪。他把代码检查了无数遍甚至怀疑芯片坏了。我让他量 BOOT0 电压——3.3V。问题瞬间定位。他是这样翻车的这块板子是二手淘来的上家为了便于串口下载把 BOOT0 通过跳线帽接到了 3.3V没拆。他拿到手后在 Keil 里烧录因为 ST-Link 烧录不需要关注 BOOT0所以一路绿灯但程序根本没从 Flash 启动。他花了两个多小时排查代码逻辑完全没想到是启动模式的问题。这个案例告诉我们两件事烧录成功 ≠ 程序运行。启动模式不对一切白搭。遇到“烧录正常、运行异常”第一件事就是检查 BOOT0 电平。5.5 常见问题速查表故障现象可能原因快速解决办法No Target Connected接线错误、未供电、SWD 速度过高、复位拉死检查 SWDIO/SWCLK/GND降速到 1MHz检查复位电路Device ID incorrect工程型号与芯片 ID 不匹配选更大兼容型号或直接用 STM32F103ZEFlash Download Failed at 0x08000000供电不稳、篇章擦除方式不对、FLM 冲突改善供电切换擦除模式只保留单个 FLMProgramming Done 但程序不运行BOOT0 被拉高程序未从 Flash 启动BOOT0 拉低复位下载一次后第二次无法连接SWJ 引脚被禁用/重映射、读保护开启串口 ISP 整片擦除或按住复位连接ST-Link 驱动感叹号山寨调试器驱动不兼容换原版 ST-Link 或 DAP-Link6. 进阶技巧让迁移和烧录链路更稳的几个小习惯流程走通了我再分享几个自己在实际项目中沉淀下来的习惯能让这一步“烧录”环节的稳定性提升一个台阶。6.1 用脚本固化烧录流程告别手点按钮Keil 的 F8 下载好用但生产或者团队协作场景下它不够自动化。我的做法是写一个批处理脚本调用 ST-Link 的命令行工具比如 STM32 ST-LINK Utility 的 CLI 版本或 Keil 的命令行编译接口实现一键编译 烧录。ST-Link CLI 的基本用法类似于STM32_Programmer_CLI.exe -c portSWD modeUR -e all -w firmware.hex -v -rst这段命令的含义是连接 SWD 端口模式为热插拔URUnder Reset整片擦除写入 firmware.hex校验复位运行。用这种命令跑批量烧录效率高得多也不容易手滑点错。6.2 读保护选项字节的正规玩法GD32F103 同样支持读保护RDP。如果你做产品不希望别人用 ST-Link 直接读走固件可以把 RDP 级别设为 1。但务必在生产流程里测试清楚RDP1 后再次烧录必须整片擦除才能解除而且整片擦除的时序比普通擦除慢很多产线烧录节拍会受影响。还有一种折中是开启“写保护”WRP让特定 Flash 区域不可编程但可读。这比 RDP 温和适合做 Bootloader 保护。6.3 预留 SWD 接口的硬件设计建议如果你的产品板是自己画的SWD 接口建议用 4 针3.3V、SWDIO、SWCLK、GND或 5 针加复位 NRST的标准座而不是只在 PCB 上留四个过孔。因为量产调试、产测、售后返修都要插调试器没有标准座会非常痛苦。另外SWDIO 和 SWCLK 引脚建议串联 33Ω 到 100Ω 的匹配电阻靠近 MCU 放置能有效抑制振铃和过冲。这个细节在批量生产时能避免很多“某些板烧录失败”的诡异问题。6.4 GD32F103 的 IAP 升级链路设计最后说说标题热词里反复出现的 GD32F103 IAP 升级。如果你要在 GD32F103 上做 IAPBootloader App 方案需要注意Bootloader 和 App 的 Flash 分区要提前规划好。比如 64KB FlashBootloader 占 16KB0x08000000 - 0x08003FFF App 从 0x08004000 开始。App 工程的起始地址要改在 Target 页签的 IROM1 起始地址设成 0x08004000 Size 相应减小同时要在代码里设置向量表偏移在 SystemInit 之后、外设初始化之前执行SCB-VTOR 0x08004000。App 内不要再初始化将用于 IAP 的通信外设和 Bootloader 重复否则两者会打架导致跳转后卡死。跳转函数要用__set_MSP()设置主堆栈指针同时确认跳转前关闭所有中断、恢复外设默认状态。细节很多建议单独写一篇但前提是你的基础烧录链路是通的否则 IAP 无从谈起。7. 写在最后一点实践体会从 STM32F103 迁到 GD32F103烧录这一关只要掌握了 ST-Link Keil FLM 这条链路其实半天就能打通。真正花时间的不是工具而是理解 BOOT0 的启动逻辑、Flash 读保护机制和 SWD 引脚被禁用这些“隐性陷阱”。我个人的习惯是拿到一块新 GD32 板子第一件事不是写代码而是先确认三件事BOOT0 接地没有、SWD 引脚有没有被占用、芯片能不能被 ST-Link 识别。这三件事确认完后面全是坦途。另外一个我没提到但你肯定会遇到的细节ST 的库函数和 GD 的库函数在部分外设 API 名称上有差异比如 ST 的GPIO_InitTypeDef在 GD 的旧版本库里被命名为gpio_parameter_struct。这是因为 GD32 后期推出了一套风格接近标准库但成员命名不同的固件库。所以如果你想偷懒不改代码用一套“双平台兼容”的写法建议自己封装一层硬件抽象层而不是直接依赖厂商库。这也是为什么有人说“无缝迁移”有人说“坑很多”——取决于你项目的代码风格和用的库版本。最后再分享一个排查锦囊如果哪天 ST-Link 怎么都连不上 GD32而你检查了所有硬件都没问题试着把 BOOT0 临时拉高再复位一下。虽然最终工作模式要求 BOOT00但这个“歪招”有时候能骗过 Flash 里的异常程序让调试器抢先接管等连接成功后再把 BOOT0 拉回来。这招不是官方文档里的标准流程但我实测过几次有效。技术这东西有时候就是经验比说明书管用。