编译项目时FLASH 溢出

发表于 2026-9-6 21:29

最简单粗暴的办法：把main函数里的while循环主体用__attribute__((section(".ramcode")))放到RAM中执行，释放少量FLASH，但需注意RAM只有6KB，放不下大函数。

发表于 2026-9-5 12:10

这事儿我遇到过，主要是代码量太多。你可以试试优化代码，比如去除未使用的函数和变量，或者提高编译器优化等级。

发表于 2026-9-6 13:02

堆和栈的大小设置是在链接脚本里改的，它们占用的是RAM空间，跟FLASH溢出没有直接关系。你这个问题大概率是代码体积真的超过了32K，或者是编译器优化等级没开。建议先把优化等级调到-Os试试，通常能缩减不少体积

发表于 2026-9-7 08:12

USB CDC库本身挺占空间的，特别是那个描述符表和端点处理逻辑。如果你只用了CDC功能，检查一下是不是把其他没用到的USB类驱动（比如HID、MSC）也编译进去了。在CubeMX或者工程配置里把不用的USB功能关掉，能省出几K空间

发表于 2026-9-8 10:03

看看你的printf重定向是不是用了标准的sprintf或者浮点运算。STM32F0这种Cortex-M0内核，处理浮点数非常吃FLASH。如果只是为了调试打印，尽量用整数格式化，或者自己写个轻量级的itoa函数替代标准库的转换函数

发表于 2026-9-10 08:04

还有一种可能是中断向量表占用了太多空间。虽然F0的向量表不大，但如果你定义了很多弱函数或者空的中断处理函数，也会占地方。检查一下启动文件，把没用的中断处理函数删掉，或者用宏控制一下

发表于 2026-9-11 09:15

既然超了12480字节，说明你的代码量可能在45K左右？F070C6只有32K Flash，这差距有点大。建议你用Map文件分析一下，看看哪个.o文件占用了最多空间。有时候不小心包含了整个字符串库或者数学库，体积瞬间爆炸

发表于 2026-9-12 11:05

如果代码实在优化不下来了，可以考虑把常量数据放到RAM里运行，或者利用STM32的Option Bytes把部分Flash映射到RAM地址空间（如果芯片支持的话）。不过F0系列好像不支持这个高级操作，那就只能硬抠代码了

发表于 2026-9-13 15:05

检查一下是不是开启了Debug信息编译。Release版本和Debug版本的体积差别很大，Debug模式下为了保留调试符号，代码体积会膨胀很多。如果是做最终产品，一定要切到Release模式编译

发表于 2026-9-14 10:16

USB CDC的发送缓冲区如果设得太大也会占FLASH（如果是const数组初始化）。64字节其实还好，但如果你为了追求速度搞了双缓冲甚至四缓冲，那就要命了。对于CDC这种低速设备，单缓冲完全够用

发表于 2026-9-15 08:06

还有一个冷门原因：编译器版本。有些老版本的GCC对M0内核的代码生成效率不高，升级到最新的ARM GCC工具链，有时候能凭空省出10%的空间。Keil的话，试试ARM Compiler 6，比AC5紧凑不少

发表于 2026-9-16 09:13

实在不行就换芯片吧，F070C6确实有点小。现在国产替代或者ST自己的F072系列，价格差不了几分钱，Flash直接翻倍到64K甚至128K。为了省几毛钱去死磕32K的极限，后期维护成本太高了，不划算

发表于 2026-9-6 14:36

检查USB_CDC库版本，有些老版本库文件很大，可以考虑升级到新版本或者替换为更轻量级的库。

发表于 2026-9-7 12:04

检查你的USB_CDC库版本，老版本库可能会占用较多空间，升级到最新版可能能解决。

发表于 2026-9-10 09:33

优化代码结构，减少未初始化全局变量，考虑使用栈内存代替部分全局变量。

发表于 2026-9-12 14:49

检查代码中是否有大段未使用的代码，比如冗余的函数或过大的数据结构，这些可能占用不必要的FLASH空间。

发表于 2026-9-14 12:11

检查是否真的需要64字节缓冲区，可以考虑减少到32字节，看看是否能解决问题。

发表于 2026-9-15 19:12

检查HAL库版本，可能HAL库本身已经占用了较多空间，升级到更精简的版本或使用第三方库替换。

发表于 2026-9-16 14:23

优化代码，去除不必要的全局变量和回调函数，尝试调整编译器优化等级到-Os，应该能解决溢出问题。

[STM32F0] 编译项目时FLASH 溢出