CW32L012串行Flash下载方案移植：Bootloader与量产烧录实战

玩单片机这些年，我一直有个执念：能用串口搞定的事，绝不动调试器。尤其是到了产线烧录或者现场升级这种场景，SWD调试器又贵又挑环境，一根USB转串口线反倒是最靠谱的伙伴。所以当我拿到CW32L012这颗芯片，第一反应不是看它的外设资源有多豪华，而是琢磨怎么把串行flash下载这套方案给它安排上。折腾了几天，踩了不少坑，终于把整个流程跑通了，今天就把它完整记录下来。

这篇教程适合两类人：一类是刚接触CW32系列，想用低成本串口方案解决程序烧录问题的开发者；另一类是手上正好有量产项目，想提前评估串口下载能不能替代传统调试器烧录的工程师。我会从项目背景、硬件准备、协议设计、代码移植、主机端工具到常见坑位，完整走一遍，保证你看完能直接照着做。

1. 项目背景与方案选型

1.1 为什么CW32L012需要串行flash下载方案

CW32L012是武汉芯源半导体推出的一款Cortex-M0+内核MCU，主频最高能跑到48MHz，flash容量从32KB到64KB可选，主打低功耗和高性价比。这颗芯片本身支持SWD调试接口，但开发阶段用SWD没问题，真到了量产阶段，问题就来了：SWD接口需要专门的调试器，量产工人操作起来不如串口线直观，而且有些结构紧凑的产品外壳装好后，根本留不出SWD接口的位置。

我最早量产一款智能传感器的时候，就是被这个问题卡住的。产品内部空间极小，PCBA上只预留了一排测试点，SWD的SWCLK和SWDIO分别分布在两个角落，产线上工人拿飞针探针去触碰测试点，误触率很高，时不时就烧录失败。后来改用串口TXD/RXD两条线，直接并到产品调试串口上，稳定性一下子提升了不少。CW32L012集成的是串行flash控制器，支持标准的片上flash编程接口，所以移植串口升级方案完全是可行的。

1.2 方案的三种常见形态

在正式动手之前，我先把市面上常见的串行flash下载方案捋了一下，发现主要有三种形态：

第一种是芯片原厂出厂Bootloader方案。CW32系列芯片出厂时自带一段ISP引导程序，可以通过串口直接烧录。这个方案的好处是零成本，不需要自己写bootloader，坏处是灵活性差，原厂ISP协议不公开底层细节，而且通常会占用一部分flash空间，升级流程固定死板。

第二种是自研Bootloader加APP的双区方案。上电先跑bootloader，检测串口是否有升级指令，有就接收固件写入flash，没有就跳转到APP区。这个方案最常用，可控性最强，我今天讲的移植也是基于这个方案。

第三种是通过SPI接口接外部flash，把固件先缓存在外部flash再写入内部。这个方案适合固件体积特别大、内部flash不够缓存的情况，但对CW32L012这种内部flash本来就不大的芯片来说，属于过度设计，用得很少。

我最终选择的是第二种方案，理由很简单：代码量可控，协议自己定，想加校验加校验，想加密解密都行，最关键的是可以完全避开原厂ISP可能存在的限制，比如波特率固定、帧格式固定这些问题。

1.3 移植前后的资源对比

移植前我特意统计了一下资源占用情况，列个表方便大家对照：

Bootloader占用8KB flash是我踩过坑之后定下来的。一开始我预留了4KB，结果代码一编译，眼看就要超了，临时改链接脚本又容易出错。后来干脆一步到位，预留8KB，反正CW32L012的flash最小也有32KB，APP区还剩24KB，日常项目完全够用。

2. 硬件准备与引脚规划

2.1 最小系统连接方式

串行flash下载方案看着简单，但硬件的几个关键点不处理到位，后面全是麻烦。先说供电，CW32L012的工作电压范围是1.65V到3.6V，串口模块的逻辑电平必须和MCU的VDD匹配。我习惯用3.3V供电，所以USB转串口模块也选3.3V电平的，千万不要直接拿5V电平的模块怼上去，轻则通信乱码，重则烧芯片。

再说引脚分配，CW32L012有两组串口可以用，我选的是UART1的PA2和PA3作为下载串口。选PA2/PA3的原因很简单：PA2是USART1_TX，PA3是USART1_RX，这两个引脚在绝大多数CW32L012封装上都引出来了，而且默认功能就是串口，不需要额外配置remap。PC13我用来作为下载模式检测引脚，低电平有效——上电时如果按住按键将PC13拉低，就进入下载模式；否则直接跳转APP。

连接关系非常简单：

• PA2 (USART1_TX) 接 USB转串口模块的 RX
• PA3 (USART1_RX) 接 USB转串口模块的 TX
• PC13 接一个10K上拉电阻到VDD，再串一个按键到GND
• 共地，务必共地

共地这个问题我吃过大亏。之前调试一块板子，USB转串口模块是电脑USB口供电，目标板是独立电源，两边没共地，结果串口发送一切正常，接收全是乱码。折腾了一下午，最后发现就是地电位不一致导致的，把两个GND用一根杜邦线连上，问题秒解决。所以大家做硬件连接的时候，一定把“共地”两个字刻在脑子里。

2.2 复位电路与下载模式进入逻辑

复位电路看起来简单，但和下载模式检测逻辑是联动的，这里我多说几句。CW32L012的NRST引脚是低电平复位，我用的方案是10K上拉电阻加一个0.1uF电容到地，这是最标准的阻容复位电路。但要注意，如果产品上有指示灯、电池管理之类的负载，复位引脚的上拉电阻不能选太小，否则复位释放瞬间的电流冲击会影响电源稳定性。

下载模式的进入逻辑我是这样设计的：MCU上电复位后，先延时50ms等待电源稳定，然后读PC13引脚的电平。如果PC13是低电平，说明用户按住了下载按键，进入Bootloader；如果是高电平，正常跳转APP。这里有个细节：如果按键是机械按键，上电瞬间可能因为抖动导致误判。所以我在软件里加了20ms的去抖延时，确认电平稳定后再做判断。

实际使用中还有个更稳妥的做法——协议握手超时机制。也就是不管PC13是高是低，MCU上电后都先进Bootloader，然后等主机端发送升级指令，如果500ms内没有任何指令，再跳转APP。这样即使按键接触不良，只要主机端软件及时发送握手指令，依然能进入升级流程。我把这两种方式结合起来了：先判断按键电平，按键没按下就等待握手指令，超时后再跳转APP。这样双保险，产线上基本不会出现因为硬件原因进不了下载模式的情况。

3. 移植前的软件工程准备

3.1 开发环境与SDK版本选择

CW32L012的开发环境我推荐用Keil MDK，版本至少5.30以上。如果你手上还有IAR或者GCC工具链，也都能用，但考虑到CW32系列的资料和例程在Keil下最全，出了问题上网查资料也方便，所以对新手来说Keil是首选。

SDK方面，我使用的是武汉芯源半导体官方的CW32L031板级支持包，因为CW32L012与CW32L031同系列，外设寄存器高度兼容，直接以L031的SDK为基底移植可以省掉很多自己造轮子的时间。下载SDK后，主要用到这几个文件：

• cw32l031.h：寄存器定义头文件
• system_cw32l031.c：系统时钟初始化
• startup_cw32l031.s：启动文件
• cw32l031_uart.c / cw32l031_uart.h：串口驱动
• cw32l031_flash.c / cw32l031_flash.h：内部flash读写驱动

当然，直接用官方例程里的标准外设库也可以，并不强制要求板级支持包。关键是要确保flash驱动函数的地址、命名和你的编译器平台匹配，因为下面我们要基于这些驱动做二次封装和移植。

3.2 链接脚本与启动文件修改

这是整个移植过程中最容易翻车的地方，我第一次移植就栽在这里。Bootloader和APP是两个独立的工程，它们的链接脚本（分散加载文件或.sct文件）必须分别指定不同的flash起始地址。

Bootloader工程保持默认即可，即代码从0x00000000开始。APP工程的起始地址就要改了，对应之前预留的8KB偏移，即0x00002000。在Keil里操作很简单：打开Options for Target对话框，在Target标签页的IROM1起始地址填0x2000，大小填0xA000（这是按48KB flash算的，如果你的芯片是32KB flash，大小要改成0x6000）。

仅仅改链接脚本还不够，还有一个关键的坑等着你——中断向量表重映射。APP工程的启动文件里，默认会把向量表放在0x00000000，但由于APP实际运行地址在0x00002000，如果不修改，APP一旦发生中断，CPU还是会去0x00000000取向量表，取到的却是Bootloader的向量表，中断自然全部错乱。

CW32系列不像某些芯片有专门的VTOR寄存器可以直接改向量表偏移，所以更通用的做法是：在APP工程启动代码的最早期，把中断向量表从flash拷贝到SRAM，然后把SRAM映射到0x00000000地址。具体分两步：

第一步，在startup_cw32l031.s的Reset_Handler里，增加向量表拷贝逻辑：

Reset_Handler ; 复制中断向量表到SRAM LDR R0, =__Vectors ; 源地址：flash中的向量表 LDR R1, =__Vectors_RAM ; 目的地址：SRAM中的向量表 MOVS R2, #128 ; 向量表大小（按128字节算，32个中断向量） copy_loop LDR R3, [R0], #4 STR R3, [R1], #4 SUBS R2, R2, #4 BNE copy_loop ; 重映射中断向量表到SRAM LDR R0, =0xE000ED08 LDR R1, =__Vectors_RAM STR R1, [R0] ; 跳转main BL main

第二步，在分散加载文件中给APP工程增加一个只读数据段，存放__Vectors_RAM的地址。这部分逻辑看着绕，其实核心思想就是把向量表放到一个“既能在flash中存储，又能在SRAM中运行”的位置。如果你用的是GCC工具链，对应的链接脚本写法是：

MEMORY { FLASH (rx) : ORIGIN = 0x00002000, LENGTH = 0xA000 RAM (rwx) : ORIGIN = 0x20000000, LENGTH = 0x2000 } SECTIONS { .vectors : { . = ALIGN(4); KEEP(*(.isr_vector)) . = ALIGN(4); } >FLASH .vectors_ram : { . = ALIGN(4); __Vectors_RAM = .; . += 128; . = ALIGN(4); } >RAM /* 其他段保持不变 */ }

关于向量表拷贝的大小，我这边是固定预留128字节，也就是32个中断向量。CW32L012的中断源如果不确定到底有多少个，建议直接把__Vectors到__Vectors_End之间的长度全部拷贝过去，最稳妥。这里给一段可复用的方式：

extern uint32_t __Vectors[]; extern uint32_t __Vectors_End[]; extern uint32_t __Vectors_RAM[]; void vector_table_reload(void) { uint32_t i, size = (uint32_t)__Vectors_End - (uint32_t)__Vectors; for (i = 0; i < size / 4; i++) { __Vectors_RAM[i] = __Vectors[i]; } SCB->VTOR = (uint32_t)__Vectors_RAM; }

3.3 工程文件的目录组织

移植前把工程目录规划好，后面能省很多事。我的项目结构是这样组织的：

project/ ├── bootloader/ │ ├── core/ │ │ ├── startup_cw32l031.s │ │ ├── system_cw32l031.c │ │ ├── cw32l031.h │ │ ├── cw32l031_flash.c │ │ └── cw32l031_uart.c │ ├── app/ │ │ └── boot_main.c │ ├── protocol/ │ │ └── xmodem_protocol.c │ └── MDK-ARM/ │ └── bootloader.uvprojx ├── app_project/ │ ├── core/ (与bootloader共用SDK，但独立编译) │ ├── user/ │ │ └── app_main.c │ └── MDK-ARM/ │ └── app.uvprojx └── host_tool/ ├── cw32_downloader.py └── README.md

强调一点：bootloader和APP是两个独立的Keil工程，不要试图用同一个工程管理。因为它们的链接地址不同、编译选项不同、甚至优化等级都可能不同，强行放在一个工程里只会让脚本越改越乱。分开之后，各自编译各自下载，逻辑非常清晰。

3.4 编译优化等级的选择

Bootloader的编译优化等级我建议选-O0或者-O1，不建议上-O2以上的优化。原因很直接：Bootloader代码里有很多对时序敏感的操作，比如flash擦写时的循环等待、串口接收的超时判断，如果编译器过度优化，可能会把一些你认为“多余的”空操作直接优化掉，导致时序错乱。别问我怎么知道的，有一次我把Bootloader的优化级别从-O1调到了-O2，结果flash擦除后总是校验失败，后来用调试器单步跟踪才发现是优化器把一个关键的寄存器等待循环干掉了。

APP工程则相反，该开-O2开-O2，该开-O3开-O3，毕竟APP是真正跑业务逻辑的地方，性能优化收益明显。这与Bootloader追求稳定可靠的目标不冲突。

4. 核心移植步骤：串口驱动的寄存器级实现

4.1 引脚复用配置

串口驱动的移植是整个项目的重头戏，很多第一次接触CW32系列的朋友在这里卡住，核心原因是CW32L012的引脚复用配置不像STM32那样写在GPIO_Init结构体里，而是在专门的“引脚复用表”中配置。这个设计初看绕，用熟了反而觉得顺手——所有引脚功能集中管理，排查问题的时候一目了然。

首先配置PA2为USART1_TX，PA3为USART1_RX：

void uart_pin_init(void) { // 使能GPIOA时钟 __RCC_GPIOA_CLK_ENABLE(); // 使能UART1时钟 __RCC_UART1_CLK_ENABLE(); // PA2配置为USART1_TX，复用功能带上拉 GPIO_InitTypeDef gpio_init; gpio_init.Pins = GPIO_PIN_2; gpio_init.Mode = GPIO_MODE_MUX; gpio_init.Speed = GPIO_SPEED_HIGH; gpio_init.Pull = GPIO_PULL_UP; GPIO_Init(GPIOA, &gpio_init); GPIO_SetFunc(GPIOA, GPIO_PIN_2, GPIO_FUNC_USART1_TX); // PA3配置为USART1_RX，复用功能带上拉 gpio_init.Pins = GPIO_PIN_3; gpio_init.Mode = GPIO_MODE_MUX; gpio_init.Speed = GPIO_SPEED_HIGH; gpio_init.Pull = GPIO_PULL_UP; GPIO_Init(GPIOA, &gpio_init); GPIO_SetFunc(GPIOA, GPIO_PIN_3, GPIO_FUNC_USART1_RX); }

GPIO_SetFunc这个函数就是CW32系列独有的引脚复用配置函数，把引脚和复用功能解耦，想改引脚绑定，只需要改这一行参数即可。这个设计我后来用得很舒服，调试时想把串口从UART1换到UART2，只需要把GPIO_SetFunc的参数换一下，再改一下UART外设基地址就够了。

需要注意的是，引脚复用功能的枚举值不是随便填的，要看芯片手册的“引脚功能复用表”。CW32L012的手册最后几页会有这么个表，PA2对应USART1_TX，PA3对应USART1_RX，这个对应关系务必查手册确认，不要凭感觉填。我见过不少朋友拿STM32的思维去套CW32，结果烧录后串口完全没反应，最后发现就是复用功能枚举值填错了。

4.2 串口时钟与波特率计算

CW32L012的UART1挂载在APB总线上，时钟源可以选择PCLK或者SYSCLK。为了波特率计算方便，我直接选择PCLK作为UART1的时钟源。系统时钟配置为48MHz，APB分频系数为1，也就是说PCLK = 48MHz。

波特率115200的计算过程：

• 目标波特率：115200
• 时钟源频率：48,000,000 Hz
• 分频系数 = 48,000,000 / 115200 = 416.67
• 取整：417，实际波特率 = 48,000,000 / 417 ≈ 115108
• 误差 = (115200 - 115108) / 115200 ≈ 0.08%

0.08%的误差完全在串口通信可接受范围内，所以115200这个波特率可以用。如果系统时钟不是整数分频的，计算出来的误差会变大，超过2%就容易出现偶发乱码了。

再补充一个经验值，UART1的接收和发送都建议启用FIFO。CW32L012的UART支持发送FIFO和接收FIFO，深度各为8字节。开启FIFO后，接收多个字节时的CPU中断频率会显著降低，对Bootloader接收大固件来说帮助明显。初始化代码里使能FIFO的寄存器位为UART_CR2的FIFOEN位。

void uart1_init(uint32_t baudrate) { // 复位UART1 UART1->CR0 = UART_CR0_RST; UART1->CR0 = 0; // 使能发送和接收 UART1->CR0 |= UART_CR0_TXEN | UART_CR0_RXEN; // 配置8数据位，1停止位，无校验 UART1->CR1 |= UART_CR1_MODE_8N1; // 使能FIFO UART1->CR2 |= UART_CR2_FIFOEN; // 设置波特率 UART1->BRR = (uint32_t)(48000000 / baudrate); }

4.3 串口发送与接收的实现细节

串口发送函数的移植相对简单，核心逻辑就一句话：把数据写入发送数据寄存器，等待发送完成标志。但这里有个优化点：如果开启了发送FIFO，可以先检查FIFO是否已满，满了再等待，否则直接往FIFO里塞数据，效率能提升不少。

void uart1_write_byte(uint8_t data) { while (!(UART1->ISR & UART_ISR_TXE)); // 等待发送数据寄存器空 UART1->TDR = data; } void uart1_write_buffer(uint8_t *buf, uint16_t len) { for (uint16_t i = 0; i < len; i++) { uart1_write_byte(buf[i]); } }

接收函数的实现就要小心了，因为Bootloader的接收逻辑是“不定长、按帧处理、超时判定”。如果用查询方式接收，主循环需要不停轮询接收标志位，浪费CPU；用中断方式的话，帧边界怎么判定又是个问题。我这边用了一个简单可靠的做法：接收超时中断处理。

思路是这样的：串口每收到一个字节，就触发一次接收中断，在中断服务函数里把数据存入缓冲区，同时重置一个超时计数器。主循环里不断检查这个超时计数器，如果连续多长周期没有新数据进来，就认为一帧数据接收完毕，开始处理帧。这个“帧间超时判定”的机制，比固定帧长要灵活得多，尤其适合Xmodem这类变长协议。

#define RX_TIMEOUT_MS 10 // 10ms没有新数据视为帧结束 volatile uint8_t uart1_rx_buf[1024]; volatile uint16_t uart1_rx_cnt = 0; volatile uint8_t uart1_rx_idle = 0; void UART1_IRQHandler(void) { if (UART1->ISR & UART_ISR_RXF) { uint8_t data = (uint8_t)UART1->RDR; if (uart1_rx_cnt < sizeof(uart1_rx_buf)) { uart1_rx_buf[uart1_rx_cnt++] = data; } uart1_rx_idle = 0; // 重载超时定时器 } }

配合一个1ms的SysTick中断，主循环里做超时判断：

void idle_handler(void) { static uint16_t idle_timeout = 0; if (uart1_rx_cnt > 0) { idle_timeout++; if (idle_timeout >= RX_TIMEOUT_MS) { uart1_rx_idle = 1; idle_timeout = 0; } } }

4.4 串口乱码排查心得

串口乱码是嵌入式开发最常见的问题，在Bootloader场景下尤其致命——因为Bootloader正常情况下不会输出任何数据，一旦乱码，你甚至没法判断芯片是否还活着。我整理几个排查重点：

第一检查电平匹配。USB转串口模块的输出电平是不是3.3V，如果是5V模块，必须加电平转换芯片，比如TXS0108E或者简单点用两个三极管搭个电平转换电路。

第二检查波特率计算。不要只看理论值，用逻辑分析仪或者示波器实测一下TX引脚的波形，看一位持续的时间是不是8.68us。CW32L012的BRR寄存器写入流程需要在CR0里先关断UART，改完再打开，否则写入无效。

第三检查引脚复用。这是CW32系列特有的坑，PA2配置成USART1_TX后，还要确认GPIO_SetFunc是否被正确调用。很多朋友只配置了GPIO模式为复用，忘了调用GPIO_SetFunc，结果引脚仍然输出普通GPIO电平。

第四检查共地。前面说了，这是最容易被忽略的问题，尤其是用笔记本供电时，USB模块和板上电源来自不同供电回路，地电位不一致，乱码率极高。

5. 核心移植步骤：内部flash驱动移植

5.1 CW32L012内部flash结构

在写flash驱动之前，先要搞清楚CW32L012的内部flash结构。CW32L012的flash按扇区组织，每个扇区大小是512字节，整片flash由若干个扇区组成。擦除操作的最小单位是扇区，也就是说你哪怕只想改一个字节，也必须先把整个扇区擦掉，再重新写入全部数据。这和EEPROM差别很大，很多从EEPROM转过来的朋友一开始不适应，改一个配置项要“读出-擦除-写入”三步走。

CW32L012的flash操作需要特别注意一个特性：flash操作期间，如果CPU需要从同一块flash取指，会发生总线阻塞。所以擦写flash的函数代码必须放到RAM中运行，或者关闭全局中断以避免取指冲突。CW32系列的官方库通常提供了一个宏来标记RAM运行的函数：

#if defined (__CC_ARM) #define RAM_FUNC __attribute__((section("RamFunc"))) #elif defined (__GNUC__) #define RAM_FUNC __attribute__((section(".ramfunc"))) #endif

所有需要在flash操作期间执行的函数，加上RAM_FUNC修饰，然后链接脚本里要把RamFunc段放到SRAM区域。

5.2 解锁、擦除、写入的完整流程

CW32L012的flash控制器和STM32类似，有解锁机制，防止误操作。标准流程是：

#define FLASH_KEY1 0x5A5A #define FLASH_KEY2 0xA5A5 void flash_unlock(void) { // 先解锁主flash编程 if (FLASH->CR & FLASH_CR_LOCK) { FLASH->KEY = FLASH_KEY1; FLASH->KEY = FLASH_KEY2; } } void flash_lock(void) { FLASH->CR |= FLASH_CR_LOCK; }

擦除扇区的实现：

RAM_FUNC void flash_erase_sector(uint32_t sector_addr) { // 等待flash空闲 while (FLASH->SR & FLASH_SR_BUSY); // 解锁 flash_unlock(); // 设置扇区地址并触发擦除 FLASH->ADDR = sector_addr; FLASH->CR |= FLASH_CR_ERASE; FLASH->CR |= FLASH_CR_START; // 等待擦除完成 while (FLASH->SR & FLASH_SR_BUSY); // 重新加锁 flash_lock(); }

写入一个字的实现：

RAM_FUNC void flash_program_word(uint32_t addr, uint32_t data) { while (FLASH->SR & FLASH_SR_BUSY); flash_unlock(); // 先写入数据寄存器 FLASH->DR = data; // 设置目标地址 FLASH->ADDR = addr; // 触发编程 FLASH->CR = (FLASH->CR & ~FLASH_CR_ERASE) | FLASH_CR_START; // 等待编程完成 while (FLASH->SR & FLASH_SR_BUSY); flash_lock(); // 校验 if (*(volatile uint32_t *)addr != data) { // 写入失败，进入错误处理 } }

5.3 写flash时CPU取指冲突的处理

这部分是整个移植过程中最核心、也最容易出问题的点。前面说过，flash擦写期间CPU如果还要从同一块flash取指，就会出问题。解决思路有几个层次：

最粗犷的做法是关闭全局中断，在擦写前调用__disable_irq()，擦写完成后调用__enable_irq()重新打开中断。这个做法的缺点是：如果擦写函数本身放在flash里，关闭中断后CPU仍然在从flash取指，系统仍然可能卡死。所以关闭中断必须配合中断服务函数和擦写函数都放入RAM的手段，才能保证彻底隔离。

推荐的方案是把擦写代码全部放到RAM中执行。上面的RAM_FUNC宏就是干这个的。在Keil的分散加载文件里，需要新增一个RamFunc的执行区：

LR_IROM1 0x00002000 0x0000A000 { ER_IROM1 0x00002000 0x0000A000 { *(.isr_vector) *(InRoot$$Sections) .ANY (+RO) } RW_IRAM1 0x20000000 0x00002000 { .ANY (+RW +ZI) } RW_RAMFUNC 0x20000400 UNINIT { *(RamFunc) } }

如果不方便修改分散加载文件，还有另一个取巧的办法：擦写走flash地址别名。CW32系列有些型号的flash支持“编程时通过别名地址访问”，也就是擦写期间CPU通过特殊地址窗口去访问flash，让正常的取指不受影响。但这个功能具体是否支持，需要查阅对应型号的数据手册，不是所有型号都有。

我在CW32L012上的实测结论是这样的：只要把flash擦写函数放RAM，同时关闭全局中断，就没有问题。两个条件缺一个都不行。单独关闭全局中断但代码还在flash，会在擦除期间卡死；单独放RAM但没关中断，如果串口中断恰好打断了擦写流程，flash状态机可能被破坏，导致写入数据错误。

6. 串行下载通信协议设计

6.1 Xmodem协议的选型思考

通信协议是整个串行下载方案的灵魂，最初我想自己定义一套简单的私有协议，比如固定帧头加命令字加数据长度加CRC16，后来想了想，还是决定用成熟的Xmodem协议。原因有三点：

第一，Xmodem是几十年前就定型的经典协议，成熟稳定，主机端工具随便用什么语言都能轻易实现，Python、C#、C++都有现成的库，开发门槛低。

第二，Xmodem天然支持分包传输、应答确认和CRC校验，这正好满足bootloader烧录对可靠性的要求。Xmodem-1K模式每包可以传1024字节，对动辄几十KB的APP固件来说，传输效率也还可以。

第三，Xmodem以字节为最小操作单位的设计，让后续扩展加密、压缩等处理变得简单。你可以在发送前对固件做AES加密，bootloader收到后解密再写入flash，流程完全不用改协议本身。

当然，Xmodem也有它的缺点，最明显的就是协议开销大。每个1024字节的数据包，要额外携带3字节的头部和2字节的CRC16，有效载荷率约99.5%（等等，重新算一下：3+1024+2=1029，载荷率=1024/1029约99.5%），其实很高了。整体来说利大于弊，最终就定它了。

6.2 Xmodem-1K的帧格式

Xmodem-1K的帧格式如下：

• SOH (0x01)：表示128字节数据块模式
• STX (0x02)：表示1024字节数据块模式
• 块序号：从0x01开始，循环递增，0x00和0xFF特殊值不使用
• 块序号的反码：用于校验块序号
• 数据块：128字节或1024字节
• 校验：CRC16高字节 + CRC16低字节（使用CRC-CCITT多项式）

控制字符定义：

握手流程：接收方（bootloader）发送字符C表示等待接收，发送方收到C后开始发送第一个数据包，接收方校验通过后回ACK，否则回NAK，发送方收到NAK重新发送当前包。所有数据包发送完毕后，发送方发送EOT，接收方回ACK，整个传输完成。

6.3 主机端Python工具的实现

主机端工具我用Python实现，核心依赖是pyserial。上位机工具的逻辑分为三层：串口通信层处理底层字节收发和超时重试，Xmodem协议层处理分包、校验和确认，应用层负责读取固件文件、启动传输、显示进度。

先看串口通信层：

import serial import time class SerialPort: def __init__(self, port, baudrate=115200, timeout=0.1): self.ser = serial.Serial(port, baudrate, timeout=timeout) def read_byte(self): data = self.ser.read(1) return data[0] if data else None def write_byte(self, data): self.ser.write(bytes([data])) def write_bytes(self, data): self.ser.write(data) def flush(self): self.ser.flush()

Xmodem-1K的发送端核心逻辑：

import crcmod.predefined crc16 = crcmod.predefined.mkCrcFun('xmodem') class XmodemSender: def __init__(self, serial_port): self.port = serial_port self.seq = 1 def send_packet(self, data): # 数据包格式：STX + SEQ + SEQ_INV + DATA + CRC seq_inv = (~self.seq) & 0xFF crc = crc16(data) packet = bytes([0x02, self.seq, seq_inv]) + data + bytes([(crc >> 8) & 0xFF, crc & 0xFF]) self.port.write_bytes(packet) self.seq = (self.seq + 1) & 0xFF def start_transfer(self, file_path, packet_size=1024): # 等待接收方的C字符 while True: c = self.port.read_byte() if c == 0x43: break # 分包发送 with open(file_path, 'rb') as f: while True: data = f.read(packet_size) if not data: break # 补齐不足packet_size的包 if len(data) < packet_size: data += b'\x1A' * (packet_size - len(data)) # 发送并等待ACK，最多重试10次 for retry in range(10): self.send_packet(data) response = self.port.read_byte() if response == 0x06: # ACK break elif response == 0x15: # NAK continue else: raise Exception(f'Unexpected response: {response}') else: # 最后发EOT for retry in range(10): self.port.write_byte(0x04) response = self.port.read_byte() if response == 0x06: break

6.4 Bootloader接收端的状态机实现

Bootloader接收端的核心是一个状态机，我用枚举定义了几个状态，每个状态下处理特定的字符输入。这样写的好处是逻辑清晰、便于测试和排错。

typedef enum { XM_IDLE, // 空闲，等待起始字符 XM_SEQ, // 收到起始字符，等待块序号 XM_SEQ_INV, // 收到块序号，等待反码 XM_DATA, // 正在接收数据 XM_CRC_H, // 收到数据，等待CRC高字节 XM_CRC_L, // 等待CRC低字节 XM_ERROR // 出错状态 } XmodemState;

状态机的主循环可以这样实现：

XmodemState xm_state = XM_IDLE; uint8_t xm_seq_expected = 0x01; uint8_t xm_data_buf[1024]; uint16_t xm_data_len = 0; void xmodem_process_byte(uint8_t byte) { switch (xm_state) { case XM_IDLE: if (byte == STX) { // 1024字节包 xm_data_len = 1024; xm_data_cnt = 0; xm_state = XM_SEQ; } else if (byte == SOH) { // 128字节包 xm_data_len = 128; xm_data_cnt = 0; xm_state = XM_SEQ; } else if (byte == EOT) { uart1_write_byte(ACK); // 收到结束符，回ACK xm_state = XM_IDLE; // 执行跳转APP jump_to_app(); } else if (byte == CAN) { xm_state = XM_IDLE; } break; case XM_SEQ: if (byte == xm_seq_expected) { xm_state = XM_SEQ_INV; } else { uart1_write_byte(NAK); xm_state = XM_IDLE; } break; case XM_SEQ_INV: if (byte == (uint8_t)(~xm_seq_expected)) { xm_state = XM_DATA; } else { uart1_write_byte(NAK); xm_state = XM_IDLE; } break; case XM_DATA: if (xm_data_cnt < xm_data_len) { xm_data_buf[xm_data_cnt++] = byte; } if (xm_data_cnt == xm_data_len) { xm_state = XM_CRC_H; } break; case XM_CRC_H: xm_received_crc = (uint16_t)byte << 8; xm_state = XM_CRC_L; break; case XM_CRC_L: xm_received_crc |= byte; // 计算实际CRC并比较 uint16_t calc_crc = crc16_calc(xm_data_buf, xm_data_len); if (calc_crc == xm_received_crc) { flash_write_packet(xm_seq_expected, xm_data_buf, xm_data_len); uart1_write_byte(ACK); xm_seq_expected++; } else { uart1_write_byte(NAK); } xm_state = XM_IDLE; break; } }

这个状态机的核心优势是：每个字节的处理逻辑是确定性的，出问题可以通过串口打印状态值快速定位。我调试时加了串口打印状态转换信息的功能，一旦传输中断，看log能直接看出是卡在等待块序号还是等待数据阶段，排查效率提升明显。

7. 下载模式跳转与升级流程实现

7.1 Bootloader中的APP启动条件判断

跳转逻辑是整个方案的收尾环节，虽然代码不长，但细节很多。我在Bootloader的main函数里的主循环逻辑是这样设计的：

1. 初始化时钟为48MHz，配置串口和GPIO，初始化flash控制器
2. 读取PC13引脚电平，加20ms去抖
3. 如果PC13为低电平（下载按键按下），进入下载流程，等待主机端发送Xmodem传输数据
4. 如果PC13为高电平，进入超时等待状态：500ms内如果收到字符“C”请求握手，则进入下载流程；否则超时后跳转APP

这里有一个关键分支——当需要跳转APP时，跳转前必须做几件收尾动作：

• 关闭全局中断：防止跳转瞬间有中断触发，导致取指到未初始化的APP中断向量
• 关闭SysTick定时器：把SysTick的计数值清零，避免APP启动时误判系统时钟
• 复位UART1外设到默认状态：如果带着Bootloader的串口配置跳到APP，APP要重新初始化串口，中间可能有残留数据
• 设置主栈指针为APP向量表的第一个字

跳转代码实现：

typedef void (*app_entry_t)(void); void jump_to_app(void) { uint32_t app_addr = APP_START_ADDR; // 0x2000 uint32_t app_stack = *(volatile uint32_t *)app_addr; uint32_t app_entry = *(volatile uint32_t *)(app_addr + 4); // 检查向量表是否有效 if ((app_stack & 0x2FFE0000) != 0x20000000) { // 校验失败，栈顶指针不是合法SRAM地址 return; } // 关闭全局中断 __disable_irq(); // 复位SysTick SysTick->CTRL = 0; SysTick->LOAD = 0; SysTick->VAL = 0; // 复位UART1 UART1->CR0 |= UART_CR0_RST; // 设置跳转函数 app_entry_t app = (app_entry_t)app_entry; // 设置主栈指针 __set_MSP(app_stack); // 跳转 app(); // 永远不应该执行到这里 while (1); }

这段代码最值得说的就是栈顶指针合法性检查。CW32L012的SRAM地址从0x20000000开始，大小16KB，所以合法的栈顶指针应该在0x20000000到0x20004000之间。如果这个地址被错误地写成了0xFFFFFFFF（flash空数据），说明APP区是空的，这时候跳转过去只会死机，所以先检查再跳转是保命符。

7.2 APP工程中的SystemInit处理

APP工程跳转后，有另一个容易忽略的坑：APP工程编译时，编译器自动生成的SystemInit函数会把系统时钟重新配置一遍。如果你的APP工程里SystemInit代码沿用默认配置，系统时钟可能从Bootloader的48MHz被重置为默认的内部RC时钟，导致APP外设工作异常。

解决方式是在SystemInit函数中明确配置系统时钟为想要的频率：

void SystemInit(void) { // 使能HSI // 配置PLL倍频系数，使系统时钟达到48MHz // 设置flash等待周期 // 更新全局SystemCoreClock变量 }

这里有个小经验：如果你在Bootloader里已经初始化好时钟了，APP的SystemInit里可以什么都不做，只更新SystemCoreClock变量。这样跳转后时钟不会被打断，实现无缝衔接。但考虑到独立调试APP时也需要正确的时钟，我建议还是在SystemInit里把时钟配置逻辑写完整，保持APP工程的独立性。

7.3 Bootloader中配置存储和flash规划

除了存放APP代码的flash，Bootloader还需要考虑配置参数的存储。比如你在量产时要给不同产品写不同的序列号、校准参数，这些数据放在flash的哪个区域，必须有明确的规划。

我的flash分区规划如下：

个人建议，配置参数区单独划一块，不要和APP区混在一起。因为参数区更新频率可能很高，每次都擦除APP区会带来风险。设置参数区时，写操作要遵循“读-改-擦-写”的标准流程：

typedef struct { uint32_t magic; // 魔数，用于确认参数有效 uint32_t version; // 参数版本号 uint8_t sn[16]; // 序列号 int16_t offset; // 校准偏移 } app_params_t; void params_save(app_params_t *params) { uint32_t addr = PARAM_BASE_ADDR; // 1. 如果已有有效参数，先备份到RAM app_params_t old_params; if (params_check_valid()) { old_params = params_load(); } // 2. 擦除参数区扇区 flash_erase_sector(addr); // 3. 写入新参数 flash_program_word(addr, *(uint32_t *)params); flash_program_word(addr + 4, *(uint32_t *)((uint8_t *)params + 4)); // ... 根据结构体大小逐个字写入 }

写完参数读回来校验，校验失败尝试再擦再写，连续失败三次报错误，提示用户重新设置。这套逻辑虽然朴素，但在量产环境中非常可靠，我用到至今没出过因为参数写入失败导致的设备异常。

8. 常见问题与排查技巧实录

8.1 下载卡在等待C字符

现象：主机端工具启动后，一直显示“等待接收方发送C字符”，就是进入不了传输阶段。

排查方向：

1. 先用串口助手直接发一个“C”字符（0x43），看Bootloader是否回NAK（0x15）。如果回NAK，说明串口通路和Bootloader接收逻辑都正常，问题出在主机端工具没有正确检测C字符。如果什么都不回，说明Bootloader根本没收到数据。

2. 检查接线方向。USB转串口模块的RXD要接MCU的TXD（PA2），TXD要接MCU的RXD（PA3）。很多朋友把两根线接反了，结果“监听”到了自己发的数据，却收不到对方的回复。

3. 检查波特率是否匹配。主机端工具和Bootloader的波特率必须一致。我调试时习惯用115200，但如果你的USB转串口模块晶振不准，实际波特率会有偏差。可以试着降低波特率到9600，看通信是否恢复正常。

4. 检查Bootloader是否真的进入了下载模式。如果PC13按键没按对，或者超时时间设得太短，Bootloader可能已经跳转到APP了，自然收不到C字符。此时无论怎么发握手信号都没用。

8.2 传输中途CRC校验失败

现象：传输进行到一半，Bootloader频繁回NAK，主机端重试几次后放弃，升级失败。

排查方向：

1. 检查供电稳定性。这是最常见的原因。USB转串口模块连着电脑，电压波动会直接影响MCU供电。我遇到过一个案例：板子上还有一个电机驱动，启动瞬间电流达到700mA，导致MCU供电电压跌到3.0V以下，flash写入时电压不稳导致数据损坏。解决方式是加一个大容量电解电容，或者用独立稳压电源供电。

2. 检查波特率误差。当波特率超过460800时，CW32L012的BRR分频误差可能超过1%，在长包传输时累积错误。建议用115200甚至更低的57600，稳定优先。

3. 检查flash擦除是否超时。如果擦除大扇区时，等待循环没有设置超时上限，万一flash状态机卡住，Bootloader就会永久卡在擦除状态，表现为“收到一个NAK后不再有任何响应”。这种情况必须重启才行。所以我的代码里给所有flash等待循环都加了超时上限，超过一定时间直接报错退出。

排查问题最快的工具还是逻辑分析仪，把RXD和TXD的波形拉出来看，能直接看出是发送端的问题还是接收端的问题。曾经有个CRC校验失败的问题，我用逻辑分析仪看波形，发现主机端发送的数据包中间有一段电平异常——原来是数据线接触不良，某个字节的位信号被拉长了。这种问题靠看代码根本找不到原因。

8.3 跳转APP后串口打印乱码

现象：Bootloader下载成功，但跳转APP后，APP的串口打印一片乱码。

排查方向：

1. 检查波特率设置是否一致。APP工程里如果用了和Bootloader不同的波特率，比如Bootloader是115200，APP里初始化成了9600，那打印必然乱码。

2. 检查时钟配置。APP工程的SystemInit如果重新配置了系统时钟，且倍频系数写错了，比如配置成了56MHz而不是48MHz，UART波特率计算基准就变了，实际波特率差一截，乱码自然出现。

3. 检查跳转前是否正确复位了UART1。如果在Bootloader持有UART1外设控制权时直接跳转APP，APP重新初始化UART1时，可能残留波特率配置、FIFO状态等异常信息。跳转前手动复位UART1外设是个好习惯。

4. 如果APP中断向量表重映射做得不彻底，串口中断服务函数可能没有正确注册，导致中断数据丢失。这种情况乱码不规律，带有丢字符特征。

8.4 问题排查速查表

8.5 我的几个独家避坑技巧

第一个技巧：下载校验结束再加一道保险。Xmodem协议本身自带CRC校验，但我在整个固件接收完成后，还会对所有写入flash的数据做一次累加和校验。具体做法是：把固件按照4字节对齐分成多个字，在主机端算出一个总的累加和，放在固件末尾一并发送；Bootloader接收完再算一遍累加和，两者对比一致才算升级成功。这样就算中间的某个包被CRC漏过（极小概率），最终校验也能发现。

第二个技巧：善用串口打印调试信息，但要分级。Bootloader的串口打印在正式量产时必须关闭，否则下载过程会干扰Xmodem协议通信。我的做法是用一个编译宏控制，验证阶段打开printf，量产编译时关掉，非常干净。

第三个技巧：升级失败后的自动回退机制。我在flash里写了一个“升级计数”字段，每次开始升级时先加1，升级成功后又减1。如果Bootloader检测到计数大于3，说明连续三次升级失败，自动恢复到上一次保存的备份固件。这个机制防住了不少产线意外情况。

第四个技巧：硬件设计时给串口下载留一个测试点。即使你的产品量产时用SWD，也建议在设计阶段把串口下载的TX/RX各引两个测试点出来。有一次我在客户现场做固件升级，他们的SWD接口被结构件挡住了，幸好预留了串口测试点，直接用飞线就完成了升级，客户当场惊呆。

9. 后续扩展方向

串行flash下载方案跑通后，我还在陆续做一些扩展，这里简单聊聊，给大家一个参考方向。

一个是固件加密传输。Xmodem协议本身是明文传输，只要有人监听串口线，就能抓取完整的固件数据，逆向出APP逻辑。我现在在实验的方案是：主机端先用AES-128对固件做加密，把密钥烧录在Bootloader固定位置，升级时Bootloader解密后再写入flash。这样即使固件被截获，没有密钥也无法还原，对很多有防抄板需求的场景非常实用。

另一个是OTA差分升级。现在很多产品只有一根串口线连着外部模块，没有网络，OTA根本无从谈起。但如果外部模块本身有联网能力，可以通过串口把升级包传给Bootloader，Bootloader支持只接收差分数据、在内部做差分合并再写入APP区，可以把升级包体积缩小80%以上。这个方案的难点在于差分算法的选择和flash缓存的规划，后续有时间我再单独写一篇。

还有一个相对简单的方向：把bootloader同时烧录出厂固件和参数配置。产线上一次串口操作同时完成“烧固件”和“写序列号”两个步骤，节省一道工序，这事谁用谁知道，省下来的时间都是产线良率。

串行flash下载方案的移植其实不复杂，真正的复杂度在于底层细节的把控——中断向量表的重映射、flash擦写的时序、协议状态机的边界条件、跳转时机的正确性判断。任何一个环节出问题，整个方案就跑不通。但一旦跑通了，这套方案就能在产线烧录、现场升级、固件恢复等多个场景中发挥价值。我在自己的几个项目里用了这套方案，无论是量产稳定度还是后期维护效率，都提升非常明显。如果你也在用CW32L012或者其他同系列芯片，强烈建议试一试。