STM32F103编译报错core_cm3.c问题：原因分析与四种解决方案

1. 从一次真实的编译崩溃说起

第一次在Keil里编译STM32F103的工程，看到Build Output窗口刷出一大片红色报错，核心信息是core_cm3.c相关的错误，那种感觉我到现在还记得。明明工程是从别人那里拿来的，或者从官网下载的例程，怎么一到自己电脑上就编译不过了？更让人抓狂的是，有时候报错信息还不太一样，有的是error: #5: cannot open source input file "core_cm3.c"，有的是error: #20: identifier "__NVIC_PRIO_BITS" is undefined，还有的是undefined symbol __STREXW之类的链接错误。

这个问题在STM32F103X新手群体里出现的频率极高，几乎每个用Keil MDK开发STM32F103的人都会遇到至少一次。它不是什么高深的技术难题，但确实卡住了很多人。原因在于，core_cm3.c这个文件本身处于一个比较尴尬的位置——它属于CMSIS（Cortex Microcontroller Software Interface Standard）的一部分，是ARM公司提供的Cortex-M3内核访问层代码，但它又和具体的芯片型号、编译器版本、CMSIS版本紧密相关。一旦这些因素之间的匹配关系出了问题，编译就会报错。

这篇文章就是要把这个问题彻底讲清楚。我会从core_cm3.c到底是什么、为什么它会报错讲起，然后给出四种经过实测的解决方案，每种方案适用于不同的场景。最后还会分享一些我在实际项目中积累的避坑经验，以及如何获取最新版本的CMSIS文件。不管你是刚接触STM32F103的新手，还是已经用过一段时间但被这个问题反复困扰的开发者，应该都能从这里找到可操作的答案。

2. core_cm3.c到底是个什么文件

2.1 CMSIS的层级结构与core_cm3.c的定位

要理解为什么core_cm3.c会报错，首先得搞清楚它在整个软件栈里的位置。CMSIS是ARM公司制定的一套标准接口，目的是让不同厂商的Cortex-M芯片在软件层面有一致的访问方式。它大致分为几个层级：

• 内核访问层：直接操作Cortex-M内核的寄存器，比如NVIC（嵌套向量中断控制器）、SysTick、MPU等。这一层的代码就是core_cm3.c和core_cm3.h。
• 设备访问层：由芯片厂商提供，比如ST的stm32f10x.h，定义了具体芯片的外设寄存器映射。
• 外设驱动层：标准外设库或HAL库，比如stm32f10x_gpio.c、stm32f10x_usart.c等。

core_cm3.c的作用是实现内核访问层中那些不能用C语言直接完成的操作。比如__STREXW、__LDREXW这类独占访问指令，还有__WFI、__WFE等低功耗指令，它们需要内嵌汇编来实现。在早期的CMSIS版本中，这些函数的实现放在.c文件里；但在较新的版本中，ARM把这些函数改成了__STATIC_INLINE，直接放在core_cm3.h头文件里，core_cm3.c这个文件就被移除了。

这就是问题的根源之一：如果你的工程里还保留着旧版的core_cm3.c，但头文件已经换成了新版，或者反过来，就会出现函数重复定义或者找不到定义的错误。

2.2 为什么STM32F103X特别容易碰到这个问题

STM32F103X用的是Cortex-M3内核，这是ARM较早的内核版本。ST官方在推出标准外设库（Standard Peripheral Library）的时候，打包了当时版本的CMSIS文件。后来ARM更新了CMSIS标准，ST也推出了HAL库，但很多老教程、老例程、老工程模板仍然在使用标准外设库和旧版CMSIS。

新手往往是从网上找例程来学习，这些例程可能来自不同的时间点，用的CMSIS版本各不相同。有的例程里包含core_cm3.c，有的不包含；有的用的是CMSIS 1.x，有的是2.x，还有的是4.x甚至5.x。当你把这些文件混在一起用的时候，编译报错几乎是必然的。

另外，Keil MDK本身也在不断更新。不同版本的Keil MDK自带的ARM编译器版本不同，对CMSIS的支持程度也不同。比如Keil MDK 5.x默认使用ARM Compiler 5或6，而ARM Compiler 6对旧版CMSIS的兼容性就有一些变化。这些因素叠加在一起，就让core_cm3.c的报错变得非常常见。

2.3 常见的报错类型与对应原因

在实际操作中，core_cm3.c相关的报错主要有以下几种：

搞清楚这些报错背后的原因，解决起来就有方向了。下面我会逐一给出四种解决方案，你可以根据自己的实际情况选择最合适的一种。

3. 四种解决方案的完整操作路径

3.1 方案一：直接移除core_cm3.c并升级到新版CMSIS

这是我最推荐的方案，也是目前最符合CMSIS标准演进方向的做法。从CMSIS 4.0开始，ARM就把core_cm3.c中的内容全部移到了core_cm3.h中，以__STATIC_INLINE函数的形式提供。这意味着你根本不需要core_cm3.c这个文件。

具体操作步骤如下：

第一步，从工程中移除core_cm3.c。在Keil的Project窗口中，找到core_cm3.c文件，右键选择"Remove File from Group"。注意，这里只是从工程中移除引用，并不是删除磁盘上的文件。如果你确认不再需要它，也可以直接从工程目录中删掉。

第二步，确认core_cm3.h是新版本的。打开core_cm3.h，搜索__STATIC_INLINE关键字。如果能看到大量以__STATIC_INLINE开头的函数定义，比如__STATIC_INLINE uint32_t __LDREXW(uint32_t volatile *ptr)，说明这个头文件已经是新版的了。如果搜不到，说明你用的还是旧版头文件，需要从ARM官网或ST官网下载新版CMSIS。

第三步，检查stm32f10x.h中的宏定义。确保__NVIC_PRIO_BITS被正确定义为4（STM32F103的中断优先级位数是4）。这个宏通常在stm32f10x.h中通过#define __NVIC_PRIO_BITS 4来定义，或者在工程选项的C/C++预定义宏中添加。

第四步，重新编译。如果一切正常，编译应该能通过。如果还报__STREXW之类的链接错误，说明头文件中的内联函数没有被正确展开，需要检查编译器版本是否支持__STATIC_INLINE。

注意：移除core_cm3.c之后，如果工程中还有其他文件引用了它里面定义的函数，需要确保这些函数在新版core_cm3.h中都有对应的内联实现。通常情况下，标准外设库和HAL库都不会直接调用core_cm3.c中的函数，所以这个操作是安全的。

这个方案的优势在于一劳永逸，符合CMSIS的发展方向，以后升级CMSIS版本也不会再遇到这个问题。缺点是需要确认头文件版本，对于特别老的工程可能需要做一些额外的适配。

3.2 方案二：保留core_cm3.c但修正头文件包含关系

有些老工程因为各种原因不能移除core_cm3.c，比如工程中其他代码直接依赖了它里面的函数实现，或者你使用的编译器版本对__STATIC_INLINE的支持有问题。这种情况下，可以选择保留core_cm3.c，但需要修正头文件的包含关系。

核心思路是：让core_cm3.c和core_cm3.h的版本保持一致，并且确保core_cm3.h中不会重复定义core_cm3.c中已经实现的函数。

具体操作：

第一步，确认core_cm3.c和core_cm3.h来自同一个CMSIS版本。打开两个文件，查看文件头部的版本注释。通常会有类似@file core_cm3.c、@version V1.30这样的信息。确保两个文件的版本号一致。

第二步，在core_cm3.h中屏蔽重复的函数定义。如果core_cm3.h中使用了__STATIC_INLINE来定义函数，而core_cm3.c中又有这些函数的非内联实现，就会导致重复定义。解决方法是在core_cm3.h中找到这些函数，用条件编译把它们包起来，比如：

#ifndef __CORE_CM3_C_IMPLEMENTED __STATIC_INLINE uint32_t __LDREXW(uint32_t volatile *ptr) { return __LDREX(ptr); } #endif

然后在core_cm3.c的开头定义__CORE_CM3_C_IMPLEMENTED宏。

第三步，检查编译器优化选项。在Keil的Options for Target -> C/C++中，确保优化等级不是-O0。有些编译器在-O0下对内联函数的处理会有问题，适当提高优化等级（比如-O1）可以避免一些奇怪的链接错误。

第四步，清理并重新编译。在Keil中执行Project -> Clean Targets，然后重新Build。

这个方案适合那些不能大改工程结构的情况，但操作起来比方案一麻烦一些，而且需要你对CMSIS的代码结构有一定了解。

3.3 方案三：通过Keil的预定义宏解决标识符未定义错误

如果你的报错主要是identifier "__NVIC_PRIO_BITS" is undefined或者类似的标识符未定义错误，那么问题可能不在core_cm3.c本身，而在于编译时的宏定义没有正确传递。

__NVIC_PRIO_BITS这个宏定义了NVIC中断优先级的位数，STM32F103系列是4位。这个宏通常在stm32f10x.h中定义，但如果你的工程没有正确包含这个头文件，或者头文件中的条件编译没有走到定义这个宏的分支，就会报未定义错误。

解决方法有两种：

方法一：在stm32f10x.h中显式定义。打开stm32f10x.h，搜索__NVIC_PRIO_BITS，确认它被定义在正确的条件编译分支中。对于STM32F103，应该定义在#ifdef STM32F10X_MD之类的分支里。如果找不到，可以手动添加：

#define __NVIC_PRIO_BITS 4

方法二：在Keil的工程选项中添加预定义宏。打开Options for Target -> C/C++ -> Preprocessor Symbols，在Define框中添加__NVIC_PRIO_BITS=4。多个宏之间用逗号分隔。

另外，还需要确保STM32F10X_MD这个宏被定义了。STM32F103X属于中容量产品，需要定义STM32F10X_MD。这个宏决定了stm32f10x.h中包含哪些外设的寄存器定义。如果这个宏没定义，很多外设相关的标识符都会报未定义。

提示：在Keil中，预定义宏的优先级高于头文件中的定义。如果你在头文件和工程选项中都定义了同一个宏，编译器会使用工程选项中的值。所以如果你修改了头文件中的定义但没有生效，检查一下工程选项里是不是有冲突的定义。

这个方案主要解决的是标识符未定义类的错误，对于文件找不到或者重复定义类的错误效果有限。

3.4 方案四：替换为STM32CubeMX生成的最新工程框架

如果你已经尝试了上面几种方案但问题依然存在，或者你的工程本身就已经很老旧、维护成本很高，那么最彻底的解决方案是放弃旧工程，用STM32CubeMX重新生成一个基于HAL库的工程框架。

STM32CubeMX是ST官方推出的图形化配置工具，它可以根据你选择的芯片型号自动生成包含最新CMSIS文件的工程。生成的工程默认使用HAL库，CMSIS文件也是最新版本，不会出现core_cm3.c报错的问题。

操作流程：

第一步，安装STM32CubeMX。从ST官网下载安装包，安装过程中会自动下载对应的STM32F1系列固件包。

第二步，新建工程并选择芯片。打开STM32CubeMX，选择"New Project"，在芯片选择器中输入"STM32F103"，选择你实际使用的具体型号。

第三步，配置外设和时钟。根据你的项目需求配置GPIO、USART、TIM等外设，配置时钟树。对于新手来说，可以先只配置一个GPIO输出和一个USART，用来验证编译和下载流程。

第四步，生成工程。在Project Manager中设置工程名称、路径和工具链（选择MDK-ARM），然后点击"Generate Code"。STM32CubeMX会自动生成完整的工程文件，包括最新的CMSIS文件。

第五步，在Keil中打开并编译。生成的工程可以直接用Keil打开，编译应该一次通过。

这个方案的优点是彻底解决了CMSIS版本问题，而且HAL库的跨芯片移植性更好。缺点是需要重新配置外设，对于已经写了很多业务代码的工程来说迁移成本较高。但对于新手学习来说，用CubeMX生成工程是一个很好的起点。

4. 实操中容易踩的坑与排查思路

4.1 文件路径与Include Paths的隐藏问题

很多新手在解决core_cm3.c报错的时候，会把注意力全部放在文件本身，忽略了Keil的Include Paths配置。实际上，cannot open source input file这类错误，有相当一部分是因为头文件搜索路径没有配置完整。

Keil MDK中，头文件的搜索路径在Options for Target -> C/C++ -> Include Paths中设置。你需要确保以下路径都被包含：

• CMSIS核心头文件所在目录（包含core_cm3.h）
• 设备头文件所在目录（包含stm32f10x.h）
• 标准外设库或HAL库的头文件目录
• 用户自己的头文件目录

一个常见的坑是：路径中包含了中文或者空格。Keil对中文路径的支持不太好，有时候路径里有中文会导致找不到文件。建议工程路径全部使用英文和数字，不要有空格。

另一个坑是路径使用了相对路径但层级不对。比如..\..\Libraries\CMSIS\CM3\CoreSupport这样的路径，如果工程文件移动了位置，相对路径就会失效。建议在Include Paths中使用相对于工程文件（.uvprojx）的路径，并且在移动工程时一起移动依赖的库文件夹。

4.2 编译器版本与CMSIS版本的兼容性矩阵

Keil MDK的不同版本自带不同的ARM编译器，而不同版本的CMSIS对编译器有不同的要求。下面这个表格是我在实际使用中总结的兼容性参考：

如果你使用的是ARM Compiler 6（AC6），它对旧版CMSIS中的一些内嵌汇编语法支持有变化。比如旧版core_cm3.c中使用的__ASM关键字在AC6中需要改为__asm，或者使用__STATIC_INLINE配合__attribute__((always_inline))。这也是为什么我推荐直接移除core_cm3.c、使用新版头文件的原因——新版CMSIS已经处理好了这些兼容性问题。

4.3 从报错信息快速定位问题根源

面对一堆报错信息，新手容易慌，不知道从哪里看起。我的经验是：只看第一条报错。编译器报错往往有连锁反应，第一条报错解决了，后面的很多报错会自动消失。

如果第一条报错是cannot open source input file，优先检查文件是否存在、路径是否正确。如果第一条是identifier xxx is undefined，优先检查宏定义和头文件包含。如果第一条是multiple definition，优先检查是否有重复的文件被加入工程。

另外，Keil的Build Output窗口中，双击报错信息可以跳转到对应的代码行。但有时候报错指向的是头文件中的某一行，而真正的问题在调用这个头文件的源文件里。这种情况下，需要沿着包含关系往上找。

还有一个技巧：在Build Output中搜索"error"，把所有错误信息复制出来，按文件分组。同一个文件中的多个错误往往有共同的根源。比如core_cm3.c中报了很多identifier undefined，那大概率是缺少某个头文件或者宏定义，而不是每个标识符都真的有问题。

5. 最新CMSIS文件的获取与版本选择

5.1 从哪里获取可靠的CMSIS文件

获取CMSIS文件有几个正规渠道：

渠道一：ARM官方GitHub仓库。ARM在GitHub上维护了CMSIS的官方仓库，地址是https://github.com/ARM-software/CMSIS_5。这里可以下载到最新版本的CMSIS，包括核心头文件、DSP库、RTOS等。对于STM32F103来说，你主要需要的是CMSIS/Core/Include目录下的文件。

渠道二：ST官方固件包。ST为STM32F1系列提供了标准外设库和HAL库的固件包。标准外设库的最后一个版本是V3.5.0，里面包含了当时版本的CMSIS。HAL库的固件包（STM32CubeF1）则包含了更新的CMSIS版本。可以从ST官网的对应产品页面下载。

渠道三：Keil MDK的Pack Installer。Keil MDK自带了Pack Installer，可以安装ST提供的Device Family Pack（DFP）。DFP中包含了CMSIS文件和设备头文件。在Keil中点击Pack Installer图标，搜索STM32F1，安装对应的DFP即可。

渠道四：STM32CubeMX自动下载。安装STM32CubeMX后，它会在首次使用时自动下载对应的固件包，其中就包含最新的CMSIS文件。

注意：从非官方渠道下载的CMSIS文件可能存在版本混乱或者被修改过的情况。建议优先使用ARM官方仓库或ST官方固件包中的文件。如果从第三方例程中获取CMSIS文件，一定要核对版本号。

5.2 如何判断CMSIS文件的版本

CMSIS文件的版本信息通常写在文件头部的注释中。以core_cm3.h为例，打开文件后可以看到类似这样的注释：

/* CMSIS Cortex-M3 Core Peripheral Access Layer Header File * @version V4.30 * @date 20. October 2015 */

版本号V4.30就表示这是CMSIS 4.30版本。不同版本之间的主要差异在于：

• CMSIS 1.x-3.x：core_cm3.c存在，函数实现放在.c文件中。
• CMSIS 4.x：core_cm3.c被移除，函数改为__STATIC_INLINE放在.h文件中。
• CMSIS 5.x：进一步优化了编译器兼容性，增加了对ARM Compiler 6的支持。

对于STM32F103X来说，CMSIS 4.30或5.x都是可以用的。关键是保持工程中所有CMSIS文件版本一致，不要混用。

5.3 替换CMSIS文件时的注意事项

替换CMSIS文件不是简单地覆盖就完事了，有几个细节需要注意：

第一，备份原文件。在替换之前，把工程中现有的CMSIS文件夹整个备份一份。万一新版本有问题，可以快速回退。

第二，检查设备头文件的兼容性。stm32f10x.h是ST提供的设备头文件，它依赖于CMSIS的core_cm3.h。如果你只替换了CMSIS文件但没有更新stm32f10x.h，可能会出现宏定义不匹配的问题。建议同时更新ST的固件包。

第三，清理Keil的编译缓存。替换文件后，执行Project -> Clean Targets，然后重新Build。Keil有时候会缓存旧的编译结果，不清理的话可能还是报旧错误。

第四，检查工程中的文件引用。如果新版本CMSIS中不再包含core_cm3.c，需要从工程中移除对这个文件的引用。否则会报cannot open source input file。

第五，验证编译结果。替换完成后，不仅要看编译是否通过，还要检查生成的hex文件大小是否正常。有时候编译通过了但链接出了问题，生成的hex文件可能不完整。

6. 几个真实案例的排查过程还原

6.1 案例一：从GitHub下载的例程编译报错

有个朋友从GitHub上下载了一个STM32F103的例程，用Keil打开后编译，报错cannot open source input file "core_cm3.c"。他检查了工程目录，发现确实没有core_cm3.c这个文件，但工程文件（.uvprojx）中却引用了它。

排查过程：打开.uvprojx文件（可以用文本编辑器打开），搜索core_cm3.c，找到对应的<File>标签，把它删除。或者在Keil中直接右键移除。然后重新编译，又报了identifier "__NVIC_PRIO_BITS" is undefined。

继续排查：打开stm32f10x.h，发现这个头文件是旧版的，里面没有定义__NVIC_PRIO_BITS。在Keil的工程选项中添加预定义宏__NVIC_PRIO_BITS=4和STM32F10X_MD，重新编译通过。

这个案例的教训是：从网上下载的例程往往不完整，可能缺少文件或者配置文件不对。拿到例程后，先检查工程结构是否完整，再检查宏定义和头文件路径。

6.2 案例二：Keil升级后旧工程突然编译不过

另一个常见场景是：原本编译正常的工程，在升级Keil MDK版本后突然报错。这是因为新版本的Keil可能默认使用了不同版本的ARM编译器，而旧工程中的CMSIS文件不兼容新编译器。

排查过程：查看Keil的Options for Target -> Target选项卡，确认ARM Compiler版本。如果从AC5升级到了AC6，需要检查CMSIS文件是否支持AC6。如果不支持，要么降级编译器，要么升级CMSIS文件。

解决方案：把工程中的CMSIS文件升级到5.x版本，同时移除core_cm3.c。如果工程中使用了标准外设库，还需要确认标准外设库是否兼容新版CMSIS。ST的标准外设库V3.5.0是可以和CMSIS 5.x配合使用的，但需要做一些小的适配。

6.3 案例三：多文件混用导致的重复定义

有个读者反映，他的工程编译时报multiple definition of __LDREXW。他检查了工程，发现core_cm3.c和core_cm3.h都在工程中，而且头文件里也有__LDREXW的定义。

排查过程：打开core_cm3.h，搜索__LDREXW，发现它被定义为一个__STATIC_INLINE函数。再打开core_cm3.c，发现里面也有一个非内联的__LDREXW函数实现。两个文件都被编译，链接时就报了重复定义。

解决方案：按照方案一，从工程中移除core_cm3.c，只保留core_cm3.h。重新编译后问题解决。

这个案例说明了一个重要原则：CMSIS的.c文件和.h文件不要同时使用。要么用旧版（.c + .h），要么用新版（只有.h），不要混搭。

7. 给新手的长期避坑建议

7.1 建立自己的工程模板

与其每次新建工程都从零开始配置，不如花点时间建立一个自己的工程模板。模板中包含：

• 正确配置的CMSIS文件（推荐CMSIS 5.x，不含core_cm3.c）
• 标准外设库或HAL库的完整文件
• 配置好的Keil工程选项（Include Paths、预定义宏、调试器设置等）
• 一个简单的main.c，包含基本的时钟配置和GPIO初始化

以后新建工程时，直接复制模板文件夹，改个名字就能用。这样可以避免每次都在CMSIS配置上浪费时间。

7.2 版本管理的重要性

对于STM32开发来说，版本管理不仅仅是代码的版本管理，还包括：

• CMSIS版本
• 标准外设库/HAL库版本
• Keil MDK版本
• ARM编译器版本

建议在工程目录下放一个README.md或者version.txt，记录这些版本信息。当工程需要迁移到另一台电脑或者分享给别人的时候，这些信息可以帮助快速定位环境问题。

7.3 遇到报错时的排查顺序

根据我的经验，遇到core_cm3.c相关报错时，按照以下顺序排查效率最高：

1. 看第一条报错信息，确定是文件找不到、标识符未定义还是重复定义。
2. 检查工程中是否同时存在core_cm3.c和core_cm3.h，如果是，优先移除.c文件。
3. 检查Include Paths，确保CMSIS头文件目录、设备头文件目录都在搜索路径中。
4. 检查预定义宏，确保STM32F10X_MD和__NVIC_PRIO_BITS被定义。
5. 检查CMSIS版本一致性，确保所有CMSIS文件来自同一个版本。
6. 检查编译器版本，确认CMSIS文件支持当前使用的ARM编译器。
7. 清理并重新编译，排除编译缓存的影响。

这个顺序是从最常见、最容易解决的问题开始，逐步深入到更复杂的版本兼容性问题。大部分情况下，前两步就能解决问题。

7.4 关于core_cm3.c的最终建议

如果你现在正在用STM32F103X做开发，我的建议很明确：不要使用core_cm3.c。直接使用CMSIS 4.30或更高版本的头文件，把内核访问层的函数交给core_cm3.h中的内联函数来处理。这样不仅避免了编译报错，还能让代码更简洁、更符合CMSIS标准。

如果你维护的是一个老工程，暂时不能大改，那就按照方案二或方案三做最小化修改，先让工程能编译通过。然后在后续的维护中逐步升级到新版CMSIS。

STM32F103X是一颗非常经典的芯片，虽然推出已经很多年了，但它的生态非常成熟，资料丰富，作为学习Cortex-M3开发的入门平台非常合适。core_cm3.c的报错只是学习路上的一个小坎，跨过去之后，你会发现后面的路会顺畅很多。