My situation:
Trying to step through/debug a project that will run from the QSPI on the STM32H750B-DK in VS Code (on linux, if that matters). In order to test out the toolchain, I've started with two (separate) workspaces: on has the ExtMem_Boot project, the other the LTDC_Paint demo.
What works:
A/ Building both projects
B/ Flashing (via tasks.json and STM32CubeProgrammer) the ExtMem_Boot project
C/ Debugging the ExtMem_Boot project via the VS Code debug view
D/ Flashing (via tasks.json, STM32CubeProgrammer and the ExtLoader MT25TL01G_STM32H750B-DISCO.stldr) the LTDC_Paint demo.
E/ Launching the debug flow of LTDC_Paint (after modifying launch.json to include the serverExtLoader)
What fails:
The debugging automatically halts at the Reset_Handler of the startup file, the instruction for loading the stack pointer. But at this point I can't seem to step through it. Even just pressing the run arrow seems to result in a crash, rather than the actual execution.
What I find suspicious:
The debug console shows the following when the auto breakpoint in the reset handler is reached:
Program received signal SIGTRAP, Trace/breakpoint trap.
0x08000e28 in ?? ()
Which is not what I would expect, that seems to be an address referring to the isr_table of the bootloader, rather than our new location.
If I subsequently press the pause button of the debugger, we end up with:
Program received signal SIGINT, Interrupt.
0x08000e2c in ?? ()
Which again hints at being inside the bootloader.
Any thoughts on what to change to be able to debug my user application (in this case the LTDC demo)?
