CMSIS-4遗产代码库的静态工程评测：迁移前如何摸清底细

1. 为什么“尽调”比“开干”更适合CMSIS‑4这种遗产代码库

1.1 一个新同事视角：你接手的老工程到底藏着什么

我见过太多这样的场景：项目组里来了新同事，领导把一个“历史遗留固件”丢过去，说“看一下，最近要把芯片换了/工具链升一下/加个AI功能”。新同事打开工程一看，core_cm4.h、startup_stm32f10x_hd.s、system_stm32f10x.c，一堆熟悉又陌生的文件躺在那里。大部分人的第一反应是“先编译一下试试”，结果要么报几百条警告，要么直接链接失败。然后开始网上搜“arm编译器下载”“arm compiler 5.06u7”之类的东西，一头扎进版本号里出不来。

ARM的CMSIS（Cortex Microcontroller Software Interface Standard）从2008年左右确立至今，已经十几年了。CMSIS‑4作为其中一个经典版本，至今还大量存在于量产项目、老款开发板、各种第三方SDK和高校教学代码里。很多芯片厂商的早期标准外设库，比如STM32F10x标准外设库、NXP早期LPCopen，底层挂的都是CMSIS 3或CMSIS 4时代的头文件和启动文件。这些代码不是“烂代码”，它们是整个Cortex‑M生态的地基。只不过地基年代久远，上面盖的房子换了好几茬，新来的施工队看着地基的图纸难免发怵。

这篇文章想聊的，就是拿到这样一个CMSIS‑4老工程时，不要急着改代码，先做一次“源码静态工程评测”。所谓静态评测，是指在不依赖真实硬件、不烧录、不调试的情况下，通过源码层面的结构分析、编译告警、静态分析工具和依赖关系梳理，把这个工程的底细摸清楚。这套方法对嵌入式固件工程师、架构师、新接手老项目的人，以及准备做工具链升级或跨平台迁移的团队，都很有参考价值。

1.2 “尽调”不是重构，而是审计

“尽调”这个词本来是投资领域的，放到代码工程上很容易被误解成“我要把代码重写一遍”。实际上，尽调的核心动作是审计，不是重构。

重构是把代码改好，审计是把代码看懂并量化风险。做CMSIS‑4老工程的静态评测，目标是把下面这些问题的答案摆到桌面上：

• 这个工程里到底有哪些CMSIS文件，哪些是厂商改过的，哪些是原装的？
• 它依赖的具体是CMSIS 4.x哪个小版本？文件结构和CMSIS 5.x有多大差异？
• 它在编译时依赖多少非标准语法、旧编译器特性？换编译器会死得多惨？
• 启动文件、链接脚本、设备头文件之间有没有“历史补丁”，比如厂商为了适配某个特殊型号在启动文件里手工加的段定义？
• 迁移到新版本CMSIS或新工具链时，哪些是硬约束，哪些只是警告级别的小事？

这些问题如果靠“开干”来回答，会出现一种很尴尬的情况：你改了几天代码，编译通过，下载到板子上发现外设工作异常，然后你根本分不清到底是迁移引入的问题，还是老工程原本就有的隐性问题。而静态评测的优势在于，它在没有硬件干扰的情况下，先把源码层面的风险全部暴露出来。不烧板子，不动外设，不接示波器，只靠编译器、静态分析器和代码阅读，就能产出一份“能不能迁、怎么迁、迁多久”的评估结论。

1.3 谁需要这份静态评测

我把需要这份评测的人分成三类。

第一类是“被迫接手老工程”的工程师。别人写了三年的固件，代码风格、宏开关、中断优先级布局全是历史包袱，你需要在短时间内交付新需求。静态评测能帮你快速建立认知地图，知道哪些地方是雷区。

第二类是“准备升级工具链”的团队。老工程还挂在ARM Compiler 5上，新MCU或者新IDE默认用armclang（AC6），两个编译器对CMSIS头文件的处理逻辑差异很大。升级之前不做评测，等着你的就是几百条编译错误和一脸懵。

第三类是“要把旧代码迁移到新芯片/新平台”的团队。比如原来在Cortex‑M3上跑的好好的代码，要挪到Cortex‑M4或者Cortex‑M7上；原来用MDK的工程，要迁移到GCC工具链；甚至有人要把算法代码从x86环境挪到ARM Linux上——虽然那是更高层面的迁移，但底层CMSIS部分同样适用“先静态评测后动手”的思路。

2. CMSIS‑4的版本坐标与源码资产盘点

2.1 CMSIS家族树里，v4处在什么位置

CMSIS的版本演进，可以看作一颗不断分叉的家族树。

CMSIS 1.x是2009年前后的开山之作，定义了最基础的Cortex‑M内核寄存器访问方式。CMSIS 2.x开始了CorePlus的概念，把外设访问层从内核层中抽离出来。CMSIS 3.x是很多老工程师最熟悉的版本，STM32标准外设库早期版本基本都跑在CMSIS 3上面，常见文件是core_cm3.h和core_cm4.h。CMSIS 4.x在2015年前后达到成熟，它把Cortex‑M0/M0+/M3/M4全部统一，并且在4.2加入了对Cortex‑M7的支持，4.5以后又加入了CMSIS‑NN神经网络库。CMSIS 5.x是一次大革新，目录结构、编译器抽象、RTOS v2接口全面铺开。再往后CMSIS 6.x则进一步压缩了冗余。

为什么CMSIS‑4至今还有大量遗留代码？因为它和AC5编译器（armcc）搭配得太顺了。CMSIS 4时代，ARM官方同时维护cmsis_armcc.h和cmsis_gcc.h，分别对应MDK的ARMCC编译器和GCC。在MDK环境下，armcc能完美处理CMSIS 4的内联汇编、位操作、特殊寄存器访问。而CMSIS 5时代主推armclang（AC6），AC5被逐步淘汰。很多量产项目经理的想法是：“代码跑得好好的，为什么要动？”于是，一大批CMSIS‑4工程被冻结在了AC5工具链上。

2.2 一个典型CMSIS‑4工程的源码资产清单

做静态评测的第一步，是把工程目录展开，列资产清单。一个典型的CMSIS‑4老工程通常包含以下部分：

• CMSIS内核头文件：core_cm0plus.h、core_cm3.h、core_cm4.h、core_cm7.h。
• 编译器适配头文件：cmsis_armcc.h、cmsis_gcc.h，部分小版本还有cmsis_compiler.h。
• 版本文件：cmsis_version.h，里面定义了__CMSIS_VERSION_MAIN/SUB/REV三个宏。
• 设备级头文件：stm32f10x.h这类厂商出品的头文件，内部会#include "core_cm3.h"。
• 系统初始化文件：system_stm32f10x.c和对应的头文件，负责时钟初始化，导出SystemCoreClock变量。
• 启动文件：MDK对应的是.s汇编文件，如startup_stm32f10x_hd.s；GCC对应的是另一个.s；IAR对应的是.s或.icf。
• 链接脚本/分散加载文件：GCC的.ld文件、MDK的.sct分散加载文件、IAR的.icf文件。
• 如果用了DSP，则会有arm_math.h和libarm_cortexM4lf_math.a这类预编译库。

这些文件里，core_cm4.h这类内核头文件通常是ARM官方原封不动的，厂商不会改它；而stm32f10x.h和system_stm32f10x.c是厂商把CMSIS作为基底，再叠加上自己的外设寄存器定义和外设驱动。

2.3 资产盘点怎么做才不留死角

我会建议把工程目录复制一份，保持原始工程冻结不动，在副本上做评测。这样后面即使改乱了，也不影响原始交付基线。

盘点的具体动作，一是用tree命令把整个目录树导出来，把每类文件的来源标注清楚：哪个是ARM官方的，哪个是芯片厂商的，哪个是自己写的，哪个是第三方库带来的。二是对cmsis_version.h和core_cm4.h做哈希值记录，万一后续升级头文件，能精确知道“哪个文件在哪一天从什么版本变成了什么版本”。

一个很容易被忽略的地方是：很多老工程里同一个头文件会出现多份拷贝。比如MDK安装目录的C:\Keil_v5\ARM\PACK\ARM\CMSIS\4.5.0\CMSIS\Include下面有一份core_cm4.h，工程目录的Libraries\CMSIS\Include里也有一份。编译器实际用的是哪一份，取决于Include Path的搜索顺序。静态评测时要用arm-none-eabi-gcc或armclang的-H选项，或者MDK里的--preinclude方式，把真正被包含进去的文件路径抓出来。不然，你辛辛苦苦核对半天，发现编译器用的根本不是你以为的那份头文件，那就白干了。

3. 静态评测的实操方法与评测指标设计

3.1 评测环境准备：双编译器方案

静态评测的核心手段，是让同一个工程在不同编译器下各编译一遍，观察差异。我的做法是准备两个环境：一个是MDK‑ARM，用来模拟老工程原来的AC5环境；另一个是GCC ARM Embedded工具链，用来模拟迁移后的新环境。如果目标方向是AC6，那就用armclang替代GCC，但GCC更通用，我自己评测时优先用GCC做迁移风险评估。

GCC这套环境在Windows和Linux上都能搭，本质就是一个arm-none-eabi-gcc工具链加上几个命令行参数。举个例子：

arm-none-eabi-gcc -mcpu=cortex-m4 -mthumb -mfloat-abi=hard -mfpu=fpv4-sp-d16 \ -D__FPU_PRESENT=1 -D__MPU_PRESENT=1 -D__NVIC_PRIO_BITS=4 \ -ICMSIS/Include -IDevice/Include \ -c main.c -o main.o

这一行命令里的-mcpu、-mfloat-abi、-mfpu定义了目标内核和浮点模型；-D宏定义是CMSIS-Core在编译时最依赖的开关；-I指定CMSIS头文件和设备头文件的搜索路径。把工程里的每个.c文件都用这种方式编译一遍，很多问题当场就会暴露。

3.2 编译基线与告警经济学

先做一件事：用老编译器把整个工程编译一遍，记录Error和Warning数量，这叫作“编译基线”。

很多CMSIS‑4老工程的基线是“告警有毒”状态——自带几百条Warning，工程师早就看习惯了。但请注意，在告警里筛选出真正要紧的类别，是静态评测最划算的一步：

• #pragma相关的告警，说明代码里有大量编译器专有指令；
• implicit declaration of function，说明有函数没有包含正确头文件，这在老工程里往往是漏了cmsis_os.h或者arm_math.h;
• type-conversion告警，说明有隐式类型转换，在浮点和DSP代码里尤其需要注意；
• declaration after statement，说明代码风格偏老，换到AC6/armclang之后可能会触发更严格的告警策略。

评测经验是：如果老工程在AC5下自带超过300条Warning，那它换到AC6或GCC后，Error数量很可能会超过100条。这不是“工具链变了代码坏了”，而是旧代码一直依赖编译器的“溺爱”。静态评测的意义，就是提前量化出这个数字，让你在排期时有底气说“光清理告警就需要三天”。

3.3 静态分析器的引入和依赖梳理

编译只是第一步，真正能挖出深层次风险的是静态分析器。我最常用的是Cppcheck和Clang-Tidy，因为它们免费、可脚本化、适合集成到评测流程里。

Cppcheck对C代码的支持很成熟，用来扫CMSIS老工程特别合适，能找出数组越界、空指针解引用、未初始化变量等问题。Clang-Tidy更激进，适合检查Cortex‑M编程里的常见陷阱，比如：

• 未定义行为：移位位数超过变量宽度；
• 隐式整数截断：把一个uint32_t赋给uint16_t；
• 指针别名问题：特别是DSP缓冲区操作时，编译器优化可能产生你不想要的结果。

依赖关系梳理方面，我建议做两件事。第一件事是把每个.c文件的#include列表拉出来，用脚本生成一个“头文件依赖图”，找出哪些头文件是全工程的中枢。通常你会看到stm32f10x.h或者某个类似的设备头文件被几十个文件引用，那它一旦改动，影响面就是全局的。第二件事是用nm工具查看编译产物的符号表，看看哪些函数是从哪个库打进来的。CMSIS‑4老工程链接错误里，最常见的就是“undefined symbolSystemInit”或者“undefined symbol__initial_sp”，这些符号在启动文件里定义，找出来就能快速定位问题。

3.4 评测指标表的搭建

评测不能凭感觉，要落到一张表上。我习惯按下面的维度建表。

这张表填完之后，整个工程的健康状况基本就清晰了。

4. 评测中真实踩到的四个坑

4.1 ARM Compiler 5/6切换引发的“宏定义失踪”

我在评测一个老工程时遇到过一个非常典型的坑：工程原本在AC5下编译一切正常，换到AC6（armclang）后，报了一堆莫名其妙的错误，比如__forceinline未声明、__ASM未定义、__STATIC_INLINE被重定义。

原因是CMSIS 4的cmsis_armcc.h是针对AC5的，专门给armcc用；而armclang是Clang前端，它对内联汇编和设备访问的实现方式完全不一样，需要走cmsis_armclang.h那个分支。CMSIS 4.4之前的版本甚至没有cmsis_compiler.h这个统一入口，所以AC5的老头文件拿给AC6编译，等于让一个讲方言的人做同声传译，设备寄存器的访问宏、__NOP()、__WFI()这些基础指令全部识别不了。

处理方案有两个。第一个是长期方案：把CMSIS内核头文件整体升级到CMSIS 5.x，让armclang走它对应的适配层；第二个是临时方案：在AC6下编译时，手动定义一套兼容宏，把__forceinline映射成__attribute__((always_inline))。但临时方案只适合快速过编译，不适合量产交付，因为内联汇编的语义可能在编译器升级后悄悄改变。

4.2 调试器连接“No Cortex-M SW Device Found”的背后

很多人在评测老工程时会顺手接上开发板，想跑一下验证。结果一按下载，调试器给了三个大写单词：No Cortex-M SW Device Found。

这个报错很容易被当成“硬件问题”甩给硬件工程师，但静态评测告诉我，它经常源于工程配置的版本错位。逐个排查的顺序：

第1步，确认MDK的Device选项里选的芯片型号和实际芯片一致。老工程如果是从别的型号复制过来改的，很可能Device型号没改，调试器用旧型号的SWD配置去连新芯片，当然找不到。

第2步，确认Flash Download算法配置。老芯片的 Flash 算法列表里只有旧的Flash大小，新芯片Flash容量不同，下载时地址越界，就会在连接阶段报错。

第3步，检查调试器的时钟频率。老工程默认SWD时钟可能是Auto，但如果接了很长的杜邦线，或者板载调试器的引脚走线有问题，把SWD时钟从4MHz手动降到1MHz，多数情况下就能解决。

第4步，确认有没有复位电路异常导致内核jtag/swd接口处于异常状态。如果按住复位键再点下载能成功，那多半是硬件复位电路的问题。

这个坑放在静态评测文章里很合适的一点是：它提醒我们，评测阶段如果非要接硬件验证，先把工程配置从“老的”调到“新的”，再谈硬件问题，否则很容易冤枉无辜的硬件工程师。

4.3 启动文件与链接脚本的历史包袱

CMSIS‑4老工程的启动文件，是我每次评测都会花很多时间看的东西。原因很简单：启动文件里藏着的往往不是技术，而是历史。

比如一个生产了三年的项目，启动文件里Stack_Size还是EQU 0x00000400，也就是1KB的栈。当初产品功能简单，RTOS没用上，1KB栈够跑。后来迭代加了网络协议栈、文件系统，代码量翻了几倍，但还是沿用老启动文件，结果就是程序跑到深处栈溢出，表现出来就是奇怪的hard fault，翻遍代码都找不到原因。静态评测时，我会把Stack_Size和Heap_Size摘出来，直接和当前工程的全局变量总量对比，一眼就能看出是不是有栈风险。

链接脚本是老工程的另一个“历史补丁重灾区”。有些老工程师为了让某个尾插数据段落在一个特定地址，会在.sct文件里手写一个固定的地址段；后来需求变了，这个地址段可能和新芯片的RAM地址重叠了，但没人敢删。静态评测要做的是，把这些“人为痕迹”全部标注出来，再对照目标芯片的存储映射手册，逐个核对地址范围。

4.4 设备头文件“版本漂移”的隐性风险

还有一种坑是“版本漂移”：工程目录里放着一个厂商改过的stm32f10x.h，和标准CMSIS‑4共存的stm32f10x.h有细微差异。差异通常出现在厂商为了适配某个新批次芯片而添加的宏开关，比如#ifdef STM32F10X_XL，或者把某些外设中断号重新排列。

这类差异在静态编译时往往不会报错，因为插入的代码只是增加了一个宏定义或者一个枚举值，但运行时的风险很大。比如，厂商在新头文件里把某个外设中断向量的IRQn值改了，而中断向量表还是老的，那这个外设一打断，程序就会跳进一个错误的ISR。静态评测阶段如果发现设备头文件不是“原装的”，我的建议是把新旧头文件做一次diff，把差异文件留存为评测报告的附件，提醒后续迁移时务必统一。

5. 迁移到CMSIS‑4的约束清单与逐项处理方案

5.1 约束一：头文件与包含路径必须收敛

CMSIS‑4工程的第一个硬约束是头文件路径。很多老工程在MDK的Include Paths里写的是..\Libraries\CMSIS这种宽泛的路径，编译器会递归搜索整个CMSIS目录。这在当时能用，是因为CMSIS目录结构简单。但一旦加进来多个版本的头文件，或者换到GCC/AC6，路径解析逻辑变了，就非常容易包含错文件。

正确做法是把Include Path收敛到最小集合：

..\CMSIS\Include ..\Device\Include

注意，Device\Include和CMSIS\Include要分开列，不要图省事直接写..\CMSIS。如果工程里用了CMSIS‑DSP，再加..\CMSIS\DSP\Include；用了CMSIS‑RTOS v1，再加..\CMSIS\RTOS\Include。

5.2 约束二：编译器内置宏的显式声明

CMSIS‑4的代码在编译时会查看一组关键宏来决定启用哪些特性。这组宏如果不定义，或者定义得跟内核不匹配，轻则代码优化不到位，重则功能异常。典型的是这几个：

• __CM4_REV：Cortex‑M4的修订版本号，用来决定某些勘误表处理逻辑，值要跟具体芯片型号的历史参考手册对齐。
• __FPU_PRESENT：是否带FPU。如果芯片是Cortex-M4F而不定义这个宏，浮点寄存器的访问代码会被排除掉，写浮点运算时编译正常但运行会进hard fault。
• __MPU_PRESENT：是否带MPU，没有MPU的型号定义了这个宏，代码访问MPU寄存器会写进非法地址。
• __NVIC_PRIO_BITS：中断优先级位数，Cortex‑M3/M4通常是4，M0/M0+是2，定义错误会导致优先级分组API行为混乱。
• __Vendor_SysTickConfig：为0表示用CMSIS自带的SysTick配置函数，为1表示让厂商驱动接管，两个值对应不同的代码路径。

在GCC环境下的做法，是在编译命令行统一加上：

-D__FPU_PRESENT=1 -D__MPU_PRESENT=1 -D__NVIC_PRIO_BITS=4 -D__Vendor_SysTickConfig=0

在MDK的C/C++选项里也可以定义，但我见过很多老工程的宏定义是散落在设备头文件里的某个#define角落，评测时最好把它们全部抽出来，集中在头文件的最前面或者编译命令行里，避免后续改动时找不到入口。

5.3 约束三：启动文件、分散加载与链接脚本

启动文件是CMSIS‑4工程最敏感的部分。不同工具链语法不同：AC5的.s文件用AREA语法，GCC的.s文件用.syntax unified语法，两者不能混用。换工具链时必须把启动文件一并换成对应工具链的版本，不能只换编译器。

启动文件里需要重点检查的元素：

• Stack_Size和Heap_Size：建议至少0x400起，实际视工程需求放量；
• __initial_sp符号：链接脚本或分散加载文件会用到它作为初始栈指针；
• Reset_Handler：看它是否调用了SystemInit，以及是否在跳转__main前做了一些脏活；
• 中断向量表：确认每一项对应的ISR函数名和厂商外设库里的定义一致。

GCC工程还要核对.ld链接脚本里的内存区域。比如Cortex‑M7有TCM和AXI SRAM之分，老工程可能把RAM全挂在RAM区域，但新芯片的RAM起始地址变了，要按新芯片的存储映射重新划分。类似问题，静态评测时可以通过阅读链接脚本直接发现，比烧录后死机再查快得多。

5.4 约束四：DSP/NN库的接口与ABI兼容

CMSIS‑4工程里如果用了DSP库，迁移时就要格外小心。CMSIS 4的arm_math.h路径是CMSIS/DSP_Lib/Include，到了CMSIS 5.x变成CMSIS/DSP/Include。路径变还算小事，更大的问题是数学函数接口在部分版本里有调整，比如一些矩阵函数新增了状态结构体参数。

更麻烦的是ABI兼容性。CMSIS‑4的DSP预编译库是拿当时的AC5或其他工具链编出来的，换到AC6或GCC后，编译器的函数调用约定、结构体内存对齐规则、浮点参数传递方式都可能有差异，直接链接旧库会出现符号找不到或者调用参数错乱。正确做法是拿到新工具链后，把DSP库源码重新编译一遍，而不是继续用老的.a预编译库。

CMSIS‑NN的情况类似。CMSIS 4.5才开始加入NN库，如果老工程是4.4以前的版本，想用NN库做Cortex‑M上的AI推理，就必须先把CMSIS内核头文件升级到5.x或者至少4.5+。这也是为什么现在很多老工程做静态评测时，会顺手评估“要不要借这次迁移把CMSIS基线升到5.6以上”。

5.5 约束五：RTOS层从v1到v2的取舍

老工程如果跑RTOS，大概率用的是CMSIS‑RTOS v1接口，比如osDelay、osMessagePut这类函数。而CMSIS 5.x主推的是CMSIS‑RTOS v2，接口命名统一成了osDelay改成osDelay虽然名字没变，但很多入参和返回值类型从int8_t改成了osStatus_t，签名变了。CMSIS‑4和CMSIS 4.5时代的RTOS v1接口，在CMSIS 5里虽然还能用兼容头文件，但ARM官方明确不再维护v1。

我的建议是：如果工程体积不大、RTOS用得浅，就趁迁移时把RTOS调用层切到v2；如果工程RTOS依赖很深，而且团队短期没有精力做回归测试，就还是在评测报告中给出“冻结CMSIS‑4，不升RTOS”的结论。迁移RTOS是业务层面的事，不是头文件版本能解决的问题。

5.6 约束六：许可证和来源盘点

静态评测还有一个容易被忽略但很重要的维度——许可证。CMSIS‑4本身是Apache 2.0授权，但芯片厂商在CMSIS基础上扩展的设备头文件、启动文件、外设驱动库，许可证策略可能完全不同。有些厂商的早期启动文件是专有授权，不允许直接复制到闭源商业产品里再发布。

评测时要把所有第三方代码的来源和许可证声明记录下来，形成一张清单。这张清单在后续做产品合规审查、开源合规扫描时非常有用。可以说，静态评测做得好，等于给项目提前交了一份“软件物料清单”。

6. 评测报告的落地策略：升级还是冻结基线

6.1 量化风险，先说“能不能迁”

评测的最后，要产出一个明确的决策建议。我把结果分成三类：绿灯、黄灯、红灯。绿灯是代码健康，迁移成本可控；黄灯是部分问题，需要先做技术债清理；红灯是工程量太大，建议冻结在CMSIS‑4基线，不要强行折腾。

判断标准参考这几个关键数字：编译告警数是否超过200条、是否大量使用AC5专有扩展语法、启动文件和链接脚本是否被多次手工修改、RTOS和DSP依赖的版本是否老旧到无法兼容。如果四个指标中了三个，那我的建议是老老实实把老工程作为“维护基线”，新功能用新工程，不要拿生产线上的稳定性开玩笑。

6.2 不同工程类型的匹配建议

量产产品固件：如果产品稳定出货，没有新芯片需求，也没有新工具链硬性要求，静态评测做完后最适合的结论就是“冻结基线”。把评测报告存档，作为技术债务的已知清单。

正在迭代的产品：如果产品还有活跃迭代，建议分两步走：先做一轮静态评测修复已知风险，比如栈大小调整、启动文件整理、编译器告警清理；然后再规划CMSIS版本升级，从4.x起步，先升到4.5以上，再考虑跳5.x。

学习型项目和技术验证：这种项目最应该选择升级，因为学习价值高。用CMSIS 5代码和AC6/GCC新工具链去理解Cortex‑M工作机制，比守着老工程复制粘贴效率高得多。

新启动的项目：不要再碰CMSIS‑4了，直接用芯片厂商当前打包好的CMSIS‑5或CMSIS‑6版本。老库的“遗产”价值在于参考和审计，不在于让它继续承载新代码。

6.3 别忘了把评测结果沉淀为软件物料清单

我在实际项目中吃过一次亏：一个用CMSIS 4的老工程，产品线切换后新同事接手，完全找不到版本记录，连用的AC5编译器版本都是从网上下载的旧版安装包，折腾了好几天才把编译环境还原回去。

从那以后，每次做静态评测，我都会在工程根目录放一份RELEASE_NOTES.md，记录四样东西：CMSIS版本号、编译器版本号、启动文件哈希值、链接脚本提交记录。工程编译环境一旦能原样重建，后面所有迁移和排错都会简单很多。

做源码静态工程评测这件事，本质上就是给老代码做一次全身体检，然后把体检报告交给项目组，让“要不要开刀”变成一个有数据支撑的决策。CMSIS‑4这颗大树底下乘凉的人太多了，但真正愿意花时间搞清楚它根须怎么长的并不多。带着这套评测思路去整理一个老工程，你会发现自己对Cortex‑M体系结构的理解，会比写十年代码都要通透。