Why does headless build cause headless gdb debugger to start at the wrong address?

[MFolk.1]

I am trying to develop an automated test script in python to test embedded software running on the STM32L496RG which resides on a custom PCB. To do this, I am trying to utilize the ST headless GDB debugger and the headless build utilities. This particular test requires me to have to make slight modifications to the source code (via python script) during the test, which I have been able to do successfully.

When I run the automated test script I am able to modify code, rebuild the program, and execute a test step, which always seems to work the first time within the test, but never after that. I then have to disconnect the debugger and possibly even power cycle the MCU in preparation for the next test step where I need to modify more code. After modifying the code the second time and rebuilding, I attempt to startup the debugger, which is connecting with the target successfully (or so it seems). I verify this by confirming that the gdb server connects with the target, then the gdb client starts up with the correct elf file, and finally that the server and client connect/link with each other.

Now here is the kicker, when the program starts up correctly the first time I get a message stating that the starting address that the debugger is at (while it waits for the green light to proceed), which is (as you would expect) starting at the reset handler.

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

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

But after the second rebuild, it states that it is starting program execution at:

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

82       nStatus = Nvm_WriteLong(eepromBaseAddress, NVM_FORMAT_HEADER);

which I believe is an address within the program. However, ../Src/Eeprom.c is a source file that exists in another project within the workspace, but not this particular project. This other project is only used to initialize eeprom for this project. This issue only seems to occur when running all of this in a headless fashion. When I build and run the same code using the STM32CubeIDE GUI it all seems to work just fine. I do have multiple projects within the workspace, but I don't see how they could be getting in the way because the gdb debugger confirms during setup that it is pointing to the correct elf file path. Should I be doing a mass erase or something before starting up the debugger? Does this sound like a build problem or a debugger problem?

Any ideas as to what is going on?

Thanks,

Marshall

[MFolk.1]

**UPDATE**

I have now proved that this is a headless build problem and not a debugger problem. It is either a headless build configuration settings issue or it is a glitch in the headless build program. I am still playing with the build configuration settings to see. Any guidance or advice on this would be appreciated.

-Marshall

[Tesla DeLorean]

Perhaps double check what's getting built via .MAP file, .HEX or .ELF outputs

Looking for different addresses, perhaps settings embedded in the debug data, etc.

[MFolk.1 · Accepted solution]

Okay. I figured it out. It is not a build problem. You could argue that it isn't even a ST-Link GDB debugger problem. However, I most definitely think it is a GDB debugger problem.

I assumed that the ST-Link GDB headless debugger functioned the same as it does in the UI version of STM32CubeIDE. Specifically, that the headless command to start the GDB debugger automatically programs the updated elf file onto the target as it boots up. I assumed this because why else would a command to start the GDB Client take in the file path to the elf file if it isn't going to load it on the target for you.

arm-none-eabi-gdb.exe C:\..\Debug\ProjectName.elf

Why not just call the client executable without arguments if the program isn't going to do anything with the arguments? This command below would do just fine.

arm-none-eabi-gdb.exe

Anyways, I fixed this issue by adding in a headless command call to the STM32Programmer to manually load the updated image onto the target before starting the GDB debugging session.

C:\ST\STM32CubeIDE_1.6.1\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_2.0.0.202105311346\tools\bin\STM32_Programmer_CLI.exe -c port=SWD -w C:\..\Debug\ProjectName.elf

Hopefully this helps others who think like me.

Thanks,

Marshall