Is ST Cube IDE a piece of buggy crap?

[peter-h]

Cube has been updated to 1.12.0.

The tool version has not changed - at least not automatically, which is good. It says in the release note that it is "enabled"; no idea what that means. The binary is identical byte for byte.

Errata
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.12.0
does not list any of the biggest bugs e.g. the random file opening when debugging.

In the release note is this



which I sort of understand (it appears to do the same thing as zeroing BSS does to global statics) but the path above does not exist.

[dkonigs]

Errata
https://wiki.st.com/stm32mcu/wiki/STM32CubeIDE:STM32CubeIDE_errata_1.12.0
does not list any of the biggest bugs e.g. the random file opening when debugging.

With the random-file-open bug, I can't help but wonder if they're somehow oblivious to that bug even being there at all.

[Chat GPT (2)]

It sounds like you've encountered a frustrating and confusing situation. In general, it's always a good idea to save your work frequently, even if you haven't made any changes recently. This can help prevent accidental changes from going unnoticed and potentially causing problems down the line.

Regarding the issue with the typedef, it's possible that the code was relying on a certain order of includes or other dependencies that changed without your knowledge. It's also possible that the code was relying on some behavior or functionality that has changed in a new version of the compiler or other toolchain that you're using.

As for the files that couldn't be closed and the loss of your default window configuration, it's hard to say what might have caused those issues. It's possible that there was some sort of bug or glitch in the software you were using, or that something else on your system was interfering with it.

In any case, it's always a good idea to have backups of your work, as you mentioned. It's also a good idea to try to track down the root cause of any issues you encounter, as this can help you avoid similar problems in the future. If you're not sure how to do this, it might be worth reaching out to the developer community for the software you're using, or seeking out resources such as documentation or tutorials to help you better understand the underlying concepts involved.

[SiliconWizard]

Nice nickname.

[dietert1]

The text sounds like chat gpt, doesn't it? Who knows..

Regards, Dieter

[peter-h]

Probably a spammer. The language is out of chatgpt. Totally bland. Sickly-sweet and nice and positive.

[Simon]

Uh, I thought changing the password would do it. I renamed it chat GPT, better than going around deleting every post.

[beenosam]

Probably a spammer. The language is out of chatgpt. Totally bland. Sickly-sweet and nice and positive.

Seems like good trolling for sure lol

[Kjelt]

If the AI got out it will start contributing to forums 

[NorthGuy]

If the AI got out it will start contributing to forums 

... and ruling the world

[peter-h]

So far, I see no bug fixes on v12 other than an apparent reduction of the random file opening issue during debug.

[peter-h]

They also need to fix the Search function.

A lot of the time it simply doesn't find some variable name. Sometimes the "free text" search does find it. Other times you have to use some external file search which (obviously) works.

[paulca]

I believe the lack of "Find references" working is partly the way the indexing is setup and partly, being honest, the code.  The HAL code for example has many a dead end regarding references.  Anonymous structs are a good example.  Like a lot of the ones in HAL that were clearly written in C++ and ported to C by a machine.

[peter-h]

The Find Refs is even worse than Search

So I wasn't going to mention it.

What do you think is wrong with the indexing?

[paulca]

What do you think is wrong with the indexing?

I haven't bothered to look.  I probably do exactly as you do.

CTRL+Click... nope.
<grumble>
Find References in workspace...  nope.
<growl>
File search...  yep!
<tut>

Things that will probably make it difficult for the indexer.
* the custom project layout
* the dynamic includes/cpp files
* the autogenerated code
* anonymous structs and void pointers.
* The sheer volume and complexity of the IFDEF and MACRO soup.

EDIT:
Even in Java land, eclipse's home territory it can run out of steam on complex projects and simply stop resolving references.  Double nested, anonymous factorn patterns buried in a double nested visitor pattern certainly did.  To dry run that stuff I used the debugged and stepped into the code to find out what actually got run as Eclipse had no idea either.

[peter-h]

Here you go. And there is nothing difficult about SysTick_Handler. The one in yellow, the #define, is findable only with that "quick search". The last (3rd) image should be the 1st but there is no way to edit a post to do that.

[Kjelt]

I am getting a bit tired of everything that is not good or ok.
It is free man,  if you find it to be such crap why not buy from Keil or IAR and start finding out that also there life ain't perfect.

[nctnico]

They also need to fix the Search function.

A lot of the time it simply doesn't find some variable name. Sometimes the "free text" search does find it. Other times you have to use some external file search which (obviously) works.

I always use 'search text'. Make sure to give the indexer enough memory to work with and enable indexing on large files as well. The default maximum is a couple of thousand lines. I use Eclipse's indexer on the Linux kernel and it works well once the indexer is configured. But be aware that the first index of a Linux kernel takes a good part of an hour.

[rsjsouza]

If there is something that I like about Eclipse is its editor and search capabilities. In the early days I was also very confused with the better search (Ctrl-H) but over time I got to learn how it works with the code, its dependencies and #ifdefs. Pretty good is also the perspective context switch, which I hated at the beginning but I was so used to have all the code dev and debug windows cramped on the same screen that I didn't realize how liberating it was to not have to resize and move stuff around between these tasks.  (Project management, build console, disassembly, memory, registers, stdout console, breakpoints, watchpoints, etc.)

YMMV, but it is indeed free. 😁

[peter-h]

The default maximum is a couple of thousand lines

Make sure to give the indexer enough memory

Interesting. Where is the config for this?

and start finding out that also there life ain't perfect.

Nobody said it was

What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?

[Kjelt]

What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?

It is not their core business. Only recently they started investing in this.
You can better ask yourself why this company does not fix known issues in their microcontroller peripherals which is their core business 

And yes big companies use the sorts like IAR because they have better support if the s*it hits the fan, that is why they pay, service insurance.

[paulca]

Interesting. Where is the config for this?

-Xms256m
-Xmx1024m

C:\ST\STM32CubeIDE_1.10.1\STM32CubeIDE\stm32cubeide.ini

These are quite small.  Note, plugins and extras can use additional memory if they use additional processes.

[paulca]

What is probably most puzzling is that a $14BN company can't fix this - a primary tool for generating code for its chips. Or maybe they feel that only hobby programmers use it?

I have used Eclipse for 20+ years.  I have also used Eclipse CDT since about 2012.  The later has always been a bit rough around the edges.  Back in 2012 it was far worse, with virtual zero build integration and only useful as an indexed editor.. and the indexer had issues then.

It is a little odd that STM picked eclipse.  However, the options you have today to create an IDE without undergoing the arduious decade length product project of making it from scratch.... are:

Eclipse
VSCode
JetBrains

Given the nature and scale of the business, options 1 will be the only "Free" entry.  Microsoft will doubtless charge handsomely for the consultancy and any licensing required beyond the base VSCode.  JetBrains are also going to charge handsomely and probably extended that charge to the user for the "real feature set".

Eclipse CDT is 90% there, so they started there.  They could also integrate their MX configurator/geneerator into it.

The debugging system is all "off the shelf", just like 99% of the build chain.

I honestly think the code goes a few steps too deep into nested IFDEF and MACRO chains and the indexer loses track in many locations.  As I said, my personal most common view of this is the dead ends caused by "Anonymous struct"....

[paulca]

The random files opening during Run and Debug and the whole process there in needs to be thrown in the bin and rewritten.  IMHO.

It is just too riddled with bugs.  You can see it struggle each and every time with timing between the programmer the device and the whole process seems fragile and hanging together.

The issue with the files opening is reported by STM to be an issue with the connection to GDBServer.  Something about a race condition between the ARM debug core signalling and the GDB.  When they connect the GDB to the ARM debug it immediately starts emitting signals/symbols to Eclipse.  Eclipse then opens those files as the debugger has fired an event for a line in them.

It sounds plausible, but my question is... how come every other language virtual machine or debug protocol can wait and synchronise with GDB without all these issues.

In terms of Java and I believe C elf exe's GDB can work in tandem with the language runtime to "Wait for debugger" where it will automatically pause on your ENTRY_POINT and wait for everything to sync up first.

The reason I think STM have issues relating to this is that their process of "Connect under reset" is itself broken.  Watch the logs.  It restarts the device at least twice, not once.  All while saying "Waiting on debugger...."....  "Waiting on debugger..."....   all while random ASM files are opening.  When you device under test is in communications with other devices this alone destroys your test harness if you forget it happens.  You test harness sees the MCU reset, starts its test and the thing promptly resets again.

It's got too many issues.  What it needs is STM to take their most keen mid level engineer and lock him in a room, give him whatever he needs and let him have hte full flexibility to come up with a solution that works, void from legacy or corporate BS.

[nctnico]

That is why you shouldn't use a debugger to do behavioural verification. Use a serial port with text output for that (and commands to set parameters). Debugging is only useful to find bugs that are not simple to find otherwise (like pointers going wrong or software getting stuck somewhere).