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]

Nice triage work! That makes a sort of sense; at least there's a connection between running code and the file that gets open; unfortunately, it's a moment of execution that we don't care about.
Hopefully, someone at ST will see your useful info and dig more into it. Others seem to have evidence that invalidates my hypothesis of it being an Eclipse bug.

[yuyfc.1]

Same issue 1.12.0

[HTD]

Oh, it's an old thread, but to make it perfectly clear, it doesn't halt like on breakpoint. It just opens the file, the debug session goes on. Without a debug session, when just `Run` option is used - it's the same. The app starts normally, but some files (usually startup / boot code) is opened. For STM32H7 project it's usually the startup file (so it's not random - it's really the first thing that is executed), then some system drivers and OS files, like usb drivers, diskio, that sort of thing. It's almost never the user code, however, it happened too - my application file was opened without a reason once or two.

So I'd take strong educated guess, that the file open is never unrelated to the project, it's always a file whose content was executed.

The problem is following: why does it open? When there is a breakpoint in a file AND when I'm in the `Debug` mode - it SHOULD open. Then and ONLY then. Here both conditions are false. There is no breakpoint in the startup file and I'm not in the debug mode. The file opens.

Another interesting detail: the spurious files are also opened on TERMINATING the debug session. I press stop, then a file opens. Let's say it takes a good hour from my work day just to close those files over and over again and then recalling what I was doing before and what was the file I was working on a while ago.

[PHolt.1]

Guys, this has already been documented exactly. The problem with this dumb forum package is that it doesn't show posts in chronological order so nobody can find anything. I also cannot find a way to get a link to a post, so I will repeat my post (from a week or two ago) below:

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.

[Piranha]

Yes, the SalesForce FailForce parody of forum is an absolute junk, but in this case your original post is literally two posts up! Therefore by making a duplicate you are making the usability of this junk even worse. Also duplicates are forbidden.

Your "skill" of NOT seeing and finding things is phenomenal...

[PHolt.1]

And your reputation for rudeness is legendary on the internet, Piranha. The general consensus is that you enjoy feeding on the remains of people less clever than you.

I could say more but I don't want to p**ss you off totally, because sometimes, just very rarely, maybe in 1% of your posts, you actually post something which represents a complete fix for something which a normal person can make use of.

[ARaid.1]

To support team / testers.

How to reproduce.

1. This bug manifests only with Segger J-LINK debug probes, not ST-Link probes. Bug not exists with ST-Links.
2. When you launch debug, you need to put CPU in halt/reset state. But it is not, CPU continue to execute code from project files and debugger just displayed where it has been before putting it to halt on first breakpoint. It might be tricky to find this place in IDE/Eclipse Plugin code by sight/code review. This might be in very short time. So I suggest you to catch bug purely experimentally, for example placing two breakpoints (I mean breakpoints in IDE java code or in some startup scripts), making problem area narrower with each iteration.
3. You can't reproduce this bug with typical one-c-file (main.c) demo/example project. You need project in which CPU executes forever-loop spreaded over different files. When your execution loop is in the same file (main.c) you have not chance to catch this bug, because this main.c file is already opened and CPU executes loop exactly right in this (same) file. People often reported startup*.s file, but chance to catch CPU in startup code is small but not zero (because startup code not looped).

Happy coding, guys and girls. Hopefully this bug will be fixed in the next release!

[qua]

Happens with ST Link V3 for me.​

[eos1d3]

@ARaid.1​ Are you trying your best to insult all ST developers here? You are just talking nonsense.

1. All official and non-official ST-Link 2.1 and ST-link 3 are having the same issue. And macOS and Windows are having the same issue too.
2. Any ST-Link never has "continue to execute" issue when debugging.
3. Any STM32CUBE project include many .C files. How you you make single ".C" file for it?

This guy is totally bullshxt here. Are you another ST employee trying to save the face of ST? :face_with_tears_of_joy:

[PHolt.1]

As I wrote above, the spurious files being opened are ones containing code that was running when the debugger did a Reset.

So if your project consists of just one code file (say main.c) then you won't see this problem.

But almost nobody has a project in a single .c file. Well, you could do it but it would be very messy.