是什么原因导致无头gdb调试器在错误的地址启动呢？

我正在尝试在 python 中开发一个自动测试脚本来测试在驻留在自定义 PCB 上的 STM32L496RG 上运行的嵌入式软件。为此，我尝试使用 ST 无头 GDB 调试器和无头构建实用程序。这个特殊的测试要求我在测试期间必须对源代码进行轻微修改（通过 python 脚本），我已经成功地完成了。
当我运行自动化测试脚本时，我能够修改代码、重建程序并执行测试步骤，这似乎总是在测试中第一次起作用，但之后就再也没有了。然后我必须断开调试器，甚至可能重新启动 MCU 以准备下一个我需要修改更多代码的测试步骤。第二次修改代码并重新构建后，我尝试启动调试器，它成功地与目标连接（或者看起来如此）。我通过确认 gdb 服务器与目标连接来验证这一点，然后 gdb 客户端使用正确的 elf 文件启动，最后服务器和客户端相互连接/链接。
现在这是关键，当程序第一次正确启动时，我收到一条消息，指出调试器所在的起始地址（在等待绿灯继续时），这是（如您所料）开始在重置处理程序。
Reset_Handler () 位于 ..Startup/startup_stm32l496rgtx.s:63
63 ldr sp, =_estack /* Atollic 更新：设置堆栈指针 */
但是在第二次重建之后，它声明它正在开始执行程序：
Eeprom_Format () 中的 0x08019670 位于 ../Src/Eeprom.c:82
82 nStatus = Nvm_WriteLong（eepromBaseAddress，NVM_FORMAT_HEADER）；
我认为这是程序中的地址。但是，../Src/Eeprom.c 是一个源文件，它存在于工作区内的另一个项目中，但不存在于这个特定项目中。此其他项目仅用于初始化此项目的 eeprom。这个问题似乎只在以无头方式运行所有这些时才会发生。当我使用 STM32CubeIDE GUI 构建并运行相同的代码时，一切似乎都运行良好。我在工作区中确实有多个项目，但我看不出它们是如何妨碍的，因为 gdb 调试器在安装过程中确认它指向正确的 elf 文件路径。我应该在启动调试器之前进行批量擦除或其他操作吗？这听起来像是构建问题还是调试器问题？
关于发生了什么的任何想法？