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?

[Yoann KLEIN]

Hello,

@mattias norlander​ , do you have an idea about that ?

Thanks for your help,

/Yoann

[mattias norlander]

Hi,

A bit late on the ball here. This is timing related in the debug stack.

When debug is launched the GDB-server connects to target.

Then the GDB-client connect to the GDB-server.

During this procedure the GDB-client is doing a hand-shake to determine what is the target which registers are available in this CPU etc.

The problem is that Eclipse/CDT intercepts this information and specifically the PC-register and assumes that the target now is halted and that the debug launch is done.

Consequently it does a look-up of the PC-register value and tries to map it to the C-code and open the editor in the right file.

Keep in mind that this is even before we have flashed the changes to the project we are debugging --> the read PC-value from target may not map correctly with the new built elf-file. We can even open the incorrect c-file.

So the problem (as far as we have investigated up until today) is that Eclipse/CDT tries to show data before debug launch is finished.

There are discussions in this area in the up-stream community. Maybe even some patches. But not something ready for next release.

I cannot find a simple work-around either.

[Dave D.]

Is there any progress toward a resolution for this problem?

I see the issue regularly with projects created with STM32CubeIDE (using v1.12.0). After the debugger connects, the IDE opens startup_stm32g491retx.s. After I Terminate, it opens stm32g4xx_hal.c. And sometimes if I don't close those unsolicited files, it opens one of the large files, then dutifully reports to me that it is opening a large file.

Thanks,

Dave

[Yoann KLEIN]

Hi,

Maybe @mattias norlander​ has some news about that :)

/Yoann

[Piranha]

https://community.st.com/s/question/0D53W00000AbWCbSAN/jumping-to-random-file-after-pressing-run-button

[HTD]

I still can't find the solution. It's still there in 1.12.0. I've read the explanation. That the debugging backend fires when you call `Run` and it just follows impulses from the code. They are like some invisible and uneditable breakpoints, yada-yada. The easy fix for one who knows the codebase would be to test if the "breakpoint" comes from the user code or IDK, bootloader, system or IDK what else and ignore it. Even easier one: test if the proper CubeIDE debug session is started - if not - IGNORE ALL EVENTS from the debugger, ignore "fileOpen()" call, geez, disable it until a flag is set the "main()" was entered. It's not a rocket science but I won't fix it myself because I have my own work to do, however, it should be really easy for a person who just knows the codebase, which parts are where.

[Pavel A.]

Some good ideas here. IMHO would better work on these in the upstream Eclipse CDT embedded, then wait patiently for CubeIDE to "inherit" from there.

[PHolt.1]

It happens only when I restart the target with

 

Then it opens a "random" file but the file opened is the code which was running when the target was reset. Which file is opened, is wherever the CPU was when the above button was pressed.

So the file opened is not "totally random" but is not desirable to have it opened; it serves no purpose. It means that if you restart the target say 20 times, you get 20 file openings, and depending on where the CPU spends most of its time, you may get 20 different files, or fewer. If for example CPU spends a lot of time waiting on some mutex, then over 20 restarts you will get mostly tasks.c (the FreeRTOS main file) opened, but you may get other files so if e.g. the mutex is around some SPI code, you will get tasks.c and sometimes spi.c. Eventually you will get loads of different files opened.

This probably explains why some people get it much worse than others.

(Posted in another thread of same topic, but what the h e l l since nobody at ST cares anyway)

[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.

[PHolt.1]

"Even easier one: test if the proper CubeIDE debug session is started - if not - IGNORE ALL EVENTS from the debugger, ignore "fileOpen()" call, geez, disable it until a flag is set the "main()" was entered."

1) sometimes one wants to have breakpoints working before main()

2) FWIW, current Cube always sets a breakpoint on main() and AFAICT the config for not having that has been removed

"IMHO would better work on these in the upstream Eclipse CDT embedded, then wait patiently for CubeIDE to "inherit" from there."

This issue is several years old and ST have shown no interest in fixing it. Also it may be ST debug process specific. Can anyone confirm whether it exists in non ST versions of Eclipse? I don't think it does.

[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.