CH32V103系列这几年在国产低成本RISC-V MCU里算是露脸比较多的片子，Cortex-M3内核兼容的引脚排列、几块钱的售价、还带USB和以太网控制器，很多人做小批量产品时都动过它的心思。但片子便宜是一回事，能不能顺利烧写又是另一回事。我最早接触这块芯片时，被烧写折腾得够呛，串口烧写失败、Link连接不上、驱动装不上、Flash下载到一半报错，各种问题都遇到过。

这篇文章就围绕ch32v103xx的烧写展开，把主流的几种烧写方式、工具链选择、配置细节、失败排查逐个过一遍。不管你是刚拿到开发板想点个灯，还是做小批量产需要稳定烧录方案，都能在这里找到能直接用的东西。

1. 烧写方案的选择：别一上来就扎进串口里

很多人拿到CH32V103第一反应是找串口烧写，因为STM32时代养成的习惯，BOOT0拉高、串口一接、FlyMcu一点就完事。CH32V103确实支持串口ISP，但如果你对它不熟悉，这个看似熟悉的路径恰恰是坑最多的地方。烧写之前先搞清楚这片子到底有哪几条路可以走，再根据你的场景挑一条，比盲目试错省时间得多。

1.1 四类主流烧写方式横向对比

CH32V103的烧写路径大致可以分成四类：WCH-Link调试器烧写、串口ISP烧写、SWD/JTAG调试口烧写、以及官方脱机烧录器批量烧写。每种的底层逻辑和适用场景都不一样，我先把它们放在一张表里说清楚。

这四类里，日常开发最推荐WCH-Link。它不仅支持CH32V103，还覆盖了CH32全系列和CH57x、CH58x等蓝牙芯片，一个几十块钱的小东西能通吃沁恒自家的片子。串口ISP则适合在没有调试器的环境下救急，或者产品需要远程升级Bootloader时作为备选通道。脱机烧录器做小批量生产很划算，但如果只是几十片样板，没必要额外投这个钱。

1.2 为什么优先推荐WCH-Link而不是串口ISP

我在实际使用中明显感觉到，CH32V103的串口ISP对时序要求比STM32更敏感，这也是网上搜“串口烧写失败”能搜出一堆帖子的根本原因。串口ISP依赖芯片内部Bootloader的时序配合，而CH32V103的Bootloader在部分早期版本芯片上对波特率偏差、起始位判定比较挑剔，尤其是用CH340这类USB-TTL时如果硬件设计上晶振精度不够，很容易出现握手失败。

WCH-Link走的是SWD协议，芯片上电后调试接口默认就是开启的，不依赖BOOT引脚状态，对电源稳定性的要求也没有串口ISP那么高，连接成功率几乎是百分之百。所以我的建议很直接：只要你是做开发调试，别犹豫，直接上WCH-Link。串口ISP留到需要远程升级固件或者手头实在没有调试器时再用。

2. WCH-Link烧写全流程：从接线到下载的完整记录

WCH-Link烧写CH32V103看起来简单，里面还是有不少细节。接线、驱动、工具版本、目标芯片供电这些环节只要有一个没搞对，就容易卡住。下面按我日常操作的顺序，一步步把整个过程写清楚。

2.1 接线与硬件环境搭建

CH32V103的SWD接口只有两根信号线，SWDIO和SWCLK，加上电源和地线一共四根。WCH-Link的引脚定义在官方文档里写得很清楚，但不同批次的小板子丝印位置可能有差异，接线前务必对照你手上那块的丝印确认，别想当然。

标准的四线接法如下：

• WCH-Link的3V3接目标板3V3，这个必须接，因为WCH-Link的SWD输出电平是3.3V，共地之外还要共电源，否则电平参考不一致会导致通信不稳定。
• WCH-Link的GND接目标板GND。
• WCH-Link的SWDIO接目标板的SWDIO引脚，在CH32V103上这个引脚是PA13。
• WCH-Link的SWCLK接目标板的SWCLK引脚，在CH32V103上对应PA14。

有些WCH-Link板子上SWDIO和SWCLK丝印写的是DIO和CLK，个别版本甚至没有SWDIO/SWCLK丝印，只有一排排针。这种情况下可以参考官方原理图确认引脚定义，核心点是找到那个标着SWDIO和SWCLK的排针。接线时还要注意目标板最好由自己的电源供电，不要把WCH-Link同时当成电源模块给整个系统供电，尤其是目标板上还有电机、继电器这类大电流外设时，WCH-Link的LDO撑不住。

2.2 驱动、工具链与固件版本匹配

WCH-Link连接电脑后，需要安装驱动。Windows系统一般会自动识别，如果识别不了，去沁恒官网下载WCH-Link驱动包手动安装。驱动装完之后，打开设备管理器，在端口或者通用串行总线设备里能看到WCH-Link设备，这一步正常了再继续。

烧写工具用的是WCHISPTool，这个工具集成了ISP和WCH-Link两种模式，下载地址在沁恒官网的CH32V103页面下。工具版本建议用最新的，我遇到过老版本工具不识别新批次芯片的情况，版本差异看起来不起眼，实际影响很大。

这里有个容易踩的坑：WCH-Link出厂固件默认配置可能导致连接报错。新版本WCH-Link支持在WCHISPTool里切换目标芯片系列，如果软件提示找不到目标芯片，先检查一下WCH-Link的Target系列设置是不是选到了CH32V103。不同系列之间切换后，电平逻辑和时序参数不同，选错就会连接失败。

2.3 WCHISPTool操作步骤与关键参数详解

工具打开后，界面不算复杂，但每个下拉框都有含义。我按实际操作顺序拆开说。

第一步，在软件界面的“芯片系列”下拉框里选择CH32V103，然后点击“连接”按钮。软件会自动通过WCH-Link读取芯片信息，连接成功后状态栏会显示芯片型号和Flash容量等信息。如果连接失败，软件会弹出错误提示，常见的是“连接目标芯片失败”或“WCH-Link未连接”。

第二步，点击“擦除”按钮，清空Flash。开发阶段每次下载前擦除是好习惯，能避免旧程序残留导致的新程序行为异常。如果芯片开了读保护，擦除操作还能顺带解除保护，但代价是所有Flash内容都会丢失，包括你之前烧进去的程序和任何存在Flash里的数据。

第三步，在“固件文件”区域加载你要烧写的hex或bin文件。沁恒官方提供的例程工程直接编译出来的通常是hex文件，这个格式包含了地址信息，烧写时不需要额外指定起始地址。如果你用的是bin文件，需要手动填写烧写起始地址，CH32V103的Flash起始地址是0x08000000，填错了程序下载进去也跑不起来。

第四步，点击“下载”按钮，等待进度条走完。下载完成后软件会提示烧写成功，如果过程中出现“校验失败”之类的报错，先别急着换芯片，多数情况下是接线太长或者电源不稳造成的。

2.4 一个新手最容易忽略的细节：目标芯片电源

我在帮朋友排查WCH-Link连接失败时，发现一个很有意思的现象：目标板用USB供电时能正常烧写，换成独立电源适配器供电就连接不上。查了半天，问题出在适配器输出电压纹波太大，导致SWD时序在电平跳变时出现抖动。CH32V103的SWD接口对电源质量有一定敏感度，供电纹波大的时候通信就容易失败。

所以烧写时要么直接让WCH-Link给目标板供电，要么确保目标板电源稳定没有明显纹波。如果你必须用外部电源，建议在目标板的3.3V和GND之间加一个10uF左右的钽电容或者陶瓷电容，能明显提升烧写成功率。这个经验在我后来给客户做产线治具时也用上了，效果很稳定。

3. 串口ISP烧写：Bootloader的正确打开姿势

串口ISP是CH32V103烧写绕不开的一条路，尤其是手头没有调试器的时候，USB-TTL模块就能完成烧写。但串口ISP相比SWD多了不少变量，BOOT引脚状态、串口引脚接线、软件配置、波特率选择，每个环节都能让你失败得莫名其妙。这一节把串口ISP烧写的完整流程和底层原理拆开说。

3.1 BOOT引脚配置：启动模式决定你能不能进入ISP

CH32V103上电后从哪个地址执行，是由BOOT0引脚的电平状态决定的。串口ISP烧写的核心就是把芯片引导到系统存储器中预置的Bootloader程序，这个Bootloader负责接收串口数据并写入Flash，而它要运行起来，BOOT0引脚必须处于高电平状态。

BOOT0引脚是芯片的Pin 44，在LQFP48封装下位于右下角区域。常见的最小系统板上，BOOT0引脚会通过一个跳线帽或者拨码开关接到GND或3.3V。接线要点如下：

• 烧写前，把BOOT0接到3.3V高电平，然后给芯片上电或复位。
• 烧写完成后，把BOOT0恢复到GND低电平，再次复位让用户程序正常启动。

这个逻辑很好理解，高电平让芯片从系统Bootloader启动，低电平让芯片从Flash启动用户程序。实际操作中很多人烧写失败就是因为忘记拉高BOOT0，芯片上电后直接跑的是Flash里已有的旧程序，串口自然没有反应。

另外要注意，CH32V103的串口ISP使用的是USART1，对应的引脚是PA9(TX)和PA10(RX)。USB-TTL模块和芯片之间需要交叉连接，即USB-TTL的TX接芯片的PA10(RX)，USB-TTL的RX接芯片的PA9(TX)。这个交叉关系说三遍都不为过，好多失败案例都是因为用户直接TX接TX、RX接RX，串口当然收不到任何数据。

3.2 串口参数与目标文件选择的实操记录

硬件环境准备好后，软件这边选择串口ISP工具。CH32V103虽然是RISC-V内核，但串口ISP的通信协议沿用了沁恒一贯的方案，WCHISPTool软件在串口模式下直接支持它。操作流程如下。

打开WCHISPTool，接口模式选“ISP”，串口选择你USB-TTL对应的COM口号。波特率选项里有1200、2400、4800、9600、57600、115200等多个档位，理论上Bootloader支持自适应波特率，但我实测下来固定选择115200最稳，9600也可以，再高如921600反而容易出问题。

加载固件文件时，同样推荐使用hex格式。点击“下载”前，确保BOOT0已经拉高、芯片处于复位状态，然后再点下载。工具会先发送握手命令，芯片进入Bootloader后回响应，然后开始数据传输。整个过程的时序是：断电→设置BOOT0高→上电→打开工具选好串口→加载文件→点击下载→等待完成→断电→BOOT0恢复低→重新上电运行。

如果你看到软件提示连接成功但下载进度一直不动，大概率是波特率太高导致的数据传输错误。降低波特率到9600再试一次，很多问题就消失了。串口ISP在115200波特率下烧写32KB的固件，大约需要十几秒，不算快但完全可以接受。

3.3 串口ISP失败的最大元凶：晶振与Bootloader版本

网上关于CH32V103串口烧写失败的求助帖里，有个高频原因是外部晶振的问题。CH32V103的串口ISP Bootloader运行时的时钟来自芯片内部HSI，但握手成功后实际数据传输时的波特率校准依赖芯片外部晶振的精度。如果你的板子外部晶振焊接不良或者频率偏差超过一定范围，Bootloader计算出的波特率就会和实际不符，表现就是握手偶尔能成、下载必然失败。

排查方法很简单：测一下OSC_IN和OSC_OUT引脚之间的晶振是否正常起振，或者直接换一个已知完好的晶振。另一个办法是降低串口波特率，波特率越低对时钟偏差的容忍度越大。我之前在产线上遇到过一批板子串口烧写时好时坏，最后定位到是晶振批次问题，换成高精度晶振后问题彻底消失。

这里顺带提一句Zynga烧写的对比，很多做Zynq开发的朋友遇到的是另外一个维度的麻烦：Zynq的启动镜像需要BOOT.BIN打包FSBL、SSBL和bitstream，烧写到QSPI Flash还需要专门的Programming Flash镜像，这块板和CH32V103的玩法完全不同，一旦在你脑海里把两者烧写方式搞混，会在调试上浪费大量时间。回到CH32V103，记住它就是一颗MCU，烧写思路按照单片机的方式走，反而不会出大问题。

4. 台式机与产线上的烧写差异：脱机烧录与批量生产方案

前面聊的开发阶段烧写，强调的是灵活和调试方便。但做产品到了小批量产阶段，用USB-TTL一根根线戳着烧写效率太低，也容易出错。这一节聊聊脱机烧录和批量烧写方案，给你一个从开发过渡到生产的安全路径。

4.1 脱机烧录器：免PC烧写，产线神器

沁恒官方有WCH脱机烧录器，它的工作方式很直接：先用PC端软件把固件下载到脱机烧录器内部的存储空间里，然后把脱机烧录器拿到产线，通过SWD接口直接连接目标板，按一下按钮就能完成烧写，完全不需要电脑。对于产线批量烧录，这个方案比每个工位配一台电脑加一个调试器可靠得多。

脱机烧录器的操作流程分两步。第一步是“下载固件到烧录器”：把脱机烧录器通过USB连到电脑，打开配套的上位机软件，加载hex文件后点击下载，固件就存到烧录器内部Flash里。第二步是“脱机烧录目标芯片”：把烧录器的SWD排线接到目标板上，给烧录器上电或按触发按钮，它会自动完成连接、擦除、写入、校验整个流程，通过指示灯告诉你烧写是否成功。

这个方案的好处非常明显：不依赖PC的稳定性、不需要工位操作人员理解烧写原理、流程标准化。我见过不少小工厂里工人用USB-TTL手动烧写，结果串口号选错、BOOT0没拉高、文件加载了旧版本，各种低级错误造成大量返工。脱机烧录器把这些变量全部消除，属于一次性投入长期受益的选择。

4.2 产线烧写的两个关键配置：校验与读保护

批量烧写和开发烧写有一个本质区别：开发时烧错了重来就行，产线上烧错了意味着产品返工甚至报废。所以在产线烧写场景下，两个配置必须明确。

第一个是校验必须开启。WCHISPTool在烧写完成后默认会做一次Flash校验，确保写入的数据和源文件完全一致。这个选项不要关，哪怕它会让单次烧写时间增加一两秒，换来的是烧写结果的确定性。批量生产时可以在抽检环节随机拿几片已经烧好的芯片读取Flash内容做比对，进一步确认校验机制正常工作。

第二个是读保护。如果你的固件包含核心算法或者不希望被同行逆向，量产时可以考虑在烧写后开启读保护。CH32V103支持读保护功能，开启后通过调试接口无法读取Flash内容。这个功能在WCHISPTool里有对应的配置项，烧写时勾选即可。需要注意的是，开启读保护后如果需要返修并重新烧写，一般需要先执行全片擦除以解除保护，这会清空包括固件在内的所有Flash内容，返修前要做好数据备份流程。

4.3 产线常见隐患：烧写时序与供电设计

批量烧写场景下，目标板的供电设计比开发板讲究得多。开发板上电源乱一点大不了烧写失败多试几次，产线上每一块板子的烧写时间都是成本。如果目标板上有大电容或者大功率外设，上电瞬间的浪涌电流可能导致SWD通信电平抖动，进而造成烧写中断。

产线治具设计时，建议在目标板的供电入口预留单独的调试电源接口。烧写时由治具给目标板供电，产品自身的电源开关保持关闭状态。这样既保证了烧写时供电稳定，又避免外设意外启动造成安全隐患。治具上还可以加一个延时继电器，上电后先稳定200毫秒再发起烧写连接，进一步降低失败概率。

还有一个很多人忽视的细节：批量烧写时不同板子之间的地电位可能有差异，如果治具和目标板之间的地线接触不良，SWD通信时好时坏。治具上的弹簧针用一段时间后要定期检查弹性和接触电阻，这类硬件问题在产线上比软件问题更隐蔽，也更磨人。

5. 串口烧写失败排查手册：从现象到根因的定位方法

网上关于ch32v103xx烧写的求助中，串口烧写失败占了很大比例。原因前面已经讲了不少，这一节把这些经验汇总成一份可对照的排查手册。你遇到问题时可以按图索骥，不用每次都从头开始猜。

5.1 失败现象分类与对应排查步骤

我根据自身经历和帮网友排查的案例，把串口烧写失败分成三类：完全无响应、握手成功但下载失败、下载成功但运行异常。每类的排查路径不同，先搞清楚自己属于哪一类，能少走很多弯路。

第一类是完全无响应，软件提示“无法连接”或“芯片无应答”。这类问题优先检查硬件连接：BOOT0是否确实拉到高电平、串口TX/RX是否交叉连接、USB-TTL的驱动是否正常安装、目标板是否正常供电。这四项占这类问题的九成原因，逐项排查基本能定位。

第二类是握手成功但下载时报错，或者进度条走到一半卡住。这类问题优先检查时钟和波特率：外部晶振是否正常、波特率是否过高、串口线是不是太长导致信号衰减。还有一点容易被忽略，USB-TTL模块如果是山寨的CH340，输出电平质量差，也可能导致数据传输途中出现误码。换一个质量可靠的USB-TTL模块很多问题就消失了。

第三类是下载提示成功但程序不运行。这个问题最迷惑人，但它和烧写本身关系不大，问题往往出在BOOT0没有恢复到低电平，或者程序本身的启动配置有问题。先把BOOT0拉低再复位，如果还是不运行，检查程序里的时钟配置和中断向量表设置是否正常。

5.2 三条独家排查技巧

除了上面表格里列的标准排查项，有几条经验是常规文档里不会写的，在这里分享给大家。

第一条，用示波器看串口波形。当你怀疑USB-TTL模块或者接线有问题时，用示波器探头夹在芯片PA9(TX)引脚上看是否有数据波形输出。芯片上电进入Bootloader后，如果PC端软件已经发出了握手命令，PA9上应该能看到有规律的方波信号。如果一片平静，说明芯片根本没进入Bootloader模式，问题在BOOT0或复位电路；如果有波形但下载失败，问题在信号质量或波特率匹配。这个判断方法比盲猜高效得多。

第二条，临时换一颗芯片试试。如果你手头有第二颗CH32V103，把它换上再试一次同样流程。如果第二颗能正常烧写，说明第一颗芯片的Bootloader区域可能已经被破坏，或者芯片本身有缺陷。这种情况概率不高但确实会发生，特别是从非正规渠道采购的芯片，存在翻新片的风险。

第三条，检查USB-TTL模块的供电能力。有些USB-TTL模块的3.3V输出能力只有几十毫安，如果你的目标板上有额外的LED灯、传感器等耗电元件，模块的3.3V会被拉低甚至跌落，芯片供电不足自然不会正常工作。区分这个问题的方法是：把USB-TTL和目标板的连接断开，只保留目标板由外部电源供电，USB-TTL只接TX、RX、GND三根线，再次尝试烧写。如果这样能烧写成功，基本可以确认是供电能力不足的问题。

5.3 预防串口烧写失败的硬件设计建议

如果你还在原理图设计阶段，以下几个设计建议可以让后续的烧写体验顺畅不少，属于“现在多花几分钟，以后少加几天班”的投入。

第一，BOOT0引脚一定要通过电阻下拉到GND，同时预留一个跳线端子方便拉高。有些设计为了省一个电阻，直接把BOOT0接地，需要用ISP时就得飞线，少一个电阻省不了几分钱，却给调试和产线烧写增加不少麻烦。

第二，串口引脚引出到排针或者测试点。PA9和PA10即使被复用为其他功能，也建议在PCB上预留测试点或排针位，需要烧写时装上排针连接USB-TTL即可。样机阶段飞线还能忍，产品阶段如果固件需要升级，没有预留的串口测试点就只能拆壳飞线，非常痛苦。

第三，晶振的选择和布局要规范。外部晶振和两个负载电容要尽量靠近芯片的OSC_IN和OSC_OUT引脚，走线短而直，周边不要有高频信号穿过。晶振是串口ISP的重要依赖，布局不合理导致的起振不稳非常隐蔽，往往只在批量生产时集中爆发。

6. 烧写之外：几个值得记住的底层原理

这一节不写操作步骤，聊聊烧写背后的一些原理。理解了底层逻辑，以后遇到新问题自己就能推断出排查方向，不会每次都被现象带着走。

6.1 为什么BOOT0只有拉高才能进入ISP

CH32V103上电启动时，BOOT0引脚的电平状态决定了CPU从哪个地址取第一条指令。BOOT0为低时，CPU从Flash起始地址0x08000000开始执行用户程序；BOOT0为高时，CPU从系统存储器中固定的Bootloader地址开始执行。这段Bootloader由芯片出厂时预置，主要功能就是通过串口接收数据并写入Flash。

这个设计的巧妙之处在于，Flash里就算烧录了一个完全跑飞的程序，只要你能控制BOOT0引脚，就永远有一条后路可以把芯片恢复成一个可烧写状态。这就像电脑的BIOS和操作系统分离，操作系统崩溃了还能进BIOS重装系统。单片机行业的叫法叫“系统存储器”，作用和BIOS高度类似。

6.2 校验失败背后的Flash写入机制

烧写工具下载完成后通常都会做校验，为什么还需要校验？这和Flash的写入机制有关。Flash写入和RAM写不一样，Flash写入需要先擦除再写入，而擦除是以扇区为单位的。如果旧程序和即将烧写的新程序在同一个扇区里交错分布，工具需要先擦除整个扇区再写入新数据，如果这个过程中断电或者通信中断，Flash里就会出现数据不完整的情况。

所以烧写工具在下载完成后会重新把Flash内容读出来和目标文件逐字节比对，这就是校验的由来。它能在烧写过程中出现偶发错误时及时报错，避免你以为烧写成功了，实际运行起来却行为怪异。我在开发阶段偶尔会为了省事关掉校验，但手上这批芯片如果Flash有坏块，关掉校验会导致程序烧进去后随机崩溃，排查起来非常痛苦。校验开着多花几秒，换来的是确定性。

6.3 从CH32V103烧写看RISC-V调试接口的差异

CH32V103采用RISC-V内核，这让它在调试接口上和传统的ARM Cortex-M芯片有一些重要差异。很多人第一次接触时会想当然地以为RISC-V的调试接口和ARM一样是标准化的，实际上RISC-V的调试规范还处于演进阶段，不同厂商的实现细节都有差异。

CH32V103上WCH-Link使用的SWD接口，在物理引脚上和ARM的SWD有相似之处，都是两根线SWDIO和SWCLK，但底层的调试协议并不相同。更准确地说，WCH-Link对自家的RISC-V芯片是通过一种专有的调试协议进行通信，这是沁恒通过WCH-Link的固件实现来适配的。这就解释了为什么你拿J-Link去连CH32V103经常连不上，因为J-Link的调试协议栈可能没有针对这颗芯片做适配。而WCH-Link之所以好使，是因为它就是为自家芯片定制开发的。

这也意味着你在选择工具时不用有“标准情结”，对CH32V103来说，官方工具链就是效率最高的选择。WCHISPTool配合WCH-Link，就是这颗芯片在Windows系统下最顺滑的烧写路径，没有之一。

7. 烧写效率优化：开发阶段的时间管理

最后聊一个很多人忽视的话题：烧写效率。单次烧写看起来只需要几秒钟，但一天几十次反复烧写，积少成多也是不小的时间成本。优化烧写效率不是让你压缩烧写时间本身，而是减少烧写之外无效等待和重复劳动的时间。

7.1 编译输出、自动烧写与快捷键配置

如果你用MounRiver Studio（沁恒官方的IDE，基于Eclipse二次开发）做开发，可以配置编译完成后自动烧写功能。这样每次编译通过后，IDE自动调用WCH-Link把固件烧进芯片，你只需要按一个快捷键就能完成“编译+烧写”整个链路。省去手动打开WCHISPTool、加载文件、点击下载的重复操作，一天下来能省不少时间。

具体配置步骤不复杂：在MounRiver Studio的Run配置里，把烧写工具的调用命令配置到编译后自动执行的步骤中。它本质上和Visual Studio Code里的Tasks机制类似，编译和烧写被串联在一个命令里。配置好后，整个调试循环从“改代码→编译→开工具→加载→下载→切窗口”变成“改代码→按一个键→完事”，效率提升非常明显。

7.2 谨慎使用“跳过擦除”选项

WCHISPTool在烧写时通常有“跳过擦除”或者在“选项”里可以关闭自动擦除功能。这个选项的作用是：如果新旧程序的Flash布局完全一致，跳过擦除可以显著缩短烧写时间。因为擦除是Flash操作中最耗时的一步，跳过后只做写入和校验，速度能提升一倍左右。

但我建议开发阶段慎用这个选项。原因很实际：跳过擦除的前提是旧程序和新程序在Flash里的布局完全一致，但编译器每次编译时，代码段、数据段、堆栈的位置都可能因为代码改动而发生偏移。如果旧程序残留在Flash里的其他扇区数据没有擦除，新程序运行起来可能遇到未预期的数据残留问题，表现为程序行为诡异、变量初始值不对、外设配置异常等。这些bug排查起来的耗时，远超你省下来的那点烧写时间。

7.3 定期清理调试缓存与临时文件

这个建议听起来很“软件工程”，但实际体验下来对烧写效率也有实实在在的影响。长时间开发的工程，Debug目录下的编译中间文件会越来越大，MounRiver Studio的启动速度和编译速度都会变慢。定期执行一次Clean然后重新编译，能让编译产物保持干净，避免因为文件系统碎片化带来的编译变慢问题。

另外工具软件本身的缓存也值得关注。WCHISPTool如果长期不更新，可能积累一些异常缓存状态，表现为连接速度变慢或者偶发连接失败。遇到这种情况，把WCHISPTool的配置目录清空重置一次，很多莫名奇妙的软件问题就消失了。这个经验虽然没有严格的科学依据支撑，但在我的工程实践中确实多次应验，属于典型的“做了不亏”的维护操作。

烧写这件事本身不复杂，但围绕它的坑可以延伸到硬件设计、软件配置、产线流程和工具选型各个方面。我一开始在CH32V103上栽了不少跟头，现在回头看不外乎是这几个原因：对RISC-V调试接口的差异认识不足、对串口ISP的时序和时钟要求了解不深、被STM32的使用习惯带了节奏。希望这篇文章能帮你把CH32V103的烧写链路一次理清，少走我当年走过的弯路。如果看完还有没解决的烧写问题，大概率是硬件层面的特殊情况，用这篇文章里的排查方法一步步定位，基本都能找到答案。