1. 写在前面的几句大实话：STM32CubeMX到底帮你做了什么
做嵌入式这几年，我从寄存器开发一路折腾到标准库，再切换到HAL库，中间最让人头疼的其实不是写业务逻辑，而是每次新建一个工程都要重复做一堆初始化：时钟树怎么配、GPIO模式怎么选、外设中断往哪挂、各模块的初始化顺序是什么。这些活儿本身不难，但繁琐、容易漏，而且不同芯片之间差异很大，靠手写迟早出问题。
STM32CubeMX这个工具，本质上是把这个“初始化工程”环节从体力活变成了配置活。你在图形界面上选芯片型号、勾外设、点几下鼠标，它就能生成一份完整的初始化代码，底层是基于ST官方的HAL库。你拿到手的不是空壳工程，而是一个已经做好了时钟、引脚、外设初始化，并且能在MDK-ARM、IAR、STM32CubeIDE或者CMake/Makefile工程里直接编译运行的起点。
这篇文章想写的，不是CubeMX里每个按钮的功能说明书，而是我从零开始用CubeMX初始化一个STM32工程时，真正会遇到的坑、需要注意的配置项、以及不同使用场景下怎么选方案。主要面向刚开始接触CubeMX的朋友，也适合已经在用但想搞明白“为什么这么配”的开发者。看完之后，你应该能独立完成一个STM32CubeMX初始化工程，从装软件到跑起一个能点灯、能进RTOS、能驱动外设的基础工程。
2. 一上来就卡住的环节：安装、固件包下载与汉化
2.1 安装版本选择与Java环境
STM32CubeMX的安装本身不算复杂，官方下载页面提供了各个平台的安装包。但有几个细节我建议你提前搞清楚，免得装到一半进退两难。
先说Java。新版CubeMX已经内置了JRE，安装过程基本是一条龙，不需要你再单独装Java环境。但如果你用的是比较老的版本，或者安装之后启动报错提示找不到Java，那就需要手动装一个JRE。这里我直接给结论：去官网下载Java 17（对应新版CubeMX）或者Java 8（对应老版本），装好之后配置好JAVA_HOME环境变量，一般就能解决。
安装路径这里有一个容易被忽略的点：CubeMX默认会把安装目录放在C盘，但固件库（Firmware Package）默认下载路径是在用户目录下的STM32Cube文件夹里。如果你C盘空间紧张，建议安装的时候就把固件库的存储路径改到一个独立分区，比如D:\STM32CubeRepository。后面下载多个芯片系列的固件包时，这个文件夹体积会非常可观，动不动几个GB，放系统盘容易引发磁盘告急。
2.2 固件包下载慢、失败的处理思路
装好CubeMX之后，第一次新建工程就会提示下载对应芯片系列的固件包，比如STM32F4系列、STM32F1系列、STM32H7系列。这个下载环节，我相信大多数人都经历过“转圈圈”的痛苦。
固件包下载慢或者失败，原因一般有两个：一是网络连接不稳定，二是下载源在国外，访问速度确实不太给力。处理思路我有几条经验：
- 下载失败时，不要无限重试同一个操作。去Help -> Manage embedded software packages里查看已安装的固件包状态，把失败的包删掉重新下载。
- 如果网络实在不行，换一个时段再试，或者用代理之类的常规网络手段，这里不展开。
- 固件包下载完成后，CubeMX会缓存到本地路径。以后离线状态下也可以使用，前提是你提前下好了包。
我个人的习惯是：换一台网络稳定的机器，把所有常用系列的固件包一次性下载好，然后把整个STM32CubeRepository文件夹拷贝到工作电脑上，在CubeMX的固件包管理界面里设置好本地路径就可以直接使用，同样能新建工程，速度还快得多。
2.3 汉化有没有必要，怎么汉化
“STM32CubeMX中文汉化”确实是个热搜词，说明不少人看英文界面别扭。我想说的实话是：CubeMX的界面英文词汇量很有限，常用的就那几个，数量级和复杂度比阅读芯片手册小得多。配置项里真正会用到的英文，比如Pinout、Clock Configuration、Project Manager、Generate Code，翻来覆去就是那一套。
汉化这件事在技术上是可以做的，网上也能找到语言包或汉化补丁。但我不太推荐在项目开发阶段使用汉化补丁，原因是：CubeMX版本更新频繁，菜单和配置项会调整，汉化包不一定及时跟进，有时候汉化之后反而找不到某个功能放在哪里了。更何况，生成出来的代码注释、HAL库API，全都是英文的，这部分没法汉化，最终你还是要回到英文语境。
我的建议是：界面保持英文，把常用配置流程跑熟，那些英文词汇自然而然就记住了。这也是我为什么在这篇文章里重点讲“为什么这样配”，而不是逐个菜单翻译。
3. 新建工程前必须做对的三件事：选型、时钟与调试口
3.1 选择芯片型号还是开发板
打开CubeMX，第一个界面就是芯片选型。这里有两条路：一条是按板卡选择（Board Selector），另一条是按芯片型号选择（MCU Selector）。
如果你是直接用开发板学习，比如正点原子、野火的板子，Board Selector可以快速找到匹配的板卡模板，CubeMX会帮你把板载外设的引脚分配和初始化配置都预设好，省去大量手动配引脚的功夫。但要注意，开发板模板里的配置只覆盖板载资源，比如板载LED、按键、调试器、外部Flash等，如果你要外接模块，还是需要自己调整。
如果是做实际项目，或者手里只有一颗裸芯片/自研板卡，MCU Selector是更常用的一条路。选型时可以按系列过滤，也可以直接搜索型号关键字。核心指标无非是Flash大小、RAM大小、主频、封装引脚数、外设资源，这些信息在选型界面的列表里都有，选完之后右侧图表还会给出大概的资源利用率提示，对选型很有参考价值。
3.2 时钟树配置：外部晶振、PLL和主频
新建工程之后，第一个要面对的大头就是System Core -> RCC，也就是时钟树配置。很多新手在这块翻车，因为时钟树的可视化界面看起来密密麻麻，但实际上核心就几件事。
首先是时钟源。如果板子上有外部高速晶振（HSE），就在RCC配置里把HSE设为Crystal/Ceramic Resonator；如果有外部低速晶振（LSE，用于RTC等），也需要在这里一起开启。如果你的系统对时序要求不高，不想用外部晶振，也可以直接用内部高速时钟（HSI），但精度会差一些，串口通信、USB这类对时钟精度有要求的外设容易出问题。我的建议是：能用外部晶振就用外部晶振，省心。
其次是主频。STM32每个系列都有最大主频限制，比如F103最高72MHz、F407最高168MHz、H743最高480MHz。时钟树界面上，PLL的倍频分频系数会直接影响最终的系统时钟。CubeMX的强大之处在于，你只需要在HCLK那一栏输入目标频率（比如168MHz），它会自动帮你计算PLL配置，并且用红色提示当前的配置是否超限。
这里有一个特别重要的细节：时钟源选完之后，一定要先配置调试接口，再动时钟树。原因我在下一小节解释。
3.3 调试接口配置：避免一次下载后就锁死
这是一个我亲眼见过很多次的事故：新建工程，选好芯片，时间紧任务重，直接生成代码，烧录进去，然后第二次再烧就提示“No target connected”或者“Cannot access target”，开发板变砖了。
原因很简单：芯片的调试接口（SWD/JTAG）默认是复用为GPIO的，在你配置GPIO时如果不小心把SWDIO（PA13）、SWCLK（PA14）这两个引脚配成了普通GPIO，程序一旦跑起来，调试器就再也连不上芯片了。
所以在设计任何STM32工程时，第一步就应该在System Core -> SYS下把Debug模式配置好。常用的是Serial Wire（也就是SWD），在板级调试时用这个接口就够了，只占两根引脚，加上地线和复位线，总共四根。JTAG虽然也能用，但占用引脚多，一般项目不值得。
调试接口的配置顺序看起来很基础，但重要性怎么强调都不过分。这属于那种“踩过一次就永远记得”的坑，我不希望你也踩一次。
4. 引脚分配与常用外设初始化配置
4.1 引脚分配的基本操作
时钟配置完成之后，界面的右侧会出现芯片的引脚图，这就是CubeMX的交互核心之一。你可以直接在引脚图上点击引脚进行功能配置，也可以通过左侧的外设列表（Categories）逐项展开，点击某个外设进入配置模式，由CubeMX自动分配或手动指定引脚。
如果是手动指定引脚，按住Ctrl再点击引脚图上可用引脚，就能把某个功能映射上去。CubeMX会用不同颜色标识当前引脚的功能状态，绿色代表可以分配，灰色代表已被占用，黄色是电源/地等固定功能引脚，红色表示引脚冲突。如果出现红色冲突，多半是该引脚已经被另一个外设占用，需要调整分配方案。
尽量先在左侧外设列表里配置好功能模式，再在引脚图上确认物理引脚分配，这样不容易遗漏。一个功能配好之后，CubeMX会自动检查冲突，比你在纸质原理图上一个一个对引脚效率高很多。
4.2 按键、LED这类GPIO怎么配
初始化工程里最基础也最常用的就是GPIO控制，LED点灯和按键扫描是逃不掉的两件事。
GPIO输出模式，比如LED，在配置界面里需要确定几个参数：
- 引脚电平初始状态：LED阳极接GPIO、阴极接地，就默认输出低电平，上电不亮；如果是阴极接GPIO（灌电流方式），就默认高电平，上电不亮。这个要看你板子实际电路，配反了就是上电灯直接亮，或者闪烁逻辑反相。
- GPIO模式：推挽输出（Push-Pull）还是开漏输出（Open-Drain）。点亮LED一般用推挽输出，驱动能力强；开漏输出需要外接上拉电阻，用得少。
- 输出速度：LED这种低速信号选Low就足够了。高速去拉高反而容易引入噪声和EMI，没必要。
- 上下拉：输出模式一般选No pull。如果外部电路有上拉或下拉，GPIO内部上下拉反而会造成电流损耗或电平稳不住。
按键输入模式，参数更多一些：
- 输入模式：GPIO Input Mode，选浮空输入还是上拉/下拉输入。最常见的是按键一端接GND、另一端接GPIO，这种电路就选上拉输入，按下时读到低电平。另一端接VCC的，就选下拉输入，按下时读到高电平。
- 触发方式：如果需要中断，选择External Interrupt Mode with Rising/Falling edge trigger。按下接地，就用下降沿触发；按下接VCC，就用上升沿触发。
- 用户标签（User Label）：建议在每一步配置命名时，给引脚起一个好识别的名字，比如LED_RED、KEY_BOOT。这样生成的代码里，GPIO的宏定义会直接带这些命名，阅读和修改代码都会非常轻松。CubeMX会在生成的头文件里自动把这些命名转化为宏，例如在main.h里生成LED_RED_Pin、LED_RED_GPIO_Port等。
4.3 I2C OLED初始化配置的经验
搜热词里出现了“STM32CubeMX i2c oled”，这块也值得专门拿出来说一下，因为OLED屏算是初始化工程里很常见的验证外设。
在CubeMX里启用I2C（比如I2C1），通常只需要设置I2C速度和地址长度。OLED屏大多是I2C接口，地址一般是0x3C或0x3D，具体看模块的地址引脚电平。这里容易出问题的反而是引脚分配和速度：
- I2C引脚在CubeMX中会自动分配，一般I2C1的SCL是PB6、SDA是PB7（F103、F4系列），不同芯片有区别。如果你自己的板子引脚不同，需要手动改。
- I2C速度选择100KHz（Standard Mode）还是400KHz（Fast Mode），OLED驱动IC通常支持400KHz，但如果线比较长或者模块稳定性一般，降到100KHz反而整体更可靠。
- 在代码层面，CubeMX生成的I2C初始化是HAL_I2C_Init函数，它只做I2C外设的配置，并不会自动检测总线上是否有设备。如果通信失败，优先查接线和地址，不要盲改代码。
OLED显示部分通常需要移植第三方驱动库（比如U8g2或者SSD1306驱动），这部分不属于CubeMX初始化工程的核心，但可以在工程里预留好I2C句柄，后续驱动库调用HAL_I2C_Mem_Write即可完成数据写入。
5. 代码生成：从CubeMX到Keil/VSCode，工程文件到底怎么流转
5.1 Project Manager设置决定生成结果
很多人生成代码时会发现，明明点了Generate Code，但文件结构和预期不一样，或者生成完直接编译报错，这时候问题多半出现在Project Manager设置上。
Project Manager界面主要分几个区域：
- Project Name和Location：工程名和路径，路径不要带中文和空格，否则MDK和GCC工具链都会出各种莫名奇妙的问题。
- Toolchain / IDE：这是最关键的下拉框。选择MDK-ARM V5/V6生成的是Keil工程；选择STM32CubeIDE生成的是IDE工程；选择Makefile或CMake则可以配合VSCode等工具链使用。
- Generate Under Root：勾选后代码都生成在根目录下，不额外创建子文件夹。
- Generate peripheral initialization as a pair of '.c/.h' files per peripheral：这个选项强烈建议勾选。默认情况下，CubeMX会把所有外设初始化代码堆在main.c里，越加越臃肿；勾选之后，每个外设会有独立的.c/.h文件，比如i2c.c/i2c.h、usart.c/usart.h，后续维护体验完全是两回事。
还有一个容易踩的坑：在旧版本CubeMX中，如果选择MDK-ARM V5版本，生成的Keil工程是一个.uvprojx文件；V6版本生成的扩展名可能不同。MDK选择V5还是V6，取决于你本地Keil装了哪个编译器版本。如果工具链版本不匹配，打开工程后可能提示找不到编译器。解决办法是：在Keil的Project -> Manage -> Project Items里切换或者安装对应的ARM Compiler。
5.2 Keil工程生成与启动文件
当选择MDK-ARM生成后，CubeMX会在工程目录下创建MDK-ARM子文件夹，里面是Keil工程文件和启动文件等。启动文件（startup_stm32xxxxx.s）是由CubeMX从固件包里拷贝过来的，这个文件负责设置初始栈指针、中断向量表、调用SystemInit和main，是整个工程跑起来的入口。
这里要提醒一个点：因为CubeMX生成的代码是HAL库风格的，所以Keil工程里编译选项的宏定义会包含USE_HAL_DRIVER和STM32F4xx（对应具体系列）这样的语句。如果编译时出现HAL库函数找不到定义，先检查C/C++选项卡下的Define里有没有这两个宏。
Keil里编译时还有一个常见现象：首次编译较慢，因为要编译整个HAL库的源文件。CubeMX生成的工程会把所有用到的HAL源文件都加入工程，但实际上很多文件用不到，可以通过右侧的Manage Project Items删减。不过这个操作有一定风险，如果你不确定删了之后是否还需要，就先不要动，等编译通过、功能验证稳定后，再考虑裁剪。
5.3 多外设独立c/h文件的使用习惯
前面说到建议勾选“peripheral initialization as a pair of '.c/.h' files per peripheral”，这里展开说说原因。
默认不勾选时，整个初始化代码全在main.c里，结构大概是：
int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_I2C1_Init(); MX_USART1_Init(); while(1) { // ... } }看起来倒也简洁，但后续外设多了，main.c能到一千多行，其中大部分还是初始化代码。你真正关心的业务逻辑，反而淹没在一堆重复的模式配置里。
勾选每外设独立文件后，main.c里只保留主流程，外设调用的函数声明在各自头文件里，阅读和修改都更清晰。比如要调I2C，直接看i2c.h里有什么函数即可，不需要翻遍main.c去找句柄定义。这个习惯一旦养成，你在做复杂项目时会轻松很多，因为这本质上是一种简单的模块化思想。
6. 推荐在VSCode里初始化并编译STM32工程
6.1 CubeMX生成CMake或Makefile工程
近几年用VSCode做嵌入式开发的人越来越多，原因无非是VSCode编辑体验好、插件生态强、跨平台一致性好。“STM32CubeMX vscode”这个热搜词说明大家确实在寻找一条成熟的“CubeMX生成 + VSCode编译调试”的路径。这里我给出一种足够主流的做法。
在CubeMX的Project Manager里，Toolchain / IDE选择CMake或Makefile，先让CubeMX帮你把工程骨架生成出来。选择CMake时，CubeMX会生成CMakeLists.txt、cmake文件夹（包含工具链配置）、以及全套源码文件；选择Makefile时，会生成一个Makefile文件，里面定义了源码文件列表、头文件路径、链接脚本等。
两种方式我都有用过，个人更偏向CMake。理由很简单：CMake对IDE和编译器的抽象程度更高，后期如果要从命令行编译切换到CLion、QT Creator或者VSCode的CMake插件，都不需要改工程结构。Makefile则更轻量，适合快速验证和习惯GNU Make的老手。
6.2 VSCode环境配置
有了CubeMX生成的工程文件之后，VSCode这边需要准备的是：
- 安装C/C++扩展（微软官方）和Cortex-Debug扩展。前者负责智能提示和代码跳转，后者负责调试器对接。
- 安装编译工具链。Windows环境下，推荐安装arm-none-eabi-gcc工具链。装好之后把bin目录加入系统PATH环境变量。
- 如果需要用CMake，再安装CMake Tools扩展，以及CMake本身（或者在VSCode里直接集成CMake工具）。
接下来打开工程根目录，CMake Tools扩展会自动识别CMakeLists.txt。首次加载时，选择工具链套件，指定为arm-none-eabi-gcc。如果一切顺利，底部状态栏会出现Build按钮，点击即可编译。
编译生成的.elf、.bin文件会输出到build目录下。烧录方面，可以用ST-Link搭配OpenOCD，或者直接用STM32CubeProgrammer的命令行模式。Cortex-Debug插件配合ST-Link，在VSCode里配置launch.json，点击F5就能直接烧录并进入调试。
6.3 VSCode编译与排错
VSCode这条链路确实灵活，但代价是门槛比Keil高。你至少需要理解三件事：交叉编译工具链是什么、CMake如何组织源文件、调试器如何连接目标。
常见报错类型和解决方案我列一下：
- “arm-none-eabi-gcc: not found”：工具链没装好或者没加PATH。
- “CMake Error: CMAKE_C_COMPILER not set”：没有正确选择工具链套件，需要在CMake Tools里指定编译器路径。
- “undefined reference to xxx”：多半是链接脚本（.ld）文件路径或内存大小设置不对，去检查CubeMX生成的链接脚本是否被CMake正确包含。
- “No ST-LINK detected”：检查ST-Link驱动，以及CubeMX里SYS配置是否正确选择Serial Wire调试口。
说实话，如果你只是点个灯、调个串口，用Keil可能更省事。但如果你做的是一个长期维护的中大型项目，代码提示、Git集成、多窗口编辑这些能力，VSCode带来的效率提升是实实在在的。而且CubeMX只是负责初始化，真正写业务逻辑时，你还是希望有一个顺手编辑器。
7. 初始化阶段的进阶场景：RTOS与LAN8720A
7.1 在CubeMX中启用FreeRTOS
写到这里，初始化工程已经不只是“点灯”级别了。很多项目会用到实时操作系统，而在CubeMX里集成FreeRTOS是天然的优势，因为不需要你手动移植，选个选项就能生成可运行的RTOS工程。
在中左侧Categories里找到Middleware and Software Packs，点击FreeRTOS，在Mode里选择CMSIS_V2（较新的封装接口）。CMSIS_V2是ARM官方对RTOS接口的标准化封装，CubeMX生成的代码会使用osKernelInitialize、osThreadNew这类API，而不是直接暴露FreeRTOS原生API。这样以后换RTOS内核，业务代码可以少改很多。
启用FreeRTOS之后，CubeMX会为每个任务分配一个栈大小（Stack Size），单位是字（word），不是字节。默认栈大小2048指的就是2048个字，也就是8KB。这个数值不要盲目调大，因为SRAM有限；但也不能开太小，否则任务里调printf或者复杂浮点运算很容易爆栈，表现为程序跑飞、HardFault或者行为诡异。
7.2 用一个RTOS任务点亮LED
初始化工程里最常见的一个验证动作，就是创建两个任务，一个让LED闪烁，另一个做一些周期性操作。CubeMX里可以直接在Tasks and Queues面板中新建任务，比如：
- defaultTask：默认任务，优先级osPriorityNormal，栈大小128（word级别，实际上128字=512字节，如果打印信息就会爆，建议给大点）。
- ledTask：专门控制LED，优先级osPriorityLow，栈大小128。
生成代码后，在main.c里会看到两个任务的入口函数，比如StartDefaultTask和StartLedTask。往里填业务代码即可：
void StartLedTask(void *argument) { for(;;) { HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET); osDelay(500); HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET); osDelay(500); } }这里面有一个很容易犯的错误：FreeRTOS任务函数里不能直接调用HAL_Delay这种阻塞延时（除非时基配置得当），否则会阻塞整个调度器。正确做法是用osDelay（内部调用vTaskDelay），让出CPU给其他任务执行。
RTOS的时基配置也要注意。CubeMX生成工程后，在FreeRTOS的Config Parameters里有一个TICK_RATE_HZ，默认1000，也就是一个系统节拍1ms。osDelay(500)就是延时500个节拍，实际延时约500ms。这个理解清楚了，任务延时就不容易糊涂。
7.3 引入LAN8720A：基本初始化和注意事项
热搜词里有个“stm32cubemx rtos+lan8720a”，我猜测是有人想用RTOS+以太网，做网络通信相关项目。LAN8720A是一颗很常用的以太网PHY芯片，与STM32的MAC（Ethernet外设）搭配，可以用RMII接口连接。
在CubeMX里启用Ethernet外设一般做这几件事：
- 选择ETH外设，Mode选择RMII，这样需要的引脚更少，一般只需要7根信号线（TX_EN、TXD0、TXD1、RXD0、RXD1、REF_CLK、MDIO/MDC可选）。
- 在Ethernet Configuration里配置PHY Address（一般由LAN8720A的PHYAD0引脚外部电平决定，很多模块默认地址是0）。
- 关闭/调整几个关键选项：比如PHY Clock选择。RMII接口需要50MHz的REF_CLK，可以由外部晶振提供，也可以由STM32的MCO引脚输出。如果用MCO输出，需要在RCC时钟树里把MCO1配为50MHz，这个配置顺序比较讲究。
- 当你启用ETH和FreeRTOS后，如果需要使用lwIP协议栈，可以在Middleware里把lwIP也打开，然后在RTOS模式下生成网络任务。这套组件全部由CubeMX生成，确实省掉了很多手工移植的功夫。
LAN8720A初始化后的一个常见问题是“link up但ping不通”，这个时候优先查PHY寄存器状态，确认是否完成了自动协商。HAL库的HAL_ETH_ReadPHYRegister和HAL_ETH_WritePHYRegister可以直接用来排查。还有一个细节：PHY芯片的复位引脚（NRST）往往由MCU的一个GPIO控制，需要在初始化中先拉低再拉高完成硬件复位，再延迟几百毫秒等待PHY稳定。这个时序如果不对，PHY可能一直在异常状态。
说实话，以太网项目的初始化涉及的东西不少，一篇博文很难覆盖完全。但CubeMX把最难的部分——ETH外设寄存器配置和lwIP的移植集成——自动化了，你已经从“一行一行配寄存器”里解放出来，剩下的主要是理解网络栈的流程和排查链路问题。
8. 一次典型的初始化工程报错排查：编译后没有arm文件夹
8.1 问题现象
搜热词里出现了“stm32cubemx 编译后无 arm 文件夹”，这个具体问题我印象很深。有段时间，不少人在用CubeMX生成Keil工程后，打开工程点击编译，命令窗口一闪而过，然后发现工程目录下没有生成arm文件夹里的那些中间产物（比如STARTUP、LISTING、OBJECT等子目录），自然也没有可下载的hex/bin文件。
这个现象在CubeMX新版本配合Keil MDK v5时尤其常见。很多人一开始会怀疑是CubeMX生成工程不完整，反复重新生成，问题依旧。实际原因往往是在Keil的Output选项中，中间文件的生成路径被设置成了空或非法的路径。
8.2 排查思路
排查分三步走：
第一，先确认CubeMX生成的工程本身没有缺胳膊少腿。打开工程目录，检查MDK-ARM文件夹下是否有.uvprojx文件、startup汇编文件、链接脚本等，如果没有，说明CubeMX生成阶段就有问题，考虑重新生成或者更换Toolchain版本。
第二，打开Keil工程，在Options for Target -> Output选项卡里，检查Select Folder for Objects选项。CubeMX生成的工程，输出路径一般默认为.\objects（即当前工程目录下的objects文件夹）。如果你看到“No output directory”之类的提示，或者是CubeMX路径覆盖后变成了空字符串，就是问题根源。把这个路径改为.\objects或者.\build\objects，重新编译即可。
第三，检查Listing选项卡的类似设置。Listing是列表文件路径，不影响烧录文件生成，但放一起确认总没错。
另外还有一种特殊情况：Keil工程编译后，输出目录生成了，但默认不生成Hex文件。如果需要下载到单片机，需要在Output选项卡中勾选Create HEX File，否则只有axf文件，部分下载器无法直接识别。
8.3 最终原因和解决办法
我那次帮朋友排查，最后发现CubeMX生成的.uvprojx文件里的输出路径被写成了绝对路径，指向的是他另一台电脑上的目录。这是因为他在CubeMX的Project Manager设置里，曾经手动改过一次输出目录，CubeMX就把这个路径记忆在了工程配置里。多人协作时，一个人改了路径，工程拷到别的机器上就会出问题。
解决办法很简单：把Options for Target里的Output路径和Listing路径全部改为相对路径，比如.\objects和.\listings，然后重新编译，arm文件夹正常生成。以后拿到CubeMX生成的工程，我第一件事就是检查这两个路径，避免重复踩坑。
9. 我踩过的几个坑，以及一点个人习惯
写到最后，把这些年用STM32CubeMX做初始化工程时踩过的坑和养成的习惯集中说几个，不一定都在前文出现，但都真实影响过我的开发效率。
第一个坑：新建工程时没留意HAL库版本。CubeMX固件包更新频率不低，不同版本之间的API有细微差异。如果工程A用F4固件包1.27，工程B用1.28，代码从A复制到B时，偶尔会出现某些新定义的宏找不到，或者某些初始化参数类型对不上。建议一个项目固定一个固件包版本，至少在一个完整开发周期内不要随意升级。
第二个坑：在CubeMX里改了配置直接点生成，却没注意到它只生成新代码，不会自动删除你已经改过的旧代码。CubeMX生成的代码区分“用户代码区”和“生成覆盖区”，两者用特殊的注释标记分隔：
/* USER CODE BEGIN 0 */ /* USER CODE END 0 */你写在这对注释里的代码，不管重新生成多少次都不会被覆盖。但如果你把代码写在注释之外的区域，重新生成时就会被冲掉。这个规则一定要刻在脑子里，否则某次generate code之后，你发现之前的实现全没了，那种心情体验一次就够了。
第三个坑：多个外设共用同一个中断优先级分组时，中断优先级配置不当导致的偶发问题。CubeMX里可以给每个外设中断设置Preemption Priority和Sub Priority，在裸机阶段看不出问题，一旦上了FreeRTOS，中断优先级和RTOS内核的临界区保护密切相关。FreeRTOS要求中断优先级不能超过某个宏定义的范围，否则会调用到FreeRTOS不安全的中断API。所以只要是RTOS项目，我会在初始化阶段就顺手检查一下FreeRTOSConfig.h里的configLIBRARY_MAX_SYSCALL_INTERRUPT_PRIORITY以及各外设中断优先级，确保预留了足够的空间。
最后说点个人习惯。以前我做初始化工程，总会忍不住继续往下写业务逻辑，后来发现这个习惯不好。现在我的做法是：CubeMX生成完代码后，先在默认工程上编译一次，确认零错误零警告；然后在main函数里跑通一个最基础的外设，比如串口打印或点灯，验证整个编译烧录链路没问题；如果要用RTOS，就再建一个空任务，确认调度器能正常跑起来。
每加一个外设，编译一次、验证一次。整个过程看起来慢，但实际比一口气加十几个外设、最后编译报一堆错再去排查要快得多。嵌入式调试的时间，大部分都花在“不确定是哪一层出了问题”，而CubeMX初始化工程的意义，恰恰是把你带到这样一个状态：每加一个模块时，你心里清楚，这一层是可靠的，问题只可能出在更上层的业务逻辑里。
这也是我觉得STM32CubeMX最值得使用的原因。它不是帮你省掉“写代码”这件事，而是帮你把“地基”打得足够确定，让你在往上盖楼的时候，不必每次都怀疑脚下是不是空的。
