How to stop STM32CubeIDE from opening random files when debug is started?

[HTD]

Every time I debug my project for STM32H747 (created with TouchGFX), the debugger opens a bunch of random files, different each time.

It does that BEFORE even finishing uploading the project to the board. Before I even get "Verifying" on the console.

Then it stops at MPU_Config() in main.c.

It doesn't do that in projects created with STM32CubeIDE, just with a TouchGFX project.

It's super annoying, is there any way to stop that beavior?

[Dave D.]

This makes sense, and explains why, after I've added more application code (and working on debugging the same), now the tool's favorite unsolicited file to open is different from before.

[HTD]

1) Agree.

2) Probably not true anymore, I still have that option in the current version and it works as expected, so no forced break point at main().

And... I think it's a bug not a feature 😉 When you debug your code, you NEVER want to debug the debugger (or IDE), except when you debug the debugger, but then the debugger or IDE is your code.

I think we're all pretty fed up with this "feature" already, I'm getting to a point where I spend more and more time configuring another toolchain to work with my projects. For the coding I mostly use Visual Studio Code, it's just so much faster and has some useful extensions. However I haven't figured out yet how to make builds and debugging from there. But if I succeeded one day it would be such a relief 😉

[PHolt.1]

" I still have that option in the current version and it works as expected, so no forced break point at main()."

I'd like to know where it is : - )

It used to be under Debugger config but not anymore.

[t.decker]

Look in the next tab "startup" 

[PHolt.1]

Well spotted, but mine is grayed-out

[Dave D.]

What is especially aggravating about this issue is that it cannot be ignored. If I choose to leave open the unsolicited files (not bothering to close them), the IDE will continue to open more files, each time I run the debugger. This eventually jams the editor window with tabs spilling over. This dumb tool is even opening C source files which are inside folders that I have excluded from the build (both Debug and Release, grayed out with slash through them.) That should not even be possible.

[HTD]

I know why. It's another bug in a "fractal of bad design" 😉

Do you see `Builder type` set to `Exernal builder`? I think you have this option selected the same way I have. Why do I have it selected? Because the internal builder is totally broken and not usable, since it just crashes 99% times I try to build my project. It's a steaming pile of junk, do not use, ever again. I have PTSD from waiting for 15 minutes to build my project and then having to kill the CubeIDE, restart it, wait another 5 minutes for it to open again, wait another 15 minutes to "4%" to find out it's not responsive and then start over. So - this bug is worked around by selecting `External builder` - it works. Just like this. It's not fast, it's not "better", but does one "simple" thing: builds the project. However...

I have startup options grayed out exactly as in your picture. But there's more! I have breakpoint at `main` DISABLED 😉 Why do I have it? Because you can set this option when the `Builder type` is set to `Internal builder`. So - set it up, apply, change the startup option, then DON'T FORGET TO SWITCH THE BUILDER TO `EXTERNAL` if you want your project to build at all and save countless hours lost on its crashes.

Please tell me if it worked.

[PHolt.1]

It didn't work, but after some googling I found this

https://stackoverflow.com/questions/66566866/stm32cubeide-run-configurations-how-to-disable-set-breakpoint-at-main-if-gra

If you go into the config via this other route, the option is not grayed-out.

And it works. F11 takes me straight to a running project. No more breakpoint at main().

[AnkhInnovationsLLC]

This is still the case in 2023 as of October 9th... Just absolutely terrible working in the STM32 IDE.

Press launch, it randomly switches to the open IOC, then to the xxx startup.S file. Super super annoying.

I'm finding the overall experience with ST to be quite poor, its taking us way way longer to do anything really because everything is in poor old inaccurate PDF's, the IDE is so slow (it takes about 3 seconds to switch tabs) and its so janky its ridiculous. I've never seen an IDE jump into TWO random files just running the program.

[KMill]

I agree - this simple bug is taking far too long to get fixed. It shows that STM32CubeIDE is a very low priority for ST, and therefore not one we can rely on for long term support. If I were cynical I'd say it's deliberate in order to push people towards paid-for IDE's by other suppliers. But I maintain my long-held belief that chip manufacturer's must porvide free, high quality tools to support their chips, as it drives confidence and therefore sales. Low quality tools and shockingly bad support like this example have me looking for other suppliers.