Is ST Cube IDE a piece of buggy crap?

[westfw]

Ozone looks dated on the surface

It's so ... annoying ... when something comes along and makes it obvious how "shallow" one is.I theoretically am mature and geeky enough that the bells and whistles and sheet "prettiness" of a modern desktop application are more signs of wasted hardware and developer resources than actually "important."  Until I come across an older-style app, like the X-11 based MacOS implementation of EAGLE, or the Padauk IDE, or GIMP, where such modernization has been neglected.  And it should be fine (and in fact I thought the EAGLE solution was an excellent compromise, back when it first came out), but it also seems so ... "Eww."
I take it Ozone is in the same category.  Works fine, probably better than average, but ... you sort of wish that there were signs of more resources being deployed to do the less important stuff.

[peter-h]

I've been coding since the late 1970s so am well familiar with text based tools, and "text graphics" tools. I've used the most awful ICE tools with the most awful UIs. One of them, a Japanese box sold by a UK agent for £10k, was even full of spelling mistakes in the menus. But it did work, sort of, and had real time trace which you don't get today.

However, I think if you are using an IDE for editing and compilation, then most people will expect the breakpoint and single step functionality to work in that too. And ST have almost done this. It's just not reliable; the debugger loses comms with the PC. But this could be something on the PC; who knows? Thankfully I don't need to run the target under debug for hours. Most issues are solved very quickly, and the rest can be found with debug statements.

What particularly breaks the Cube debug functionality is using the SWV ITM data console. It breaks even if I set the clock to some very slow value.

[betocool]

I updated the CubeIDE from 1.8.0 to 1.9.0. It broke things! I know it did because 1.8.0 would compile a repo, whereas1.9.0 wouldn't.

I went back to 1.8.0 and all my code and firmware is working as expected.

Anyone else had this?

Cheers,

Alberto

[DavidAlfa]

Peter and me at least. But basically because some variables were not correctly declared (In the header, instead as global inside a c file and then declared as extern in the header).
Try this:
https://www.eevblog.com/forum/reviews/stm32-oled-digital-soldering-station-for-t12-handle/msg4059751/#msg4059751

Easy fix, though, just fix these variables.

[dkonigs]

Having casually compared compilers for decades now, its often been the case that gcc would compile things that other compilers would fail on. However, it was almost always a case of gcc being more permissive of bad things, than those other compilers failing when they shouldn't.

Over time, gcc has become less permissive of such bad things, so this problem crops up a lot less than it used to.

Its kinda surprising that these sort of changes are still happening version to version, but it likely is par for the course.

Just remember, its not that the update broke your code. Rather, its that your code was already broken, the compiler previously let it slide, and now it isn't.  (Or the default on some compiler error/warning flag changed, which can be an easy fix if you look closely and figure out what it was.)

The only change in 1.9.0 that's been an issue for me so far, is the new default build output settings. However, fixing that was literally finding a box to check.

[peter-h]

Is anyone using a Segger debugger with Cube v1.9?

I normally use a STLINK V3 but I tried a Segger J-Link Edu. I last tried it with Cube around version 1.6 and it worked but didn't do anything any better, plus it kept putting up a message one has to agree to regarding copyright on something, which was a nuisance.

Now, the J-Link still works but not at all reliably, loses connection to the target easily, SWV ITM debug console doesn't work at all, and the stupid message still comes up, so I will chuck it away. Might not be related to the new Cube version, but it's not worth spending time on it. I got it because so many people praised the Segger stuff.

STLINK V2 and V3 both work fine, and are very cheap. Plus I can have one on each PC on which this project is being worked on, and don't have to change the project properties if a project is restored from one to the other.

[Sal Ammoniac]

Is anyone using a Segger debugger with Cube v1.9?

No. It works fine and is very robust on Cube v1.8. I'll download and install Cube v1.9 this weekend and try it with my J-Links.

[peter-h]

How do you get around the copyright agreement screen?

[dkonigs]

Is anyone using a Segger debugger with Cube v1.9?

I am, but I haven't done anything fancy with it yet.
My biggest gripe with the J-Link integration is that, for some reason, launching my code as a "Run" target never seems to work correctly. This isn't a new issue, and ST-Link has never had this issue.  Sometimes it simply doesn't reset the target correctly after reloading, and sometimes it doesn't seem to load correctly at all.
However, launching it as a "Debug" target usually works just fine. (And a Debug launch with J-Link does seem to be a slightly smoother experience than a Debug launch with ST-Link)

[betocool]

Ok, so one of the problems was the declaration of a variable twice, once in .h and once in .c files. Fortunately, in the sense of compiling the code, that was that.

However, weird thing here... The firmware I'm working on allows us to jump into bootloader mode (DFU bootloader) from a command line interface. That command and jump has worked well up until version 1.80. If I recompile the code with version 1.9.0, that particular jump fails, and the firmware does a watchdog reset. Otherwise it would get stuck. The message I get without watchdog is that the USB has not been recognised.

This bootloader jump code has been used in two projects, with pretty much the same code. If I recompile the code for both projects with v1.9.0, that bootloader jump goes to hell and I either get a watchdog reset or a funky non working state.

Any ideas? Maybe something worth posting on the STM32 forum as well...

Cheers,

Alberto

[ataradov]

Have you looked at the disassembly?

One of the most common unexpected optimizations in recent versions of the compilers is removal of the code when you deference a NULL pointer. This is technically an undefined behaviour in C, so compilers are free to do whatever. But in embedded systems NULL pointer is meaningful in many contexts.

[betocool]

No, I have not, but it is indeed a good idea!

Unfortunately I will need to get a PC with v1.9.0 to try it out, but that's doable. All of our code now runs on 1.9.0, and if this is an issue, then we can't update just yet.

Cheers,

Alberto

[peter-h]

posting on the STM32 forum as well

That often works but only for 5 mins 30 seconds - there are so many posts that it scrolls off fast

Also don't post more than 10 lines of source code, otherwise nobody replies.

It is dodgy to change compiler version on any real product. I am happy to go to 1.9 because the thing I am working on won't be out for a while. Otherwise you have to do a ton of regression testing (re-testing every line in the code, basically). With 1.9 offering seemingly nothing over 1.8, and chucking in a new compiler, you can expect trouble.

[Kjelt]

One of the most common unexpected optimizations in recent versions of the compilers is removal of the code when you deference a NULL pointer.

So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?
Than can not be, it will cause havoc.

[abyrvalg]

No. Comparison is not dereferencing and is not an UB.

A real case where I hit NULL deref UB with ARM gcc time ago:

Code: [Select]

unsigned *ptr = (unsigned *)0x1000;
do
{
   CRC->DR = *(—ptr);
} while (ptr);
resulted in an unconditional loop, compiler’s logic is: if we really accessed *0 in the current iteration then the system have derailed already, the check in while is redundant, remove it to save space. But checking for NULL before accessing (i.e. with —ptr replaced by ptr—) worked (but I really needed to feed that last dword at 0 to CRC too).

[Siwastaja]

C's built-in idea/assumption that memory address "0" is invalid and can't exist, but is used to signify invalid pointer instead, is nice and saves the memory and hassle of needing a separate "is_pointer_valid" variable for every pointer.

Yet, it totally breaks apart in systems where 0 actually is a valid memory address, and you need to use that. This includes many embedded systems.

I'm surprised this problem isn't widely recognized. Is there really not some command line -fallow-zero-pointers option?

[NorthGuy]

Strictly speaking the NULL pointer doesn't need to be represented as zero internally:

"An integer constant expression with the value 0, or such an expression cast to type void *,is called a null pointer constant. If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal
to a pointer to any object or function".

Therefore, an implementation is free to use any representation for the NULL pointer (say -1). This way, a valid pointer to address 0 will be different from NULL. The only limitation is that void*(0) will be cast to NULL instead of to a valid pointer to address 0, but a non-constant expression, such as void*(x-x) will be cast to a valid pointer.

So, there may be a solution, but the compilers just don't use it. After all, it's not that hard to reserve the 0 address for something which is never pointed to.

[dietert1]

Or live with one lost byte. The problem is about as relevant as a 32 bit unsigned tick counter that overflows every 4.3 million seconds = every 50 days. There may be a glitch or a crash. Once you are aware of it, it's easy to check and work around.
IMO this thread documents how Embedded is a moving target. Some days ago i read a paper on STM32U5 low power operation. They promote longer sleep intervals by educating developers about the extra hardware links between low power peripherals. This was difficult to learn on the MSP430 and not that important as the MSP430 remains low power even with thousands of interrupts per second. Now it seems we should learn this. And each MCU has it's own details.

Regards, Dieter

[ataradov]

So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?

No, as explained above.

Specifically when applied to bootloaders, you often have bootloader placed at address 0, and this is the address that would contain the initial stack pointer for the bootloader. If you are jumping to it using a regular jump, then you would need to dereference the 0 pointer to get the value of the SP. If this is the case, you would need to do that in an assembly section.

But this is not the best way to call the bootloader anyway. A software system reset (via WDT or NVIC) is way better.

[nctnico]

So if you write safe code and put a guard in the beginning checking if pointers are initialized by verifying they are not NULL that will be removed?

No, as explained above.

Specifically when applied to bootloaders, you often have bootloader placed at address 0, and this is the address that would contain the initial stack pointer for the bootloader. If you are jumping to it using a regular jump, then you would need to dereference the 0 pointer to get the value of the SP. If this is the case, you would need to do that in an assembly section.

I still find it weird that the compiler messes around with what should be an arbitrary number. It seems that GCC may remove NULL pointer checks assuming the program would crash anyway which is something I really wouldn't want to happen on an embedded (microcontroller) platform because in such a case it isn't handled by an OS gracefully.

There are some options to control the behaviour of GCC though:

-fdelete-null-pointer-checks

    Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. This option enables simple constant folding optimizations at all optimization levels. In addition, other optimization passes in GCC use this flag to control global dataflow analyses that eliminate useless checks for null pointers; these assume that a memory access to address zero always results in a trap, so that if a pointer is checked after it has already been dereferenced, it cannot be null.

    Note however that in some environments this assumption is not true. Use -fno-delete-null-pointer-checks to disable this optimization for programs that depend on that behavior.

    This option is enabled by default on most targets. On Nios II ELF, it defaults to off. On AVR, CR16, and MSP430, this option is completely disabled.

    Passes that use the dataflow information are enabled independently at different optimization levels.


From: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html

Edit: It looks like the GCC version I'm using for microcontroller targets (vanilla GCC from ARM) has -fdelete-null-pointer-checks enabled by default.

[ataradov]

I still find it weird that the compiler messes around with what should be an arbitrary number. It seems that GCC may remove NULL pointer checks assuming the program would crash anyway which is something I really wouldn't want to happen on an embedded (microcontroller) platform.

  This is a side effect of the optimizer that is spread over all stages of compilation. They don't internationally hunt for this use case, this removal is just a side effect of implementing the spec to the extreme.

As if was said, NULL can be anything, and 0xffffffff would be a better value in this case, but literally everything would break if you make this change.

And this may actually be useful. I ran into an issue where I inadvertently used an uninitialized pointer and the compiler removed the whole body of the function replacing it with one "udf" instruction. If the code contains undefined behaviour - just mark it as such and replace with a clear undefined instruction. This actually helped me to quickly find the source of the issue, as I've got a clear and repeatable fault.

There are some options to control the behaviour of GCC though:

This is good to know.

[peter-h]

I did say pointers are the root of all evil

That said, I could not completely avoid them, in things like this

Code: [Select]

data=0;
for (address=0x080e0000; address<0x080fffff; address+=4)
{
if ( (*(volatile uint32_t*)address) != data )
error++;
data+=4;
}
There was a long thread here on optimisation. GCC -O3 breaks a lot of stuff and IIRC people said that is to be expected because it is experiemental.

The daft thing is that in nearly all cases, removing code which the compiler thinks is not used, saves absolutely nothing. What % of your project is code which might do nothing? Maybe a few lines in 10000. Who would produce a compiler which does this? It is ridiculous. A compiler should optimise real code constructs. And they have been doing that for many years.

The wider issue is that if you are working on something which will also be worked on by others, you have to freeze them on version 1.8.0, and not everyone will like that.
The trouble is that nobody can guarantee their code will compile and run right on every future compiler version. People aren't perfect

[nctnico]

As if was said, NULL can be anything, and 0xffffffff would be a better value in this case, but literally everything would break if you make this change.

That is true. But it is also the result of sloppy programming. Things like if (!my_pointer)  yadayada_error(); is just bad coding since NULL can be defined as any value. BTW: IMHO you should always use conditional statements with an explicit value anyway.

[newbrain]

Things like if (!my_pointer)  yadayada_error(); is just bad coding since NULL can be defined as any value.

No, this is wrong on two counts:

• !my_pointer is guaranteed to yield true if my_pointer is the NULL pointer.
• NULL is defined as either the constant 0 or the same cast to (void*)

References (C11):

• 6.5.3.3 Unary arithmetic operators, §5:
  The result of the logical negation operator ! is 0 if the value of its operand compares unequal to 0, 1 if the value of its operand compares equal to 0. The result has type int. The expression !E is equivalent to (0==E).
  Now, 0 in a pointer context is the NULL pointer so the expression will do the right thing.
• 6.3.2.3 Pointers, §3:
  An integer constant expression with the value 0, or such an expression cast to type void *, is called a null pointer constant . 66) If a null pointer constant is converted to a pointer type, the resulting pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.
  So NULL cannot be defined in other ways, and 0 is a perfectly good NULL pointer.

If the actual machine NULL pointer needs to be something different for whatever reason, it all must happen by compiler magic.

EtA: OTOH, if one does something like (uintptr_t)p and p is a NULL pointer, I don't see anything in the standard that would prevent getting something different from 0 (but I should check more accurately, definitely nothing in 6.3.2.3).

[Kjelt]

Oh well this confirms again that in modern programming we do need autotesters with lots of sunny and many more  rainy day scenarios, checking all desired , undesired and esp. critical behavior of the code.
If the compiler has changed something which influences the devices result, some test shall fail.