1. 现象复现STM32C092GCU7 烧录进度条卡死在 50%1.1 用的什么环境怎么复现的我最近在一块自研板上把主控换成了 STM32C092GCU7这颗芯片是 ST 的 C0 系列Cortex-M0 内核48MHz 主频Flash 一共 64KBRAM 24KBUFQFPN48 封装。板子供电走的独立 3.3V LDO调试器是 ST-LINK/V2SWD 用四根杜邦线直接连到板子上。IDE 用的 STM32CubeIDE 1.15 左右固件包是 STM32Cube FW_C0 系列。刚开始跑空工程、点灯程序都正常。等我把 USB 协议栈、轻量级任务调度和业务逻辑全部加进去之后编译能过但一点 Debug烧录进度条走起来到一半的位置就停了。试着重复烧了三遍每一次都卡在同一个地方大概就是总进度的 50% 附近。弹窗报错调试器连接立刻断开必须给板子重新上电才能再次连上。这个“恰好半程”的现象非常典型它基本把问题指向了 Flash 地址空间的某个边界而不是程序本身或链接问题。为了把问题说清楚我把完整的排查过程记录下来从 IDE 配置、链接脚本一路查到 Option Bytes最后定位到根因并修复。如果你也遇到过“烧录只烧一半”“Flash download failed”这类问题顺着这条链路走一遍大概率能找到答案。1.2 报错信息与“恰好 50%”这个关键线索复现步骤很简单工程编译无 error生成 .elf 和 .hex。点击 IDE 的 Debug 按钮相当于烧录后进入调试。进度条走到约 50% 时弹出错误窗口。Console 区域报错类似Error: flash download failed - Cortex-M0或者内存访问类错误Cannot access target/Cannot access memory。点掉错误后调试会话结束ST-LINK 失联需要重新上电。这里我注意到一个关键细节空工程和内容小于 32KB 的程序都能正常下载只有程序规模超过 32KB 之后才会失败。这说明问题不在 IDE 安装、编译链或程序代码本身而在于烧录到某个地址之后芯片或者 IDE 的写入流程开始出现异常。另外如果你在报错里看到的是Cortex-M3而不是Cortex-M0那基本可以断定是某个旧的 Debug Configuration 或者烧录算法残留串场了。STM32C092GCU7 是 M0 内核不会自己“变成”M3。后面我会专门讲算法列表的问题。2. 从 IDE 配置层过筛型号、烧录算法与链接脚本2.1 器件型号选错C091 和 C092 的 32K/64K 陷阱第一轮排查先从最表面的配置开始。ST 的 C0 系列里STM32C091 和 STM32C092 是脚位兼容的都是 UFQFPN48但 Flash 容量不同C091 是 32KBC092 是 64KB。两者外观几乎一样CubeIDE 的 Device Selector 搜索结果里也经常排在一起选错型号的概率不低。如果你在新建工程时把器件选成了 STM32C091GCU7CubeIDE 生成的链接脚本就会按 32KB Flash 来设置编译时程序超过 32KB 会直接报 overflow。但更隐蔽的情况是你的程序只有 20 多 KB能编译过也能烧录但工具链从模型上就认为这颗芯片只有 32KB Flash高 32KB 的存储空间在编译器和下载器眼里根本不存在。这种情况下你看到“Program size 显示 50%”或者“烧录结果只有 50%”就是因为整个工程的容量假设就是错的。自查方法很直接打开工程根目录下的.ioc文件搜索Mcu.Name正确应显示STM32C092GCU7。右键工程 → Properties → C/C Build → MCU 设置查看器件信息。检查生成的链接脚本这一步见 2.3。2.2 Flash Download 算法列表里混入了 32KB 的“幽灵”算法如果说型号选错是明面上的坑那 Flash Download 算法列表就是暗坑重灾区。在 STM32CubeIDE 里烧录动作不是简单的“把 bin 文件丢给芯片”而是通过一段 Flash Loader 算法去操作具体的 Flash 控制器。查看入口Run → Debug Configurations → 选择当前工程的调试配置 → Debugger 选项卡 → 往下找 Flash Download 区域。不同版本 IDE 的界面略有差别有的叫 Downloads有的叫 Flash Download本质是一回事。重点看 Programming Algorithm 列表。正常情况下C092 应该只有一个条目名字类似STM32C0xx 64KB Flash 0x08000000范围 64KB。如果你在这里看到32KB Flash条目或者在同一个配置里残留了其他芯片的算法那下载器就会按那个“错误地图”去操作 Flash。我当时就在这个列表里找到一条32KB的算法。回想一下应该是之前在这个工作区里建过其他 C0 系列的工程调试配置切换时把旧算法带了过来。烧录时 CubeIDE 按算法声明的地址范围执行擦除和写入走到 0x08007FFF 之后就不知道该怎么处理于是报错。因为地址范围正好是 64KB 的一半进度条也就停在 50%。处理办法选中错误的算法条目点击 Remove。点击 Add从列表里选择当前器件对应的 64KB Flash 算法。如果搞不清楚哪个是对的直接点 Reset to Defaults 恢复默认配置。删掉旧的 Debug Configuration重新用 Debug As → STM32 C/C Application 生成一份全新配置能避免很多残留问题。2.3 链接脚本里 FLASH 长度到底是多少烧录算法管的是“下载器能写多少个地址”链接脚本管的是“编译器认为程序放得下多少代码”。两者必须同步。检查链接脚本打开工程目录下的.ld文件文件名一般是STM32C092GCU7.ld。看 MEMORY 段MEMORY { RAM (xrw) : ORIGIN 0x20000000, LENGTH 24K FLASH (rx) : ORIGIN 0x08000000, LENGTH 64K }如果 LENGTH 显示的是 32K说明工程按 32KB Flash 器件生成和 C092 的实际容量不符。这种情况下程序只要超过 32KB链接器直接报错小于 32KB 时编译输出尾部会显示类似这样的信息Memory region Used Size Region Size %age Used FLASH: 32000 B 327 STM32C092烧录卡50%？排查Flash下载算法与链接脚本
1. 现象复现STM32C092GCU7 烧录进度条卡死在 50%1.1 用的什么环境怎么复现的我最近在一块自研板上把主控换成了 STM32C092GCU7这颗芯片是 ST 的 C0 系列Cortex-M0 内核48MHz 主频Flash 一共 64KBRAM 24KBUFQFPN48 封装。板子供电走的独立 3.3V LDO调试器是 ST-LINK/V2SWD 用四根杜邦线直接连到板子上。IDE 用的 STM32CubeIDE 1.15 左右固件包是 STM32Cube FW_C0 系列。刚开始跑空工程、点灯程序都正常。等我把 USB 协议栈、轻量级任务调度和业务逻辑全部加进去之后编译能过但一点 Debug烧录进度条走起来到一半的位置就停了。试着重复烧了三遍每一次都卡在同一个地方大概就是总进度的 50% 附近。弹窗报错调试器连接立刻断开必须给板子重新上电才能再次连上。这个“恰好半程”的现象非常典型它基本把问题指向了 Flash 地址空间的某个边界而不是程序本身或链接问题。为了把问题说清楚我把完整的排查过程记录下来从 IDE 配置、链接脚本一路查到 Option Bytes最后定位到根因并修复。如果你也遇到过“烧录只烧一半”“Flash download failed”这类问题顺着这条链路走一遍大概率能找到答案。1.2 报错信息与“恰好 50%”这个关键线索复现步骤很简单工程编译无 error生成 .elf 和 .hex。点击 IDE 的 Debug 按钮相当于烧录后进入调试。进度条走到约 50% 时弹出错误窗口。Console 区域报错类似Error: flash download failed - Cortex-M0或者内存访问类错误Cannot access target/Cannot access memory。点掉错误后调试会话结束ST-LINK 失联需要重新上电。这里我注意到一个关键细节空工程和内容小于 32KB 的程序都能正常下载只有程序规模超过 32KB 之后才会失败。这说明问题不在 IDE 安装、编译链或程序代码本身而在于烧录到某个地址之后芯片或者 IDE 的写入流程开始出现异常。另外如果你在报错里看到的是Cortex-M3而不是Cortex-M0那基本可以断定是某个旧的 Debug Configuration 或者烧录算法残留串场了。STM32C092GCU7 是 M0 内核不会自己“变成”M3。后面我会专门讲算法列表的问题。2. 从 IDE 配置层过筛型号、烧录算法与链接脚本2.1 器件型号选错C091 和 C092 的 32K/64K 陷阱第一轮排查先从最表面的配置开始。ST 的 C0 系列里STM32C091 和 STM32C092 是脚位兼容的都是 UFQFPN48但 Flash 容量不同C091 是 32KBC092 是 64KB。两者外观几乎一样CubeIDE 的 Device Selector 搜索结果里也经常排在一起选错型号的概率不低。如果你在新建工程时把器件选成了 STM32C091GCU7CubeIDE 生成的链接脚本就会按 32KB Flash 来设置编译时程序超过 32KB 会直接报 overflow。但更隐蔽的情况是你的程序只有 20 多 KB能编译过也能烧录但工具链从模型上就认为这颗芯片只有 32KB Flash高 32KB 的存储空间在编译器和下载器眼里根本不存在。这种情况下你看到“Program size 显示 50%”或者“烧录结果只有 50%”就是因为整个工程的容量假设就是错的。自查方法很直接打开工程根目录下的.ioc文件搜索Mcu.Name正确应显示STM32C092GCU7。右键工程 → Properties → C/C Build → MCU 设置查看器件信息。检查生成的链接脚本这一步见 2.3。2.2 Flash Download 算法列表里混入了 32KB 的“幽灵”算法如果说型号选错是明面上的坑那 Flash Download 算法列表就是暗坑重灾区。在 STM32CubeIDE 里烧录动作不是简单的“把 bin 文件丢给芯片”而是通过一段 Flash Loader 算法去操作具体的 Flash 控制器。查看入口Run → Debug Configurations → 选择当前工程的调试配置 → Debugger 选项卡 → 往下找 Flash Download 区域。不同版本 IDE 的界面略有差别有的叫 Downloads有的叫 Flash Download本质是一回事。重点看 Programming Algorithm 列表。正常情况下C092 应该只有一个条目名字类似STM32C0xx 64KB Flash 0x08000000范围 64KB。如果你在这里看到32KB Flash条目或者在同一个配置里残留了其他芯片的算法那下载器就会按那个“错误地图”去操作 Flash。我当时就在这个列表里找到一条32KB的算法。回想一下应该是之前在这个工作区里建过其他 C0 系列的工程调试配置切换时把旧算法带了过来。烧录时 CubeIDE 按算法声明的地址范围执行擦除和写入走到 0x08007FFF 之后就不知道该怎么处理于是报错。因为地址范围正好是 64KB 的一半进度条也就停在 50%。处理办法选中错误的算法条目点击 Remove。点击 Add从列表里选择当前器件对应的 64KB Flash 算法。如果搞不清楚哪个是对的直接点 Reset to Defaults 恢复默认配置。删掉旧的 Debug Configuration重新用 Debug As → STM32 C/C Application 生成一份全新配置能避免很多残留问题。2.3 链接脚本里 FLASH 长度到底是多少烧录算法管的是“下载器能写多少个地址”链接脚本管的是“编译器认为程序放得下多少代码”。两者必须同步。检查链接脚本打开工程目录下的.ld文件文件名一般是STM32C092GCU7.ld。看 MEMORY 段MEMORY { RAM (xrw) : ORIGIN 0x20000000, LENGTH 24K FLASH (rx) : ORIGIN 0x08000000, LENGTH 64K }如果 LENGTH 显示的是 32K说明工程按 32KB Flash 器件生成和 C092 的实际容量不符。这种情况下程序只要超过 32KB链接器直接报错小于 32KB 时编译输出尾部会显示类似这样的信息Memory region Used Size Region Size %age Used FLASH: 32000 B 327