编译会导致GDB 调试器在错误的地址启动

我用 Python 开发一个自动化测试脚本，用于测试运行在 STM32L496RG 嵌入式软件。我用 ST 的无界面 GDB 调试器。这个测试需要在测试过程中通过 Python 脚本对源代码进行小幅修改，我已经成功实现了这一点。

运行自动化测试脚本时，我能够修改代码、重新构建程序并执行测试步骤，第一次测试通常能成功，但之后就不行了。然后，我必须断开调试器连接，甚至可能需要重新上电 MCU，为下一个需要修改更多代码的测试步骤做准备。第二次修改代码并重新构建后，我尝试启动调试器，调试器似乎成功连接了目标设备。我通过确认 GDB 服务器与目标设备连接、GDB 客户端启动并加载正确的 elf 文件，以及服务器和客户端成功建立链接来验证这一点。

但问题是：第一次程序正确启动时，调试器会显示它等待继续执行的起始地址（如预期）是复位处理程序：

Reset_Handler () at ..\Startup/startup_stm32l496rgtx.s:63  

63       ldr  sp, =_estack   /* Atollic update: set stack pointer */

而第二次重新编译后，调试器显示程序执行的起始地址是：

0x08019670 in Eeprom_Format () at ../Src/Eeprom.c:82  

82       nStatus = Nvm_WriteLong(eepromBaseAddress, NVM_FORMAT_HEADER)

。../Src/Eeprom.c 是工作空间中另一个项目的源文件，并不属于当前项目。这个其他项目仅用于为当前项目初始化 EEPROM。当我使用 STM32CubeIDE 图形界面编译并运行相同代码时，一切正常。工作空间中确实有多个项目，但我不明白它们如何干扰，因为 GDB 调试器在设置时确认指向了正确的 elf 文件路径。是否应该在启动调试器之前进行全擦除？这看起来是编译问题还是调试器问题？

可能由于构建系统缓存或增量编译问题，导致 ELF 文件未完全更新。

可能Flash 内存未完全擦除。

强制完整重新构建，在每次修改代码后，执行 完整清理和重新构建，避免增量编译导致的问题。

手动擦除 Flash，在加载新程序前，完全擦除 MCU 的 Flash，避免旧代码残留。

最可能的原因是 Flash 未完全擦除 或 构建系统未正确更新 ELF 文件，导致调试器加载了旧代码的符号表或地址映射。