What special requirements does ST-LINK_gdbserver place on an external flash loader? My loader works with ST-Link Utility, STM32CubeProgrammer, but not ST-LINK_gdbserver.

[smitty.werberjagermanjensen]

I've written an External Flash Loader and successfully tested erase, read, and write functionality first in my own firmware, then with ST-Link Utility v4.5.0, and also with STMCubeProgrammer v2.6.0.

However, when I try to use it to debug with TrueStudio, or simply with ST-LINK_gdbserver, I can not get past the loader's Init() so I'm unable to successfully connect to my system.

I initially had the problem when trying to debug with TrueStudio and selecting the external loader gave me the dreaded "Failed to initialize external memory!" error so I got TrueStudio out of the way and tried to work directly with ST-LINK_gdbserver instead.

• I'm using -el to tell GDB server where the .stldr file is.
• If Init() function does nothing but return 1, ST-LINK_gdbserver will start.
• If Init() function initializes clocks and peripherals (GPIO, OCTOSPI) and then returns 1, ST-LINK_gdbserver will start.
• If Init() tries to use GPIOs to indicate progress with LEDs or tries to use the OCTOSPI to configure the flash memory, even if my OCTOSPI init function only contains a return statement, ST-LINK_gdbserver fails to start.

Since I can use the memory and the external loader with other tools, I'm led to thinking that ST-LINK_gdbserver needs something specific from the external loader, or that it places some restrictions on it that my loader is not meeting.

Can anyone advise me on either how I should be configuring ST-LINK_gdbserver or how I should to change my loader to be able to debug my application?

Additional info:

• MCU is STM32L4S9xx
• Flash memory is W25Q128JV
• Debug log is attached

[Pavel A.]

Disclaimer - I don't know anything about external loaders, but it looks like the root cause is calling any other function from the main entry point.

Which suggests a problem with stack location or size.

-- pa

[smitty.werberjagermanjensen]

This was a good lead, even if it wasn't the actual issue. Thanks for responding.

I had been calling other functions from Init() so I knew calling functions was okay to an extent, but the failing ones were returning values where the succeeding ones weren't. This led me down a path that I won't bore you with.

In the end it turns out that my code was depending on the .rodata segment which was not being loaded by the gdb server process. It finally dawned on me when going through the debug log that it was only loading the .text segment and the memory descriptor structure, which gets its own section: .Dev_info.

I knew to avoid depending on the normal C 'framework' but this one surprised me, especially since ST-Link and STM32CubeProgrammer both seem to load the .rodata segment, which I've always treated 'as one' with code. This biz never stops teaching.

[waclawek.jan]

Thanks for sharing this hard-earned piece of wisdom.

JW

@Community member​ 

[Tesla DeLorean]

Not been using the GDB Server here, but ST's ELF loader has given headaches in the past. In the early days I was post-processing Keil/IAR output to do garbage removal, and unifying the sections, basically one for the code/data and another for the device details.

There isn't typically any initialization of the statics, beyond what's in the data section as loaded, so care is needed there. ST uses globals and memset(), I've tended to lean to autos and run the scatter loader.