STlink debugging hardcoded to start at Reset_Handler address ignoring vector table values.

[AOmel.242]

STM32F030R8

Blank project, no CMSIS, no Cube libraries.

Code copied from my old TrueStudio project.

I use old startup_stm32f030x8.s with some modifications.

If I change startup vector table start entry to my function (named not Reset_Handler but Boot_Start), then

compiler works OK,

elf contains correct vector table

downloads and runs OK

BUT

debugging by ST-Link (with unchecked "Resume" in Startup Debug Configuration settings):

debugger shows my function (OK)

disassembler window shows my function (OK)

BUT

PC register is set to Reset_Handler address (or junk if no such symbol)

and attempt to step or run will go to bad address.

Well,

I can rename my startup function into Reset_Handler and old Reset_Handler (I will jump there in the end) in some Old_Reset_Handler. Then I can debug my bootloader and my application.

Nevertheless it's an IDE Bug.

(TrueStudio performed OK in that case).

[Tesla DeLorean]

Check entry point exported in .ELF header

[AOmel.242 · Accepted solution]

You are right,

readelf shows entry point set to Reset_Handler, not to my routine, despite to correct vector table.

I,ve changed setting in .ld file, and now it is ok.

So, it is not Bug.

I'm sorry.

Just different behavior re. TrueStudio.

Of course, it would be nice for debugger to inform us about inconsistency of elf header and vector table.