Is ST Cube IDE a piece of buggy crap?

[peter-h]

Yes; I've been using that, though usually I disable it because I move debuggers around.

Right now I am trying to rebuild my project not in the current Debug mode but in Release mode, and it fails immediately. The paths the the various files are wrong. Is there a simple way to copy the path(s)
 from Debug to Release?

[DavidAlfa]

Basic mistake , remember to select [all configurations] next time. Otherwise you will need to set up them separately!
Not a big issue, you can select multiple paths by holding down the control key, adding all folders in a single operation.

[peter-h]

Thanks

What I have now looks like this



and there is no obvious way to copy all the many lines from the Debug mode to the Release mode, and do this for a) asm b) compiler c) linker. Also one can add or delete only 1 line at a time in this screen.

The whole thing looks auto generated and I wonder if it is generated simply by making Release the active profile and running a project indexing operation?

[nctnico]

Create a new configuration based on an existing one in order to copy all the settings.

[peter-h]

I see nothing obviously applicable under File / New, but under the project itself (which must be the right place) I see some possible options, but none are called "configuration"



The project normally built is a "STM32 Cortex" one, rather than one of the numerous "C/C++" options found in Cube, none of which seem to support a config for an STLINK debugger anyway.

I have no .ioc file anywhere, and there is stuff online suggesting that that option doesn't work in ST Cube anyway.

[newbrain]

I see nothing obviously applicable under File / New, but under the project itself (which must be the right place) I see some possible options, but none are called "configuration"

Eclipse...death by a thousand papercuts.

You'll find what you need under Project->Build Configurations->Manage (also in the menu you are looking at), see picture.
There one can create a new configuration copying from an existing one.

[peter-h]

Thank you; that works.

Quite a bit of fiddling around afterwards to make it understand that the project I actually want built is the one set "Active"

There are two places where it needs to be set Active, if you want this button to actually build the one set Active



I realise there are multiple levels of indirection here, with global settings and project settings, but one would surely expect this to do what it says



They key seems to be to have Use Active here



The other thing which caught me is that the Build Analyser window shows the data for the last build, which is not the same thing as what you are sending to the debugger. This is bloody confusing. The only time the build is updated is when you edit a source file (etc).

[DavidAlfa]

The build analyzer isn't always updated as you build the project.
When that happens, clicking somewhere in the project files will update it. Or in most cases.

[peter-h]

Yes that's true. Hilarious!

Thank you.

How can anybody release something which is so obviously broken?

Another bug:

In the c:\product\project1\release and c:\product\project1\debug directories I have batch files for crc appending. These batch files vanish on each build. No kidding. They just vanish. If I build Debug, the debug-crc.bat vanishes. If I build Release, the release-crc.bat vanishes. This f-ing program must be doing del *.* on the build directory.

So I have to put anything I want to keep elsewhere. Well, I can see rm -rf * appearing in the console, so no wonder...

Usually you also get



because the debugger has locked the file.

[nctnico]

Everything gets deleted because you tell it to rebuild everything. The build directories are always temporary for any IDE. Scripts and stuff go into a scripts directory in the root of your project.
Also don't forget to set the indexer for the C language to use the active build configuration.

[peter-h]

I did notice that sometimes, after I switch builds, it does a re-index. Is this a config item? I looked everywhere.

BTW, re that issue where Cube tends to fail to delete the .elf file because it is locked by the debugger, which it often is, it is the rm command which fails, presumably because it has insufficient privileges. At the end of the the build, Cube deletes that elf file ok by itself (usually; not always). I did explore solutions like Handle which can be run as a pre-build batch file to kill the process holding the elf file, but it is probably ok.

Found something else curious. This is the batch file I use for generating the CRC-appended .bin file

Code: [Select]

cd c:\kde420\project1\release
arm-none-eabi-objdump -h kde2020.elf > objdump.txt
if exist file.dat del file.dat
arm-none-eabi-objcopy -S --strip-all -R .bss -R .main_heap -R .ccmram -O binary kde2020.elf file.dat
c:\kde420\crcgen\addcrc file.dat 0xffffffff

Now look at how the 2nd line looks in the console:



Where has that "1" come from?

I don't think it is affecting the generation of the dump file. Of course > (and >> to append) can be used in "DOS" and win16/win32 command line batch files but maybe Cube is presenting some strange environment here. I googled around but found nothing.

[newbrain]

In cmd.exe (the basic/old Windows shell*) '1>' means (as in Unix shells) to redirect the standard output to the following file.
You can also use 2> to redirect standard error, (and <3 if you love your batch files  ).

As this batch is invoked as a post build action by the IDE, it's probably "rewritten" to be correctly executed.
Mysteries of Eclipse.

* The good shell is PowerShell, but cmd is faster to launch in many cases, and has been widely expanded with respect to the DOS times.
It is now almost respectable (arithmetic, string parsing, conditionals etc etc).

[harerod]

I posted a short list of what I would consider required reading before voicing an opinion about about the STM32 family and its infrastructure:
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779
Documentation for features that have no influence on the current design may be skipped. Finding those out may not be trivial.

[DavidAlfa]

The locked file is a minor bug that happens sometimes. Just restart the ide 

[harerod]

Quoting DavidAlfa from the GCC optimization thread:

Not that kind documentation. A proper guide/manual for the HAL.
You have a simple one, barely describing what each function does. But you still have to guess a lot of things.

I understand what you mean. However, your comment brings me to my biggest gripe about CubeIDE/"HAL": it suggests to beginners (anybody not familiar with this device family) that they can develop production quality code without working their way through the available documentation.

[peter-h]

"The locked file is a minor bug that happens sometimes. Just restart the ide"

You also have to terminate the debugger process in process explorer.

But actually this doesn't matter because while the "rm" command refuses to delete the .elf file (when cleaning up the Debug, Release or whatever directory) that is due to it having insufficient privileges. Cube itself has sufficient privileges to delete the file when it finishes compilation/linking. No idea what is going on.

"that they can develop production quality code without working their way through the available documentation"

I think the "truth" is somewhere in the middle. The code generator is useful for generating functions which do what you specified, more or less, and you are free to hack them around. This is much easier than reading the 2000 page RM, which is best used to resolve specific issues. This is one example (RM page 894)



I reckon you can test 1 and 2 at the same time because if both are appropriately set then all data has been sent out, and every "UART" I have ever used works like that (and usually you can just test the "all sent" bit only) and CS can be raised (after waiting for any pre-CS delay, with a non-optimisable inline-asm delay). But the RM doesn't say that. It says you have to test one and then test the other. So I copied the RM (last two lines):

Code: [Select]

    __HAL_SPI_ENABLE(hspi);
  }

    /* Transmit data in 8 Bit mode */

  // The need for this initial byte is unknown
    if ((hspi->Init.Mode == SPI_MODE_SLAVE) || (initial_TxXferCount == 0x01U))
    {
      *((__IO uint8_t *)&hspi->Instance->DR) = (*hspi->pTxBuffPtr);
      hspi->pTxBuffPtr++;
      hspi->TxXferCount--;
    }

    while (hspi->TxXferCount > 0U)
    {
      /* Wait until TXE flag is set before loading data */
      if (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE))
      {
        *((__IO uint8_t *)&hspi->Instance->DR) = (*hspi->pTxBuffPtr);
        hspi->pTxBuffPtr++;
        hspi->TxXferCount--;
      }
    }

    // Wait for last byte to get shifted out - needed before CS is raised!
    // Two tests done as per the RM text
    while (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_TXE)==1) {} // wait for tx buffer empty
    while (__HAL_SPI_GET_FLAG(hspi, SPI_FLAG_BSY)==0) {} // wait for tx shift reg empty

Also the HAL code doesn't disable the SPI. I don't see why it should... the clock stops when you stop stuffing bytes into the transmitter!

There are many discrepancies. And some of these are real, and can get exposed by compiler optimisation
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/200/

[DavidAlfa]

Quoting DavidAlfa from the GCC optimization thread:

Not that kind documentation. A proper guide/manual for the HAL.
You have a simple one, barely describing what each function does. But you still have to guess a lot of things.

I understand what you mean. However, your comment brings me to my biggest gripe about CubeIDE/"HAL": it suggests to beginners (anybody not familiar with this device family) that they can develop production quality code without working their way through the available documentation.

It's actually even harder,  on baremetal you must do everything yourself, but with an already made library, hah! First, decrypt how it works internally!
Something simple as using DMA UART. Does is say anywhere that you must enable UART interrupt also? Nope, then you'll find that nothing works.
Not that obvious, for example DMA SPI works perfectly without spi irq. I must admit I'm happy with HAL now. But the learning curve was not easy.

Thats' the point of the libraries, they do the hard work for you, but they also should be dwell ocumented, otherwise it's even worse.

[peter-h]

While on Cube IDE...

Is there anyone here familiar with Cube and Windows 7-64?

The system requirements (such as I can find for Cube MX) suggest win8.1 is the latest supported (presumably for Cube 1.7) which in practical terms (v8 was crap) means win10 only.

However, I originally set up v1.4 (current version c. Jan 2021) on win7-64, and that still installs fine. Been testing that in a VM. However, while I was able to auto update Cube to 1.6.1 and that still runs fine on the win7-64 machine, I cannot install 1.6.1 (or update 1.4 to anything if using the Cube auto update, and v1.7 is the only option now on offer) on the VM version (win7-64 SP1).

Cube is not a standalone executable and uses a fantastic amount of resources and libraries, notably Visual C++ redist v15 and v17 and these are notoriously hard to install, with cryptic installation errors, and desperate people posting all over the internet trying to find solutions to those errors. I suspect one cannot install VC++ 2015 after MS dropped win7 support. Done a fantastic amount of googling over past 2 days and most of the error messages point to VC++ 2015 for which I can't find a package which actually installs, and I suspect that is the key to why I have 1.6.1 running ok on the two machines which were continuously auto updated before MS dropped win7 updates.

Unfortunately Java is where Windows was 20-30 years ago, when every chest-beating programmer (well, those paid per line of code ) would generate one .exe and 100 DLLs. Now we have Cube with 2-3GB of Java files Some of the pathnames are so long that they are near the Windows max path length and if you copy them, the copy fails because the machine UNC name takes it over the limit

I posted also here https://community.st.com/s/question/0D53W000011uLwPSAU/cube-ide-installation-under-win764-sp1
but one rarely gets any response there due to the sheer quantity of posts.

The reason for this exercise is to produce clear installation documentation for the project I am working on. I am documenting everything as soon as I do it. Industrially, win7-64 is widely used on desktops although laptops are more likely to be win10.

[harerod]

peter-h, I checked that on a fresh, throwaway VMware Win7Home-64 (i7 4GB RAM 60GB SSD internet access):

Cube1.7 fails to start.
Cube1.6.1 fails to start.
Cube1.5.1 installs and is able to build existing projects.
Cube1.4 installs and is able to build existing projects.
Cube1.3 installs and is able to build existing projects.

CubeIDE1.3 .. 1.5 offer to upgrade to 1.7. The upgraded CubeIDE fails to start. Same error as a fresh 1.7 install, see attachment. The attachment is from 1.5.1 upgraded to 1.7.

Feel free to use this information, especially the error message, in your interaction with ST support.

[peter-h]

Thank you Harerod - that confirms what I found.

However I have 1.6.1 running on two win7-64 machines, both of which were online upgraded from 1.4, so what's different?

What is the VC++ distro status on your VM? On one of the base machines I seem to have the whole lot



This is the other running base machine



Both also have Java although I suspect that isn't relevant because I tried installing that, and Cube seems to dump 2-3GB of its own Java libs to c:\ST...

Would it be possible for me to retain a working Cube 1.4 install package (a documented install from the ~700MB .exe, not a VM which is ~15GB) and compile my existing code to the same binary as 1.6.1 generates? Isn't the compiler a different version in Cube 1.4 to Cube 1.6.1? If it is different, could the 1.6.1 compiler be back-patched to 1.4?

I would hate to be limited to win10 for this job.

My gcc compiler appears to be 9.3.1 20200408.

[harerod]

Please see attachment. For your other questions have a look at RN0114.
https://www.eevblog.com/forum/microcontrollers/gcc-compiler-optimisation/msg3632779/#msg3632779

[peter-h]

Yes; I think VC++ 2008 is not good enough for anything past Cube 1.4. Those error messages (exactly what I get) persistently google to VC++ 2015 missing, but try installing that into your win7-64 VM I've spent 2 days on it. One gets various 8 digit hex codes which then google to hundreds of posts by desperate people, answered mostly by conmen selling "fix your drivers" products, or on Micro$oft forums with useless replies

Funny thing is that that .dll is actually on the hard disk! But probably an old version, which is missing that call.

My gcc is 9.3.1 20200408.

[Siwastaja]

So let's recap...

Cube and ST's HAL...

* are broken
* are undocumented
* are difficult to install
* require steep learning curve
* require lot of work around the internals, including fixing unfixed bugs

... and the reasons to use them is because
* They work well and provide high quality code, MISRA and all
* Are quick to install
* Don't require the steep learning curve you would face without them
* Don't require understanding of the internals, just use, job done
* Don't even need documentation because of the ease of use

Did I get this right?

[nctnico]

As usual the truth is somewhere in the middle. 

[peter-h]

Is the compiler a single .exe (as it appears to be) compiled for x86, or something in Java?

If the former then moving the compiler from cube 1.6.1 to Cube 1.4 should work, no?

I am going to spend one more day trying to set up a win7-64 VM with VC++ redist 2015