企业官网建设流程全解析

这两年因为供应链和各种成本原因，国产MCU替代STM32几乎成了每个硬件项目都要过一遍的坎。老板拿着国产芯片的规格书扔给我，第一句话往往是“这不就是STM32吗？引脚都一样，直接换上去就行”。这话对了一半。Pin-to-Pin兼容确实让硬件改板的工作量小了很多，但真正把代码烧进去、把外设调通、把量产跑起来，你会发现“兼容”这两个字的含水量比想象中高得多。

我自己前后做过几个替代项目，从早期的GD32、AT32，到后来的APM32、MM32，各种“兼容”方案试了一圈，踩过的坑加起来都能写个小册子了。这篇博文就把那些典型的、容易让人猝不及防的隐藏坑整理出来，给准备做替代或者正在替代路上挣扎的朋友一个参考。不管你是硬件工程师还是嵌入式软件工程师，只要你手里有STM32项目要考虑国产化，这篇文章应该能帮你省下几个周末的加班时间。

1. 兼容性分级：先搞清楚Pin-to-Pin到底兼容了什么

很多人一听到“Pin-to-Pin兼容”，下意识就觉得“我可以把STM32从PCB上拆下来，把国产芯片焊上去，代码不都要改，直接跑”。这个想法在过去几年确实有一部分芯片能做到，但前提是你得弄清楚“兼容”到底兼容到哪一层。

1.1 引脚兼容不等于整机兼容

Pin-to-Pin兼容的核心含义是封装和引脚定义一致。也就是说，原来STM32F103C8T6的LQFP48封装，第1脚是VBAT，第2脚是PC13，换上一颗同样LQFP48封装、引脚定义一样的国产芯片，PCB不需要重新画，理论上能焊上去。

但这里有个容易被忽略的点：引脚定义一致，不代表电气特性和电源域设计一致。我遇到过一颗芯片，引脚位置和STM32完全一致，但内部电源架构不同，VDD和VSS的分布导致PCB上原有的去耦电容摆放位置效果变差，在高频开关信号切换时出现电源纹波偏大的问题。后来加了两个100nF电容才稳定下来。所以，引脚兼容只是第一步，电源完整性、信号完整性这些PCB层面的东西，换芯片之后依然要重新评估。

1.2 兼容的三个层次

以我的经验，Pin-to-Pin兼容的“深度”可以分为三个层次，你在选型时必须先明确自己需要哪一层：

第一层是封装和引脚兼容。这是最浅层的兼容，好处是硬件改版成本低，但软件几乎全部要重写。适合本来就想借替代机会重构代码的项目。

第二层是寄存器级兼容。芯片厂商在设计时直接对齐了STM32的寄存器地址和位定义，甚至ROM里的系统Bootloader都兼容。这种芯片理论上可以直接跑STM32的固件，但这种完全兼容的芯片其实很少，而且往往涉及专利风险，厂商也不会公开宣传太多。

第三层是库函数兼容。厂商提供一套和STM32标准外设库或HAL库API高度相似的SDK，函数名、参数列表、调用方式都很接近。你移植代码时不需要改逻辑，只需要改少量配置项和时钟初始化代码。目前市面上大多数国产MCU走的是这条路线。

搞清楚兼容到哪一层，比什么都重要。因为你只有知道兼容的边界在哪里，后续做方案评估、工作量估算、风险控制才有依据。否则你抱着“直接替换”的预期去做，翻车几乎是必然的。

1.3 Cortex-M内核相同，但芯片不是一个模子刻出来的

还有一个认知偏差要说清楚：很多国产MCU和STM32用的是同一个ARM Cortex-M内核，比如Cortex-M3或Cortex-M4。但这只代表指令集和内核调试架构一样，不代表整颗芯片一样。外设是完全不同的数字逻辑设计，寄存器映射、中断号、时钟树、Flash控制器、复位管理、电源管理，每一个模块都是芯片厂商自己定义的。

举个最直观的例子：Cortex-M内核里有一个CPUID寄存器，ARM规定了这个寄存器格式，但芯片厂商唯一ID寄存器的地址是自主定义的。STM32的唯一ID在0x1FFFF7E8（F1系列），而某国产芯片放在0x1FFFF7E0附近，代码里如果直接读地址做设备识别，换芯片之后读出来的值根本不是那么回事。这种细节不踩一次坑很难意识到。

2. 换芯后第一批怪事：时钟树与复位时序的隐形差异

代码编译通过、烧录成功、上电之后，很多项目会在最基础的地方翻车——串口打印乱码、定时器时间不对、系统偶尔死机。这些问题多半出在时钟树和复位时序上。

2.1 默认时钟源和主频不完全一致

STM32F103系列上电后默认使用HSI（内部高速RC振荡器），频率是8MHz。而不少国产“兼容”芯片，虽然也内置了HSI，但标称频率可能是8MHz、16MHz甚至不同。更关键的是，HSI的初始精度、温漂特性、出厂校准寄存器的地址和校准方式都可能不同。

我接过一个实际案例：项目原来用STM32F103C8T6，系统主频72MHz，串口1配置成115200波特率。替代芯片焊上去之后，串口输出全是乱码。排查了好久，最后发现是HSI的实际频率偏高，PLL倍频后主频不是72MHz而是73.1MHz，导致波特率误差超过了UART容错范围。STM32系列芯片出厂时会对HSI做校准，校准值和校准寄存器地址在ST的参考手册里有明确说明，而国产芯片的校准机制往往不一样，直接沿用原代码等于没校准。

2.2 PLL配置寄存器：看起来一样，实际倍频关系不同

STM32F103的标准配置是HSI 8MHz ÷ 2 × 9 = 36MHz×2 = 72MHz，或者用HSE 8MHz × 9 = 72MHz。PLL的倍频系数放在PLLCFGR寄存器（F1是PLLSRC、PLLXTPRE、PLLMUL这几个位）。国产芯片如果寄存器布局和位定义完全对齐，那还好说；但如果只对齐了功能名称、不对齐位定义，你按STM32写的PLL配置代码，得到的实际主频可能完全不同。

这里有一个非常实用的检查方法：拿到国产芯片后，先看它官方提供的system_stm32f1xx.c文件或对应的SystemInit()实现，对比一下PLL配置寄存器的赋值语句。如果厂商的初始化代码里PLLMUL的值和你原工程里的不一样，说明这里就是第一个要改的地方。

2.3 外部晶振起振条件与复位阈值

除了内部时钟，外部晶振的差异也容易踩坑。STM32的HSE振荡器电路在设计时对晶振的负载电容、反馈电阻有明确的推荐范围。国产芯片内部振荡器电路不可能和ST做得一模一样，对晶振的驱动能力和反馈电阻要求就有差异。

我遇到过低温环境下系统无法启动的情况，后来排查发现是国产芯片的HSE振荡器起振时间比STM32长，而代码里等待晶振稳定的超时时间照搬了STM32的值，导致晶振还没起来就判定“外部晶振失效”，回退到HSI了。这种问题很隐蔽，因为常温下一切正常，到了低温实验室就现原形。

复位电路同样是重灾区。STM32的NRST引脚内置上拉电阻，外部只需要接一个100nF电容即可。国产芯片的复位引脚内部结构不同，上拉电阻阻值、复位脉冲最小宽度、POR（上电复位）阈值都可能不一样。如果你的板子上还有外部复位芯片，更要仔细核对复位阈值电压和时序图，否则可能出现上电时MCU复位释放时间早于电源稳定时间，导致MCU启动到一半又掉电，反复复位。

2.4 看门狗喂狗时序与LSI频率偏差

独立看门狗（IWDG）的坑也值得一提。IWDG的时钟源是LSI（内部低速RC振荡器），STM32F103的LSI典型值是40kHz，实际上可能是30kHz到60kHz之间。国产芯片同样有LSI，但频率范围、温度特性各有差异。

如果你沿用原来的预分频系数和重载值，实测看门狗溢出时间可能比设计值短很多。比如原设计1秒喂一次狗，实际900ms就复位了。系统在正常运行时看起来没问题，但任何一次稍微长一点的阻塞操作（比如擦除Flash）就可能触发复位。所以替代后一定要实测看门狗溢出时间，不要相信代码里的注释。

3. 外设寄存器与我们熟悉的HAL库：同名不同义

软件层面最大的坑，往往藏在“看起来能编译通过”的代码里。厂商为了兼容STM32，SDK里函数名和外设结构体都尽量向ST靠拢，但内部的寄存器操作可能差异巨大。

3.1 GPIO复用功能编号不一样

STM32从F4系列开始引入了AF（Alternate Function）编号概念，比如USART1_TX在PA9上的复用功能编号是AF7。F1系列没有AF编号，用的是USART1_REMAP等重映射位。国产芯片如果内核是M3，通常参考F1的寄存器设计；如果是M4，则参考F4的AF设计。这些看起来方向一致，但AF编号的排列顺序各家有各家的定义。

我在一个项目里用国产M4内核芯片替代STM32F401，代码里把PA9配置成AF7作为USART1_TX，结果串口没有输出。查了芯片手册才发现，这颗国产芯片的USART1_TX复用编号是AF1。当时在GPIO_PinAFConfig()里改一个数字就通了，但排查过程花了一下午。所以移植时，凡是涉及GPIO复用功能的代码，一定要打开新芯片的数据手册，逐个核对AF编号，别相信“应该差不多”。

3.2 HAL/标准库API的细微差异

国产厂商提供的“兼容ST标准库”或“兼容ST HAL库”，通常只是函数名一致、调用方式接近，函数内部的寄存器操作、参数校验逻辑、错误处理逻辑不可能完全一样。

举一个我实际遇到的问题：用HAL库的HAL_UART_Transmit()发送数据，STM32的实现会等待TXE标志，然后写数据寄存器DR。国产芯片的兼容库为了“优化性能”，改成直接写DR，没有检查TXE标志。结果在连续高速发送时，出现数据覆盖丢字节的问题。从代码层面看，两边都是调HAL_UART_Transmit()，你不看库源码根本不会发现行为差异。

所以移植后，建议把关键外设的驱动都过一遍库源码，至少要把串口、定时器、ADC、DMA这几个最常用的看一遍。不要抱着“API一样就完事了”的心态，否则出了问题你根本不知道从哪里查起。

3.3 中断向量表和外设中断号

中断向量表也是个大坑。Cortex-M内核规定了起始位置必须有向量表，但芯片厂商往向量表里填什么外设中断，那是完全自由的。STM32F103的USART1_IRQn是37，某国产F103兼容芯片可能把它定义成32，也可能把EXTI9_5_IRQn绑到另一个完全不同的中断号上。

代码里一旦写死“NVIC_EnableIRQ(USART1_IRQn)”，而USART1_IRQn这个枚举值在国产芯片的头文件里已经变了，编译不会报错（因为宏定义存在），但中断根本不会触发。这类问题最坑的地方是：代码能编译、能烧录、芯片能跑，但功能就是不对。排查时要先看启动文件startup_xxx.s里的中断向量表，确认外设中断名是否和你要用的一致，再看头文件里的中断号定义，两边对齐了才算没白花时间。

3.4 DMA请求映射与优先级

DMA是外设里最容易出问题的模块之一。STM32的每个DMA通道可以对应多个外设请求，通过DMA_CCR的PL位和请求映射来配置。国产芯片虽然也提供DMA，但外设到DMA通道的映射关系很可能不同。

热词搜索里有“stm32 hal库adc单通道dma多次采样”，这个场景特别典型。ADC用DMA搬运数据，原来STM32F103的ADC1对应DMA1通道1。到了国产芯片，ADC1可能只能挂在DMA1通道3上，或者需要额外设置一个请求选择寄存器。如果不改初始化代码，DMA永远不会触发搬运，ADC数据寄存器里的值一直不变，但你不看寄存器根本看不出来。移植时务必核对DMA请求映射表，这在用户手册里一定有一张专门的表格。

4. 调试、烧录与量产环节的隐性问题

很多项目在开发阶段一切顺利，到了产线批量烧录时突然问题爆发。“为什么板子在开发板上是好的，一到产线就烧不进去”这种灵魂拷问，经历过的人都懂。

4.1 调试器报错：no stm32 target found

当你用ST-Link或者J-Link去连接国产MCU时，最常遇到的报错就是“error: no stm32 target found! if your product embeds debug authentication, please..."。这个报错信息虽然以stm32命名，但实际上很多国产MCU都适用。出现这个错误不一定代表芯片坏了，往往是SWD接口时序、复位控制或电源域的问题。

ST-Link默认以SWD方式连接ST芯片，连接时有特定的复位时序和IDCODE校验。国产芯片的SWD实现虽然跟随Cortex-M内核的调试架构，但IDCODE可能是厂商自定义的值，ST-Link的驱动不一定认识。J-Link相对好一些，因为SEGGER对新芯片的支持通常比较积极。

解决方法有几个：一是改用J-Link或DAP-Link，它们在识别非ST芯片方面更灵活；二是在调试器软件里开启“Connect under Reset”模式，让调试器先拉低复位脚再连接目标芯片，防止芯片运行中的程序干扰调试口；三是降低SWD通信速率，老版本驱动在4MHz下连不上，降到1MHz或500kHz可能就好了。

如果是自制板，还要检查SWDIO和SWCLK引脚的上下拉电阻。STM32的SWDIO内部上拉、SWCLK内部下拉，但有些国产芯片内部的上下拉配置刚好相反，导致外部调试器默认的电平状态对不上。这种情况下，在PCB上给SWDIO加一个10kΩ上拉、给SWCLK加一个10kΩ下拉，能解决很大一部分连接问题。

4.2 Flash下载算法与选项字节

ST-Link Utility或STM32CubeProgrammer烧录STM32时，会自动匹配对应的Flash下载算法，比如STM32F103系列用STM32F1xx_128KB这个算法文件。换成国产MCU后，如果你还在用ST的工具链，下载算法肯定对不上。

更麻烦的是选项字节。STM32的选项字节里有读保护等级（RDP）、看门狗配置、BOOT配置等。不同芯片厂商虽然都叫“选项字节”，但地址、位定义、写入方法各不相同。有人图省事，直接用STM32CubeProgrammer去修改国产芯片的选项字节，结果把芯片的配置区写乱，芯片直接锁定，再也连不上了。

量产烧录建议：优先用原厂提供的烧录工具、烧录软件和下载算法。比如GD32有GD-Link和对应的烧录上位机，AT32也有自己的工具链。除非你非常确定第三方工具已经支持这款芯片，否则不要拿ST的工具硬扛。

4.3 Bootloader与OTA升级的兼容性

如果你的产品需要OTA升级，Bootloader这部分几乎是绕不开的坎。STM32在系统存储器（System Memory）里固化了ROM Bootloader，支持通过USART、USB DFU、CAN等接口升级用户程序。用户可以在BOOT0拉高、BOOT1拉低的条件下进入这个Bootloader，用ST的官方工具下载固件。

国产芯片大多也内置了ROM Bootloader，但协议往往不兼容ST。比如握手命令、数据包格式、块地址定义都可能不同。如果你原来的上位机升级软件是按AN3155（STM32 USART协议）写的，换国产芯片之后大概率不能直接通信。

自定义Bootloader同样有坑。STM32的Flash操作是半字（16位）编程，一个扇区1KB（F103小容量）或2KB。某些国产芯片的Flash页大小、擦除时间、编程粒度都不一样。我遇到过擦除Flash时因为页地址计算错误，把Bootloader自身所在的页给擦了，直接变砖。所以在写自定义Bootloader时，一定要仔细读新芯片的Flash编程手册，拿最小页大小和地址对齐规则重新算一遍。

5. 外部配合器件与周边生态：ESD、晶振、通信模块全要重新磨合

MCU从来不是孤立工作的。它与外围的晶振、复位芯片、电平转换器、WiFi模块、传感器、伺服驱动器之间的配合，在替代后都需要重新验证。

5.1 外部晶振与匹配电容的参数匹配

很多国产MCU的设计参考手册里会给出HSE振荡器的推荐参数，包括负载电容CL、反馈电阻RF、振荡器驱动等级。这些参数和ST的推荐值很可能不一样。

举个例子：STM32F103参考手册推荐HSE用8MHz晶振配10pF到22pF负载电容。某国产芯片官方推荐的是8MHz配6pF，如果你的板子上还是原来10pF的电容，可能会造成振荡器起振困难或振荡幅度过小，表现为系统偶尔启动失败、或者晶振波形幅度不足导致时钟丢失。

处理办法很笨但很有效：按国产芯片手册的推荐值重新计算匹配电容，并且在打样时在晶振附近预留0603封装的贴片电容焊盘，方便调试时换电容试值。另外，有条件的话用示波器（高阻探头）实测晶振波形幅度和起振时间，这是最直接的验证手段。

5.2 外部复位芯片与电源监控

原设计用STM32时，板子上可能有一颗外部复位芯片，用来做电源监控和上电复位。STM32的复位阈值、POR延时和大多数复位芯片是匹配的，但国产芯片的复位阈值、上电复位释放电压可能不同。

如果外部复位芯片的阈值电压高于MCU的POR阈值，可能会出现MCU已经离开复位状态开始跑代码，但复位芯片仍然拉着NRST脚不放的情况。反过来，如果复位芯片阈值太低，MCU可能在电源还没稳定时就上电运行，读取Flash初始化数据出错，造成启动异常。

这种问题在实验室里用稳压电源供电时很难暴露，批量生产时不同批次电源适配器的上电时序差异就会让它频繁出现。最稳妥的方案是，替代后实测MCU电源引脚的爬坡时间和NRST释放时间，确认与MCU数据手册中的要求一致。

5.3 通信模块的时序与电平配合

很多项目里MCU要跟ESP8266、K210这类模块通信，或者通过485总线控制伺服驱动器。这些通信链路的稳定性高度依赖MCU串口的时序精度和IO电平特性。

热词里有“esp8266 wifi模块教程stm32”和“k210与stm32通讯”，我做过类似的应用，替代后最先出问题的是波特率精度。ESP8266串口波特率默认115200，对波特率误差要求比较严格。STM32用8MHz HSE时钟算出来的波特率很准，但国产芯片如果HSI没有校准，或者外部晶振参数不匹配导致系统时钟偏移，波特率误差一旦超过2%，ESP8266就会出现偶发性的乱码或者AT指令无响应。

485通信的坑在于DE/RE方向控制引脚的时序。MCU发送前要把DE拉高，发送完成后拉低，这个切换时机对代码执行时间和GPIO翻转速度敏感。不同芯片的GPIO翻转速度、串口发送完成标志位的置位时机不同，导致切换过早或过晚，接收端就抓到半帧错误数据。替代后建议用逻辑分析仪抓取DE引脚的波形和串口TX波形，确认两者时序关系正确。

5.4 低功耗特性与唤醒源

做电池供电产品的朋友要注意，低功耗模式的参数是最容易缩水的。STM32F103在停机模式下的典型电流是14μA左右（关掉所有外设时钟），一些国产芯片声称兼容，实际测量到了20μA甚至更高。更有意思的是，有些芯片在待机模式下的唤醒源不同——原来用RTC唤醒的代码，替代后可能不支持RTC唤醒，或者唤醒时间从几微秒变成几十微秒。

我之前做过一个水表项目，要求整机静态功耗低于15μA，替代后整机功耗超标，排查了一圈发现是MCU的RTC待机电流比STM32大了8μA。最后只能重新选型，这也说明替代评估不能只盯着功能和引脚，功耗指标必须拿到样片实测算数。

6. 替代移植实操：一套我自己验证过的落地流程

前面说了这么多坑，并不是劝你放弃国产替代，而是建议你按一套流程来走，把风险控制在可控范围内。下面的流程我实际跑过三轮，踩完坑之后总结出来的，照着做能省不少时间。

6.1 选型阶段先做差异清单

不要只看“管脚兼容”和“Flash容量一样”就拍板。选型时建议列一张对比表，至少包含以下项目：内核型号、最高主频、Flash/RAM大小、引脚定义、GPIO驱动能力、ADC参考电压、DMA通道映射、中断号定义、看门狗时钟源、RTC时钟源、POR/BOR阈值、低功耗电流、调试接口兼容性、烧录工具支持、SDK版本与API兼容程度。

这张表一半靠看数据手册，一半靠找原厂FAE确认。很多国产芯片原厂的技术支持非常给力，你直接问他们“和STM32F103C8T6的差异清单有没有”，他们通常会发你一份现成的对比文档。这份文档比你自己从手册里扒要准确得多，建议优先找原厂要。

6.2 最小系统验证：先跑裸机再跑外设

拿到样片后，先不要着急把完整工程烧进去。先在最小系统板上验证以下内容：上电复位是否正常、HSE外部晶振起振是否正常（示波器测）、SystemInit后主频是否准确（可以用定时器PWM输出来量）、GPIO翻转速度、串口自发自收、定时器中断频率、ADC转换值是否正确。

这一轮验证的目标是把“芯片本身是否正常工作”这个基本盘摸清楚。如果这一步都通过不了，后面的应用移植没有意义。

6.3 逐模块移植，每移植一个模块做一次回归

不要一次性把整个工程从STM32工程替换成国产SDK重新编译，那样出问题根本不知道是哪个模块引起的。我的做法是：先保留原来的Main函数和业务逻辑，把底层驱动逐个替换成国产芯片的SDK版本。

模块顺序建议：时钟和系统初始化、GPIO、串口（普通收发）、定时器（基础定时）、PWM输出、ADC、DMA、外部中断、Flash读写、低功耗模式。每完成一个模块，就编译、烧录、跑一个最小验证程序，确认功能正常后再进行下一个模块的移植。

如果项目里有第三方库，比如FreeModbus、LVGL、FatFs这些，等到底层驱动都验证通过后再说。像“freemodbus stm32移植”“lvgl移植stm32”这类场景，底层串口和定时器没有问题了，协议栈移植本身通常不会有大问题。

6.4 压力测试与长期稳定性验证

功能验证通过后，至少要做72小时连续运行测试。跑一个综合测试程序：串口持续收发、定时器中断持续触发、ADC持续采样、Flash周期性写入，同时监测设备是否有死机或数据异常。

如果产品是低功耗应用，还要专门做低功耗电流测试，观察休眠、唤醒、正常工作三个状态的电流值以及状态切换时的电流尖峰。有条件的话，把板子放进高低温箱，做-20℃到+70℃的温度循环测试，替换芯片后温度特性不用重新评估是不行的。

6.5 量产烧录与产测流程的适配

最后一步是量产环节的适配。确认原厂烧录工具是否支持你的芯片型号，如果支持，最好用原厂工具链做一次批量烧录测试。产测程序也要重新跑一遍，特别是需要读取芯片唯一ID做设备标识的功能，要确认ID寄存器的地址和长度是否已经更新到新代码里。

另一个量产环节的隐性坑是芯片丝印和包装。部分国产芯片的丝印规则和STM32不同，AOI设备或者人工目检的判别标准要更新。静电敏感等级也可能不同，生产线的ESD防护等级和拿取方式都要同步更新，不然产线不良率会让你怀疑人生。

7. 两个容易被忽略的特殊场景：ESP32与STM32通信、STM32Cube生态依赖

有些项目不只涉及MCU本体替换，还牵扯到MCU与外部主控之间的通信。比如你的设备里有一个ESP32模块和一个STM32，现在想把STM32换成国产MCU，此时外部通信协议可能也要重新梳理。

7.1 MCU与WiFi/Camera模块的接口协议

ESP8266、ESP32、K210这类模块与STM32之间通常是串口通信，可能有简单的AT指令协议，也可能是自定义的二进制帧协议。替代后MCU端串口的时序、波特率的精确度、流控引脚的时序都会影响通信稳定性。

我给一个建议：在代码里增加一个“通信测试模式”，开机后持续发送带序列号的测试帧，对端收到后原样返回，MCU端检查序号是否连续、CRC是否正确。这个测试跑一个晚上都不出错，再谈业务逻辑优化。

7.2 对STM32CubeMX/CubeIDE的高度依赖

很多工程师习惯用STM32CubeMX生成初始化代码，这在原平台开发时效率很高。但国产MCU目前大多不支持CubeMX，你需要改用手写初始化代码，或者用厂商自己的配置工具。

这种情况下，原有工程里由CubeMX生成的main.c、stm32f1xx_hal_msp.c等文件不能直接搬到国产工程里。如果你在替代时还想着“尽量保留CubeMX代码”，会非常痛苦。更务实的做法是重写这几个初始化文件，只保留业务逻辑部分和应用层代码。我在迁移时通常把原工程分成三层：底层驱动、中间层协议、应用逻辑。底层完全重写，中间层按需适配，应用层尽量不动。

最后的几点提醒

回过头来看，国产MCU替代STM32这件事，本质上是“从ST的舒适区走出来，重新认识一颗新芯片”的过程。Pin-to-Pin兼容解决的是PCB能不能焊上去的问题，真正要解决的还是时钟、复位、外设、调试、量产这一整套工程问题。

我给个人体会最深的三条经验：第一，选型前务必找原厂要迁移指南，那上面写清楚了很多用户手册里不写但实际改代码时一定会碰到的差异；第二，不要用ST的烧录工具烧国产芯片，老老实实装好原厂的烧录器和上位机；第三，替代不是一锤子买卖，小批量试产、压力测试、高低温验证一个都不能省。

有个小技巧分享给大家：在调试国产MCU时，如果遇到“莫名其妙”的问题，先看芯片的勘误表（Errata Sheet），再查原厂的技术支持论坛。很多时候你以为自己在踩新坑，其实芯片原厂早就把坑写在勘误表里了，只是你没翻到那一页而已。