Jumping to random file after pressing Run button

[GeneralTao]

Hello. When I press to Run (Run main.c) button, STM32CubeIDE opens random file, possibly, from current repository, for example: startup_stm32l452xx.s, core_cm4.h etc...

Code is loading successful, but this side effect bothers me.

I would like to disable this function. How can I do it?

If you need more information about this behavior please, ask.

Thank you for reading.

[Brian H]

Chiming in to say that ARaid.1's report is completely erroneous.

1. The issue absolutely does manifest with ST-LINK ICEs (I have used both V2 and V3) [this is because the bug is almost certainly not related to the ICE]
2. There is absolutely no need to halt the uC to see the issue. The unwanted file is opened whether or not the uC is halted.
3. A "one C file" project is so unrepresentative of typical usage as to be laughable. Further, in my experience at least, often the unwanted file is not a .c file but a .s file (part of low-level bootstrapping code that is included in a typical library-based project)

[PHolt.1]

"There is absolutely no need to halt the uC to see the issue. The unwanted file is opened whether or not the uC is halted"

The unwanted file gets opened upon a specific event. IME it opens when the CPU is reset or un-reset; I can't tell which but in my typical usage it happens during debugging, or after a debug build (F11). I think the CPU is briefly halted.

[Brian H]

"I think the CPU is briefly halted."
Okay, that's a fair assessment. I meant to say that it doesn't require the user halting the uC. A typical load/debug session definitely involves halting the uC for a period, just not because the user said "stop."

[ARaid.1]

I thnik the first thing keeping politeness ant courtesy to anyone of forum.

If you not agree, there is not need to address your opinion about my words (thank you at least that is not about me!)

The second, I'm trying help speaking for myself not pretending to objective truth.

In my case i almost never faced with this issue using plenty of my ST-Link (ST-Link V2, ST-Link V3Set, including Waveshare and even diy). I see this bug mostly using J-Link's (Two Flasher's last time, Ill try to test also Jlink Base)

Well, if I wrong about ST-Link, I apologize!

> Any ST-Link never has "continue to execute" issue when debugging.

"Continue to execute"? What are you talking about? Topic is set to: «Jumping to random file after pressing Run button»

> Any STM32CUBE project include many .C files. How you you make single ".C" file for it?

Everything that I wrote comes from the fact that the support ticket was closed, probably because the developers could not find and confirm this bug. That is why I wrote conditions for how to find and eliminate this bug. In order to observe bug, CPU must constantly execute code in various files (including HAL code).

Now look where the main loop is in most of the simplest demo projects that will be probably created or taken by developer to find this bug. This is addressed to developers and greatly increases the chance to finding bug, it will appear almost constantly.

[ARaid.1]

1. Its not "completely erroneous". I am probably mistaken in only one thing - the bug also present using ST-link's, which is not in my case.
2. We probably does not understand each other. Do you think random file opened by IDE due to bug in Eclipse file/project management ? I think no, the file opened because core executes code before cpu reset starting execution under debug. Debugger follows PC, opening file it's currently in. My point is not halt/reset. My point is code execution before entering debug, this is the cause.
3. I have read that ticket closed and I know that this bug is not fixed for years. So I start to think developers can't catch this bug. Now imagine what he/she to do in order to find bug. Her/his first attempt will be to create a test project. This will be a project with an empty while() loop in main.c, already opened in IDE. So, what is next? You can run this project 20 times and never run into a bug. Because startup code (found in other files) runs very fast and because cpu core will mostly run in main.c. which is already usually opened in the IDE. But we need to increase the probability. How to do it for a developer? It is necessary that the cpu core executes (in loop) code spread in different files before being reset when entering the debug. That is what I wrote above.

[PHolt.1]

It is possible for someone to almost never see this problem if the CPU spends 99% of its time in one .c file (say main.c) and 1% in other .c files.

The reason I posted above.

So on some trivial project, 1 file, it will not be seen. On a real project, say 20 files, loads of RTOS tasks spread across different files, it will be seen a lot.

[qua]

Even if you only have one file, it will jump to a random position in that file. That is also very annoying.

[HTD]

In my practice - the opening of files happens also when I just run the code using the "Run" option, without debugging. But I'm not sure if it's just not another kind of "silent" debug. When in debug mode, the files are opened twice. Once when the application starts, and then when the debug session is terminated. That would confirm my guess that the "Run" option is just another kind of debug - because it opens 2 random files.

[benany]

Same here. Please fix this issue ASAP!

[PHolt.1]

" "MCU GCC Compiler" → "Includes" to ensure that the correct source file is set as the main file."

No such path.

There is Include Paths but no setting for .c

 

"make sure that the "Main" tab has the correct main file specified."

There is only the .elf specified and if it wasn't then nothing would run

"Clean and rebuild your project: Sometimes, inconsistencies can occur during the build process, which may lead to unexpected behavior."

Yeah, that one is well known!

"Update STM32CubeIDE: Ensure that you are using the latest version of STM32CubeIDE. Updates often include bug fixes and improvements that can resolve issues like the one you are experiencing."

That has no effect. No visible fixes of any bugs for last 2 years or so.

"Seek help from the STM32CubeIDE community: If the problem persists, you can visit the STM32CubeIDE support forums or the STMicroelectronics community forums to seek assistance from other users or the development team. They may have encountered similar issues or have additional insights on how to resolve them.

That one is from chatgpt.

Actually maybe the whole post is from chatgpt.