Is ST Cube IDE a piece of buggy crap?

[peter-h]

I've just spent some hours trying to find out why code which compiled last night doesn't compile today.

Nothing was touched - also not touched according to file date stamps (as seen in windows explorer).

But I appreciate that if you leave any editor on-screen with a file open, a slip of the finger on a keyboard can "do stuff". But this should not change a file if you don't then save it.

The error was an obscure one, which I could not get my head round (not my code), to do with a typedef being "external" in a .h file (no idea why not include the .h file containing the real one, or why the typedef was not being exported from the .h in which it was). I don't really understand the intricacies of this stuff so I avoid this sort of thing in my own code. But it compiled the day before! This suggests that files can be changed and don't get recompiled after the change. Well, many times doing a Clean Project and then Build Project does mysteriously fix stuff.

Exiting Cube asked if I want to save a couple of files, suggesting they were edited, and I unchecked both and exited the program. I also found that some of the open files could not be closed by clicking on the cross (obviously this is a bug).

Also I lost the default window configuration. Took me a while to work out how to get it back.

I have backups almost daily of the whole project directory, to a network drive, but need to make sure I really do them daily

[ataradov]

I'll tell you a secret - any manufacturer provided tools and frameworks are crap. They are a cost center, they don't directly generate money, they cost money. So they are maintained to the level that is mostly acceptable, but no more. There is no real incentive to make them excellent, it will not result in more sales.

[SiliconWizard]

I'll tell you a secret - any manufacturer provided tools and frameworks are crap. They are a cost center, they don't directly generate money, they cost money. So they are maintained to the level that is mostly acceptable, but no more. There is no real incentive to make them excellent, it will not result in more sales.

Yes, that is true. Especially since, as you can read here and elsewhere, many professionals actually use other tools than the vendor provided ones. Vendors know this, and know that customers buying the most parts usually don't care about the crap IDEs and code generators they provide.

So, for the OP, do as you wish of course, but if I were you, I would take this mishap as an opportunity to switch to better tools and say goodbye to ST Cube forever. It will take you some time and effort, but will be worth it.

[thm_w]

CubeIDE came from a commercial product, Atollic TrueSTUDIO. So its not really the same as in house developed IDEs.
But you are free to use many other IDEs available for STM32.

Are you using version control? Then you will actually know what might have changed instead of guessing.

[peter-h]

What would you recommend?

Incidentally I see Cube (currently 1.6.1) is now at 1.7 but I don't want any ST libs getting changed. Is there a way to just update the IDE application? It may update the code generation stuff but that should affect only future usage (and anyway that aspect gets used only to generate snippets which then get moved elsewhere).

I used "make" for many years and it was great, but this thing gives you single stepping. I guess the answer will be that e.g. a Segger debugger comes with software which does that, but from what I have seen of that software, it looked like something from CP/M 2.2 ported to win3.1

Not using version control; however my drift here is that files can get changed in the IDE editor without the IDE being aware of it, and apparently without their time stamps getting changed (yes I know that is hard to believe but I have a video editor - Vegas Pro v16 - which does exactly that!).

Oh and the funniest bit is that during a build a lot of the scrolling text is in white, so you can't see it. Reproduced across 3 machines, some win7-64 and one win10. But if you run it over RDP (remote desktop) you see all the text just fine It's actually not trivial to write an app which produces invisible text, using the windows GUI functions, but such that when it is later channeled via RDP it is visible.

[dietert1]

There is little to learn from a failure report like this, since there are so many reasons for something to fail.

So let me report that i have been using a fairly recent version of STM32 cube for development and with good results, BUT: Use it to help you define pinout and initialize peripherals. For your own mental health use a serious IDE like IAR for further development. As long as i work inside the user code sections defined by Cube, that works very well and i can even modify/update the hardware setup without losing any code. Recent versions of  STM32 libraries are fairly complete and absolutely useful.

Regards, Dieter

[peter-h]

Some possible things that can cause problems are, of course:
* time stamp differences that do / do not get updated / processed appropriately
* pre-compiled headers that aren't updated based upon their dependencies so they don't sync with the actual inputs
* dependencies that aren't reflected properly in the build so stale objects or generated inputs are built into the output
* "clean" or "rebuild" rules aren't deleting / regenerating / rebuilding from the base configuration

But, surely, all of those are bugs? An "IDE" isn't supposed to be doing that.

If one was editing files outside the IDE, then maybe, although I would still expect an IDE to check the stamps when you trigger a build, as a robust way to do it.

[Bud]

I do not think this type of failure is specific to Cube IDE. I have seen exact same behaviour with MS Visual Studio. Compiles today, will not tomorrow. In fact, pretty much every single MS VS project (created by someone else) did not compile from the first try on my computer on the same VS version. The problem therefore is somewhere deeper.

[Sal Ammoniac]

I used "make" for many years and it was great, but this thing gives you single stepping. I guess the answer will be that e.g. a Segger debugger comes with software which does that, but from what I have seen of that software, it looked like something from CP/M 2.2 ported to win3.1

Are you referring to Ozone here? If so, just learn to live with what it looks like. It's not that bad. Besides, it's a very robust debugger and much more robust than the typical debugger built into vendor Eclipse implementations.

[DavidAlfa]

I've got problems like that few times. Almost always, I made something and forgot it or simply didn't notice. My advice is to install and use eGit. Any single difference will be detected, saving you a lot of hassle when things go wrong.
It could be simple as forgetting to add an include path or a define in debug or release configs, then you switch the build type and bang!

If it isn't a delicate thing, I can have a look at it. I've fought a lot of times with this ide!

An advice: Never move files using the ide itself. I had some really bad times, where it showed a "resource busy" error. And the file I moved no longer existed anywhere!
I still remember a file where I added tons of defines for registers and bits to use a IO expander. Moved it to the working directory... gone! I would have burned down the ST headquarters!

[thm_w]

What would you recommend?

Incidentally I see Cube (currently 1.6.1) is now at 1.7 but I don't want any ST libs getting changed. Is there a way to just update the IDE application? It may update the code generation stuff but that should affect only future usage (and anyway that aspect gets used only to generate snippets which then get moved elsewhere).
...

I'm not going to recommend my choice over another, I suggest people just try the options that are out there and see what suits them. Personally I use Visualgdb, since I'm a VS fan and not a pro programmer and it does everything for me. But there is VSC/platformIO, and the other options mentioned here.

Don't know about just updating the IDE, I would test it in a VM.

If you are not using version control, you are just flying blind IMO. OK for hobby, not good for work.

[DavidAlfa]

Sure, you can select the library version in the cubeMx project settings.

[MR]

A small hint, try different versions. Some versions have issues some do not.

Keep backups of old installers and BSP (board support packages!)

[Siwastaja]

Just don't use it? Even if it were less buggy and crappy, it won't likely exist in 2-3 years from now. Especially in STM32, the variety in "trend IDE of the year" has been massive. Everybody uses a different one, and the "preferred" tools change all the time. This causes unnecessary learning cycles.

Just learn the underlying GNU tools, pick a code editor you like, and you are good to go for any ARM microcontroller from any vendor, and good for decade(s) in the future.

[peter-h]

A lot of people seem to be doing that, and historically everybody did, but then you don't get integrated debugging.

Interesting comment about precompiled headers. Does this system use those? It would explain the last problem I had, which was a .h file which could not possibly have worked for the .c file in which in was being #included, and was last edited months ago. However, I did do a Clean Project many times during that time; doesn't that delete all compiled objects?

[JOEBOBSICLE]

You can get vscode to debug for any cortex m microcontroller. I don't see the point in using vendor specific IDEs.

[newbrain]

I'm not going to recommend my choice over another, I suggest people just try the options that are out there and see what suits them. Personally I use Visualgdb, since I'm a VS fan and not a pro programmer and it does everything for me. But there is VSC/platformIO, and the other options mentioned here.

Don't know about just updating the IDE, I would test it in a VM.

If you are not using version control, you are just flying blind IMO. OK for hobby, not good for work.

Quoted for truth on both counts.

Visual GDB plus VS Community Edition is a very practical and powerful combo: one of the best IDE around (YMMV) and solid support for every Arm MCU under the sun (a bit of an exaggeration...) plus some the usual non-Arm ones. It's a paid product, though with reasonable prices.
It has served me well for all my hobby stuff (not doing embedded code at work) and can easily import CubeMX projects.

Using a version control system is in my view an absolute requirement even for hobby projects. Good IDEs usually include a good integration of git (Eclipse and derived are the usual pain in the neck, making everything confusing, slow, and half working).

Just don't use it? Even if it were less buggy and crappy, it won't likely exist in 2-3 years from now. Especially in STM32, the variety in "trend IDE of the year" has been massive. Everybody uses a different one, and the "preferred" tools change all the time. This causes unnecessary learning cycles.

Just learn the underlying GNU tools, pick a code editor you like, and you are good to go for any ARM microcontroller from any vendor, and good for decade(s) in the future.

And that is the equally good, if not better, alternative route.

Having a project I share with a friend and not being able to withstand MCUxpresso (another crappy Eclipse adaptation*), I convinced him to use VS Code (he's on Mac and Windows, I'm on Linux and Windows) and set everything up for him (Cmake files, compilation tasks and debug config).

The (~200 kLOC) project now compiles and link from clean in 1.8 s (Windows) from inside VS Code (Cmake/ninja + clang, not gnu but FOSS) instead of 25 (MCUxpresso = make +anoe-gcc), and we have no host platform dependency (apart some environment variable difference).

Many other smaller projects I set up in a similar way, and the independence of the build system from the IDE/editor, the VCS, and the host platform  allows me to switch them at will, if the need (or fancy) arises.

A lot of people seem to be doing that, and historically everybody did, but then you don't get integrated debugging.

Interesting comment about precompiled headers. Does this system use those? It would explain the last problem I had, which was a .h file which could

With VS Code you have very good integrated debugging, I use it all the time, even with FreeRTOS and Azure RTOS (which I contributed to pyocd).

I think arm-none-eabi-gcc does not use precompiled headers, but if the IDE gets confused then it's its fault (and it's crap - but talking about Eclipse that's a tautology).

*MCUxpresso grievance notes on request, but I would have to clean up the language, not suitable to civilized company.

[DavidAlfa]

Also, always backup your project folder before updading, or use git from the beginning.
It's the 3rd time that the ****  ide wipes my Src folder after updating.
The first time I was not happy because I never expected that, but since then I started using git.
Now I just don't care, the worst situation would require going to git staging window and restoring the files from HEAD 

[peter-h]

Visual GDB looks interesting. I've emailed them with some questions re e.g. how easy is it to migrate from Cube. Am I right it does not do the code generation which ST Cube IDE does? This is useful at times to get started, but one could just have a Cube install for that, use it for the one function, and then exit.

It seems to require the MS Visual Studio to be installed.

One particularly irritating feature of Cube is that the .elf file is periodically impossible to delete/overwrite - because the ST debugger locks it! One has to close Cube and delete it from within Windows.

Another is the difficulty of installing a copy of a project on another PC. One can't just "import" it. The process involves (I posted this before) copying over the Project directory as well as the Cube workspace. Here are my notes

INSTALLING THE KDE PROJECT ON ANOTHER PC

Install Cube IDE and upgrade to v1.6.1. Exit Cube.
Copy over the \kde420\project1 directory.
Copy over the \st\.....\configuration directory (overwrite one in the new install).
Start Cube. Should just work.

Otherwise, STM32 CubeIDE will refuse to import when the project name is referenced in another project that already exists in your workspace, or referenced in another project that you're trying to import with the new one. This happens whenever you make a copy of an existing project and rename the project folder to say v2.

Another solution (not tested) is:

Manually edit (e.g. find and replace with NotePad++) the old project name references with the new project name within these files:
.cproject
.mxproject
.project
[projectname].ioc

Also, the .ioc file needs renaming to the new project name.

This is a POS. Lots of people will want to copy a project onto say a laptop. Currently I solve this by running Cube over RDP (remote desktop, over a VPN, to the location where I do most of the work) which works on a fast connection.

[newbrain]

Visual GDB looks interesting. I've emailed them with some questions re e.g. how easy is it to migrate from Cube. Am I right it does not do the code generation which ST Cube IDE does? This is useful at times to get started, but one could just have a Cube install for that, use it for the one function, and then exit.

It seems to require the MS Visual Studio to be installed.

Some answers:
No, VGDB does not do code generation.
I always used it with the stand-alone CubeMX (not the one integrated in ST CubeMX IDE), in that case it's as easy as generating the project as GPDSC.
The code generation is performed by CubeMX as usual, and the import procedure is quite simple and reliable.

Yes, VGDB is a plug-in for Microsoft Visual Studio, so you need some version of VS installed.

For home/hobby use, VS Community Edition is more than powerful enough (very little is missing from the Pro/Enterprise versions), and with very few limitation (I think you can also sell your code, but I should re-check the license - checked).
OTOH, in a work environment, VS CE can be (simplifying) used only for Open Source or educational purposes - but have a lawyer read the license to make sure your use case is included.

While debugging inside Eclipse based IDEs often fails for me with no understandable reason, I very seldom had problems with VGDB, as long as the debugger - MCU combo is supported (and you can go full manual if needed).

As for your woes with moving projects, my only hint is to ditch Eclipse based crap, though I must admit MCUxpresso (the crap from NXP) got it quite right in this respect and I had no issue importing and using a project in a git repo in Windows, Linux and Mac with no change - but as I said above, I then moved everything to Cmake/ninja/clang + VS Code.
Only renaming the folder is bound to fail though, and also renaming the project inside the IDE has some drawbacks.

Probably using a different Workbench per project might be easier - I find the VS way (Solutions as a containers for projects) much superior.

[Siwastaja]

Code generation is like crystal meth. Just say no to code generation. You don't need it. Open the reference manual and write your own code. Writing out the registers is only marginally slower than clicking the same options through point&click interface, and minuscule part of total development time. You are a programmer, you should be familiar with writing code.

Simple peripherals are typically 5-10 lines of code. No need to generate it.

More complex systems like TCP/IP stack over Ethernet, or USB, or filesystems, then you use libraries, this isn't code generation either.

[peter-h]

Sure; I have always done stuff that way. But now I am more or less taking over a project which was done with Cube code generation to a large degree.

It seems to be working ok. There were lots of bugs in the USB and Ethernet libraries, which took perhaps a year (of part time work) to fix.

I have never personally used the code generator, or the clock configurator, and don't plan to.

All great info - thank you!

Cube is weird in so many ways. Right now I am stepping through a project. Each time I do a new build, and before it hits the first breakpoint, it hits some random line of code in some randomly chosen .c file, and then continues to the first breakpoint, but that randomly opened file stays open, so if you do 10 builds, you end up with 10 random .c files opened in the editor, which you have no interest in It's only just started doing that. But the bit which gets the prize is the white font in the compiler console output, which magically is fully visible when you run Cube over a remote desktop connection

[esepecesito]

My 2 cents:
The tool is buggy, no question. I would not say it is a total piece of s**t either. Has some problems, but for hobby, if you want to start a little bit faster, without having to type 5000 lines, is ok.
Not all tools by vendors are crap. Codewarrior was very good. Have used both the free and payed version professionally, and I had good experience. At least with (relatively) small microcontrollers.
I used CUBE for a couple of projects, the integration was FreeRTOS and filesystems was just few clicks, all the work done. I would use it anytime I had a similar project at hand.
Like any other tool, serves some purposes, depending what you want may work better or worst.

[Siwastaja]

My 2 cents:
The tool is buggy, no question. I would not say it is a total piece of s**t either. Has some problems, but for hobby, if you want to start a little bit faster, without having to type 5000 lines, is ok.

But you don't need to type 5000 lines! Beginners using Cube and other shitty code generators is the problem because these tools generate hundreds of lines of code to do something that really requires five. So now you think it's doing great job saving the hassle, while it's only creating a problem and then "solving" it.

An LED blinker is approx. 10 lines of code, bare metal (ignoring startup code and interrupt vector table), in one C file.

A UART "hello world" is 10 lines more.

[ataradov]

But you don't need to type 5000 lines! Beginners using Cube and other shitty code generators is the problem because these tools generate hundreds of lines of code to do something that really requires five.

^^^^ THIS.

People look at the code generated by the frameworks and think that this is the actual amount of code needed.

In reality UART initialization though the registers takes fewer lines than filling out initialization structure/parameters for the library call. So you have not done anything useful yet and have more code than an actual solution.