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.

[kshoy.1]

Unfortunately either ST does not read this thread or they ignore it.

I did open a ticket a while ago ( 00173614), but apparently there are too few requests there - after a while ST confirmed the issue and ... closed the ticket, as they "cannot do much about it" and suggested that "The alternative is always to use other, paid IDEs." :). This kind of customer treatment appears a bit strange to me, though. I also cannot accept a closure of an unresolved ticket, but I can't find any contact to escalate this type of customer service.

Maybe if other affected users would raise a ticket, they might react more.

[Brian H]

To be fair, ST doesn't make Eclipse, and I suspect this is a problem within Eclipse. They truly may not be able to do anything about it. At that point, we all have the opportunity to download the Eclipse source code and try to fix it ourselves.

[kshoy.1]

Possibly fair and good point... Unfortunately I'm too weak programmer to dare that, but I believe an attempt to debug Eclipse would only make sense, if the behavior is reproducible with clean Eclipse installation. Is it possible to have a relevant test case with Eclipse?

[PHolt.1]

That's an atrocious response from ST, to tell you to pay money when their own IDE has such a bug.

It's still there in v12 too. Exists only in Debug mode, AFAICT.

That link is dead BTW. Maybe they deleted it.

[PHolt.1]

Just tested it with 12.1 which came out today.

In Debug mode I can't immediately reproduce the opening of spurious files.

Well, Cube always opens the startupxxx.s file. Why? No bloody idea but it briefly stops on the first code line.

Then, Cube always opens whichever file contains the main() function. This breakpoint was configurable in versions before about 9 but I have not been able to find it since and it looks like they removed the option.

Other files, right now, I can't make it do it.

[NRoth.3]

Just tested also with 12.1 after your post...

Exactely the same like before. No change

[eos1d3]

The latest version is 1.12.1, not 12.1.

Just test this on MacOS, SAME problem! :pouting_face:

PS: Are all ST employees hiding and pretend the problem does not exist?

[PHolt.1]

Yeah, OK, doing it now here too.

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.

[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

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

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