STM32CubeIDE for VSCode 链接脚本修改不生效问题总览

1. 文档背景与问题现象

LAT1724 是 ST 中国本地应用提示笔记，聚焦STM32CubeIDE for VSCode + CMake 工程场景下的典型工程构建问题：开发者手动修改.ld链接脚本内 ROM（Flash）起始地址，执行 Build 编译，输出 ELF 文件的 Flash 加载地址不会跟随 ld 文件变更，修改不生效。

该问题常见于 Boot‑App 双固件开发场景，需要分割 Flash 地址空间，Boot 程序占用 Flash 前段，App 程序偏移至0x08001000等偏移地址。开发者修改链接脚本 MEMORY 段内org起始地址后，直接点击 Build，编译输出无报错，但 ELF 内部程序加载地址维持旧值，不会更新为修改后的偏移地址。

现象还原：将 ld 脚本中ROM(rx): org = 0x08000000, len = 0x80000修改为org = 0x08001000，直接执行 Build，elf 文件地址不变，编译器没有重新处理链接脚本变更。

资料获取：实战经验 | LAT1724 STM32CubeIDE for VSCode修改链接文件中的Flash起始地址无效？

2. 问题发生环境与触发条件

硬件芯片

文档示例使用 STM32C562RET6，该问题不属于芯片硬件 bug，属于CMake 工程构建依赖逻辑缺陷，所有 STM32CubeMX 输出 CMake 工程均可能触发。

软件环境

1. STM32CubeIDE for VSCode V3.9.0
2. VSCode V1.124.2
3. CubeMX 生成 CMake 类型工程，GCC 编译链

触发条件

1. 使用 STM32CubeMX 生成 CMake 工程；
2. 手动修改 user_modifiable 路径下*_flash.ld链接脚本的 MEMORY 内存起始地址；
3. 直接执行 Build，不做工程清理；
4. CMake 默认配置没有将 ld 链接脚本设置为链接阶段依赖项。

3. 问题带来的业务影响

此问题不会报编译报错，属于隐性错误，极易被工程师忽略，会带来多类落地风险：

1. Boot‑App 升级场景：App 固件链接地址没有偏移，烧录后程序运行在错误 Flash 区间，固件直接崩溃，OTA 升级失败；
2. 现场调试排错成本高：编译日志无警告，工程师反复核对 ld 脚本，难以定位是构建依赖问题，怀疑芯片、CubeMX 配置、烧录工具；
3. 功能安全项目风险：例如 X‑CUBE‑CLASSB 功能安全项目，Flash 分区、备份缓存依赖链接脚本，地址偏移失效会直接导致自检库运行异常（可与 LAT1730 文档工程场景联动）；
4. 批量生产隐患：如果自动化 CI 脚本没有加入清理步骤，CI 产出固件地址错误，流入生产批次。

4. 工具版本矩阵