cancel
Showing results for 
Search instead for 
Did you mean: 

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

HTD
Senior III

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?

21 REPLIES 21
Yoann KLEIN
ST Employee

Hello,

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

Thanks for your help,

/Yoann

Yoann KLEIN
ST Software Developer | TouchGFX
mattias norlander
ST Employee

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.
Associate II

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

Hi,

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

/Yoann

Yoann KLEIN
ST Software Developer | TouchGFX
HTD
Senior III

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.

PHolt.1
Senior III

It happens only when I restart the target with


_legacyfs_online_stmicro_images_0693W00000bjE45QAE.png 

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)

Pavel A.
Evangelist III

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
Senior III

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