Debugging QSPI XiP with VS Code on STM32H750B-DK

[jeetee]

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)?

[Florent V]

Hi @jeetee,

I see that you are using JSON tasks to flash.
However, it is possible to do everything from the debug configuration. Could you share your debug configuration?
Because if you are using JSON tasks to flash, then you need to do a “hot attach” to connect to the board (which mean no reset and no programming).

Kind Regards,
/Flo

[jeetee]

Hey,

I resorted to flashing via tasks.json because I at first couldn't get the built-in debug to "just work". It's also handy to not have to enter debug mode for when just flashing is required.

Look at point E though as well, where I finally got the normal debug configuration (launch.json) to at least have it start building/flashing and launching the debugger, only to then halt at the wrong place.
Here's the current configuration:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        
        {
            "type": "stlinkgdbtarget",
            "request": "launch",
            "name": "STM32Cube: Launch ST-Link GDB Server",
            "origin": "snippet",
            "cwd": "${workspaceFolder}",
            "preBuild": "${command:st-stm32-ide-debug-launch.build}",
            "runEntry": "main",
            "serverExtLoader": [
                {
                    "loader": "/home/jeetee/STMicroelectronics/STM32Cube/STM32CubeProgrammer/bin/ExternalLoader/MT25TL01G_STM32H750B-DISCO.stldr",
                    "initialize": false
                }
            ],
            "imagesAndSymbols": [
                {
                    "imageFileName": "${command:st-stm32-ide-debug-launch.get-projects-binary-from-context1}"
                }
            ],
            "svdPath": "home/jeetee/STMicroelectronics/STM32Cube/STM32CubeProgrammer/SVD/STM32H750.svd"
        }
    ]
}

[jeetee]

Oh.

I just discovered that after the Debug View loads and halts in internal flash, rather than the code inside the QSPI, pressing the "reset target" button of the debugger toolbar once seems to make it work out.

Would be nice to not have to manually do that each time a debug session starts though..

[LaurentL · Accepted solution]

Hello,

If you execute code (XiP) in ext flash, set the "Initialize" to true in serverExtLoader attribute.

Your code in boot will map the ext flash but the debugger will try to set breakpoint in ext flash before that code is executed.

If it is only data for graphic in ext flash, you don't need to set the "Initialize".

[jeetee]

That did it.

I had it at false due to the wording at https://community.st.com/t5/stm32-mcus/stm32cubeide-for-vs-code-debug-configuration-launch-json/ta-p/866870#toc-hId-349296579 (5.3. How to debug with external loader, point 3).
But that then refers not to XiP, but to data storage, I now understand.

Thanks!