Is ST Cube IDE a piece of buggy crap?

[voltsandjolts]

You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.

Not impossible if you automate it and run at nights/weekends.
This is even necessary for each new fw release imo, because each code change could break functionality. Sunny day scenarios and 30% rainy day scenarios testing is standard practice in the last three companies I worked for. Tests are expanded for the new added functionality but also for any bug found in the field (which triggers an internal process to find the cause of the bug and how to prevent this in the future). In combination with (as far as possible) continuous integration, continuous delivery it is essential that each release is tested.

I don't think automated build/test and CI/CD has a role to play in deeply embedded mcu applications, which is mostly what is discussed on this board.

[voltsandjolts]

There is no point is playing with optimisation levels IF the product is working correctly.

Turning up the opti level is often a good way of revealing poorly coded parts of the code, revealing latent faults which might have bitten you at some later time (post deployment!).

[westfw]

I think optimisations beyond -O1 are likely to break some ST HAL code

Well, if true, that would fit in the realm of "buggy crap"...  It seems doubtful to me, though.

There is no point is playing with optimisation levels IF the product is working correctly.
You have to do a potentially huge amount of "regression testing". On a product of any complexity, this is impossible.

All the more reason for doing all of your development work at the top optimization level you have in mind.
I would never do development at -O0, for instance, regardless of whether debugging "works better."

Although this requirement that keeps cropping up that "regression testing" somehow be more complete than the testing of the original code is a personal pet peeve of mine...

[ataradov]

There is no credible evidence that optimization levels break ST code. The mentioned SPI CS problem is not a real issue. In any case letting libraries control your CS is not a good idea, it is an application-level thing.

[SiliconWizard]

I have used the STM32 HAL up to -O3 with absolutely no issues. While you may find the HAL bloated, too general and with questionable interfaces, it's written in perfectly standard C as far as I've seen (and checked with analyzers) with no obvious problems detected by major static analyzers.

If there was a suspect there, I would definitely place it either in my own code, or on other third-party libraries with much more dubious code quality than the STM32 HAL.

And optimization bugs (for perfectly valid code) are rare. I've been using various versions of GCC on various targets for a long time now, I've routinely used -O2 and -O3, and only ran into ONE compiler bug over all those years. It was on Aarch64, and it wasn't an optimization bug per se, it was just that GCC wasn"t properly enforcing aligned access only when using the corresponding flag. I reported the bug and it got fixed in the next release.

[westfw]

And optimization bugs (for perfectly valid code) are rare.

Well, it's more that "some things common in embedded code" are optimized in unexpected ways, resulting in failures.  Delay loops and concurrency/atomicity issues come to mind.

[tabemann]

If your code breaks because of the optimizer, it certainly means that your code has bugs that would likely break sometime later out in the field, unexpectedly and likely in a hard-to-reproduce fashion. I would much rather trust gcc to optimize correctly rather than trust one's own code, or one's dependencies' code, to not have subtle bugs. If anything, I would expect one to use -O3 to try to work out the bugs now, rather than to be bitten by them later.

About the STM32 HAL, I personally have not been impressed by what I have seen in them, but if it has bugs that would be elicited by optimization, I somehow bet people would have been bitten by them already.

[peter-h]

Another "feature" which crept in around v10:



It shows a negative value where shown. Rebuilding a few times gets rid of it. It doesn't seem to actually stop anything working.

[Siwastaja]

If your code breaks because of the optimizer, it certainly means that your code has bugs that would likely break sometime later out in the field, unexpectedly and likely in a hard-to-reproduce fashion.

This, this and this. And because of this, "do not change optimization settings so that you don't need to run regression testing" is bullshit. Opposite is true: you could compile the code with all possible optimization settings and run regression testing for each just to give more opportunity for bugs to stand out!

I'm never afraid of changing compiler settings or even updating to different compiler version, because that is always an opportunity to reveal my own mistakes, and get them fixed. (Choosing to use external broken code, or choosing to work in a socially broken project where bugs cannot be fixed are also examples of something to be considered my own mistakes.)

[SiliconWizard]

And optimization bugs (for perfectly valid code) are rare.

Well, it's more that "some things common in embedded code" are optimized in unexpected ways, resulting in failures.  Delay loops and concurrency/atomicity issues come to mind.

Which all would be signs of wrong assumptions, thus misuse of C.

Now if it's in third-party code, as I said earlier, it may look beyond your control, except that your choice of libraries IS within your control. And again for the record, I've never personally encountered such code in STM libraries. If there is, I'd be curious to see it.

As several of us already said, any code that breaks with optimizations is, in most cases, a catastrophe lurking, just waiting to rear its ugly head at some point and bite you severely.

[DavidAlfa]

To date, all optimization bugs were caused by me. Once all were cleared up, I've neved experienced any HAL bug caused by optimization.
But it's HAL, will aways have bugs, for example, with DMA and Timers.
Really easy to solve, simply init DMA first, but any touch in CubeMX will recreate the bug again.
As you can see, the answer was "It's been there for years, learn to program yourself".

Translation:
"Hey, don't come here trying to change our traditions!"

[SiliconWizard]

Apparently, the problem you gave a link to is a CubeMX generation "bug", not a bug with the HAL itself. (Or you may consider that the HAL init functions themselves should check that stuff, which would make them even more bloated than they already are.)

Do not confuse the HAL with the CubeMX IDE. The CubeMX IDE definitely has bugs, the HAL itself, very few IME. And I've used the HAL without the IDE. It's not rocket science.

[tabemann]

To me the wisdom of relying on an IDE to do one's code generation is highly questionable, at least from my experience of working with Java IDE's in my day job. They seem to be designed for people who could not program their way out of a wet paper bag, and generally produce brittle code that is difficult to edit manually at best (e.g. many a GUI editor will produce absolutely godawful code that is impossible to work with) and breaks if one looks at it the wrong way at worst (even though I found IntelliJ to produce okay code when automating very simple but time-consuming tasks like generating large numbers of Java accessors).

[newbrain]

Another "feature" which crept in around v10:



It shows a negative value where shown. Rebuilding a few times gets rid of it. It doesn't seem to actually stop anything working.

The number shown looks correct.
If the boot memory is 32 kB and 69 kB are used, well, you have a 37 kB debt!
Check the linker scripts and memory size definition if that does not match reality.

[peter-h]

I wrote above

Rebuilding a few times gets rid of it.

[newbrain]

I wrote above

Rebuilding a few times gets rid of it.

Yes, but I had read that - and it just makes the fact more worrying.
To me it's still a red flag that something is not proper in that area - the tooling should be deterministic. Same code same output.

I'll be blunt: this is just one more of the many red flags that you have shared in time, and they make that whole codebase and tooling look extremely fragile to me.

[newbrain]

or even updating to different compiler version, because that is always an opportunity to reveal my own mistakes, and get them fixed.

sizeof sample == 1, take it FWIW:
On a personal project I updated to clang 15 from 13.
I got a new warning (I have a couple coming from the SDK I use - none from my -Wall -Wextra -pedantic code), about returning the wrong kind of enum from a function.
It was inconsequential, given the enum-is-an-integer-with-a-fancy-name thing and the ranges in play, but it highlighted a place where I had a badly designed interface.

[peter-h]

the tooling should be deterministic

Yes, but read further back up this thread, about the Build Analyser not appearing at all until the .map file is clicked (usually that works, but not always).

AFAICT this is another Cube thing. Doing a build only (control-b) has this issue in Cube v10 but doing a Debug build (F11) produces the correct output, even though the compiler and linker etc steps are identical (I build only in what Cube calls Debug, not Release).

[tabemann]

Personally, I would just avoid IDE's when in doubt, which is definitely the case here with what you have been seeing out of CubeMX. (I do admit to using Visual Studio at my current day job, but I really use it just as essentially a text editor with built-in syntax formatting and highlighting, and while I have used a number of Java IDE's at past jobs, the only one that seemed to be of any real quality was IntelliJ (Eclipse in particular was painful to work with), and even that was painful to build new projects from scratch under.)

[paulca]

I had the phantom break point that wont go away tonight.  Happened right after it told me I had too many.  I removed a few, that "fixed" it  but wherever I put the break point in the *_tim.c file it always breaked at a completely different line that I had breakpointed half an hour ago!

Restart eclipse didn't work.  Unplug/replug the STMLink and restart eclipse didn't fix it either.

Also, more of a rant about HAL and STM32's documentation of same.  It's insane.  I spend 3 long hours tonight trying to get DMA->PWM timer output to work.

* There are ALWAYS twice as many options in the dialog as any documentation tells you about.
* The version you have ALWAYS has a different set of criteria on options.
* Your timer doesn't have the setting the tutorial wants.
* You set it up EXACTLY as per a dozen tutorial, 40 mins in the datasheet and re-re-reading the documentation and... it doesn't work.
* Most of this is because... there are so, so many options which more tutorials and documentation simply forgets to mention.

In the end I got it working, but my god it's confusing as hell compared to the lies the docs and tutorials tell you.  For example, "arbitarily select your DMA word size", like it means nothing.

The CCR register is a 32 register that takes a 16 bit value.  Ok.  However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints.  8 bit ints don't work.

Worse yet.  If you DMA transfer to the CCR register byte by byte, it goes nuts.  If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed.  WTF?

Also, if you are using one set of word widths for storaging and DMA transfer, then you duty cycle values will change if you change any of them, even while the frequency remains the same.

I got it working, but I feel like I've been dragged through a hedge and I don't quite understand what the hell was actually going on and the documentation and tutorial did sod all to help!

I've decide to move on and pretend it didn't happen.

To end on a funny note.  The last 30 mins were spent staring at a coil of Chrismas LED WS2811s ... all cyan and grumbling at the scope going "THAT RIGHT!!! 800kHz  4uS off 8uS on.  There is nothing wrong!  WHY you no WORK?"

Well, the penny dropped.  It was working.  It was working extremely well.  To the tune of well over 100 "frames" per second... which is why all the animated christmas colour animations looked Cyan... that and I had my RGB backwards

[newbrain]

The CCR register is a 32 register that takes a 16 bit value.  Ok.  However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints.  8 bit ints don't work.

Worse yet.  If you DMA transfer to the CCR register byte by byte, it goes nuts.  If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed.  WTF?

Don't know which STM32 you are using, but from several RMs, when timer registers are described one can read this:

The peripheral registers must be written by half-words (16 bits) or words (32 bits). Read accesses can be done by bytes (8 bits), half-word (16 bits) or words (32 bits)

So, no, 8 bits writes are not allowed.

[peter-h]

I had the phantom break point that wont go away tonight.

Cube has always had this issue. You can set a breakpoint anywhere



In a comment (above), on code which is #ifdef'd out, on code (this one got me a few times) which is stripped out. I had one case where I set a bp on a callback function. The bp was never taken. It took me ages to discover that the callback code wasn't there at all, because the module which was calling it wasn't there, and it wasn't there because nothing was calling it anymore (which itself was very subtle and deep down).

If I was writing this tool, I would have a post-build step checking that any breakpoints are set on actual binary code. And each time a new bp is set, re-check that. Enabling bps to be set on any line regardless of what is there is just so completely dumb.

Then you get stupid issues like if you delete a line above, the code shifts up a line, but the bp stays put (not always though).

It's a lot better than nothing, but it is a hack.

[paulca]

The CCR register is a 32 register that takes a 16 bit value.  Ok.  However if you feed it from an array of 32bit ints, you get different behaviour if you feed with 16bit ints.  8 bit ints don't work.

Worse yet.  If you DMA transfer to the CCR register byte by byte, it goes nuts.  If you transfer to it in half words it works, if you transfer to it in 32bit full words, it runs at half speed.  WTF?

Don't know which STM32 you are using, but from several RMs, when timer registers are described one can read this:

The peripheral registers must be written by half-words (16 bits) or words (32 bits). Read accesses can be done by bytes (8 bits), half-word (16 bits) or words (32 bits)

So, no, 8 bits writes are not allowed.

That much was apparent.  I suppose I should dig in and find out how it behaves when you send it as half words or full words, especially when it contains 16 bit ints.

I'm still a little baffled, as in my normal day world of very strong types I dont have 8 bit ints masquerading as 32 bit ones or vice versa, but I do in STM C.

To explain.

My PWM "period" is 90 OCC cycles for 800kHz with a 72Mhz clock.  (ARR=90)  <--- Or is it?  Sometimes the bus clock is 50% OCC.
My PWM duty cycles are 33% (30) or 67% (61)  CCR is fed by DMA.

Normally / ideally those numbers 30, 67 fit into uint8_t to save memory.  However knowing that the CCR register takes 16 bit values I decided to use uint16_t to store them.  Great so far.

However the DMA transfer function takes a uint32_t* for it's data to send and an ambiguous parameter, "Length".  Note, not Size, but Length.  I believe I have even seen it referred to as "The number of items to send"... what are items?

Now my figuring is, if I have 2400 uint16_t values I should be passing the Length  2400/2 for 32bit pointers.  However I am no longer entirely sure this is correct as to how it behaves.

So now the seed of doubt is planted we come to the DMA configuration itself.  It allows byte, half word, full word.  Tutorials, as I said, always just shrug and say it doesn't matter, pick half word as it's the default.  Turns out it does absolutely matter.

The annoying thing is, it's so slippery and ambiguous.  So, so many blind explicit casts of datatypes and pointers there is no protection at all from weird alignment disorders.

Maybe more RTFM and more investigations will make it clearer to me, but for a newbie to STM world it's always this kind of stuff that gets really confusing, really fast and wastes hours and hours on abiguity.   I figure reading the entire 300+ page reference manual will help... however having been down that route in Application Notes for PCB layout, it's the SAME SHIT.  The notes are stacked and apply to a dozen different MCUs ALL with DIFFERENT aspects.  It makes the App Notes and Reference manuals really difficult to track.  "The ABC is enabled (F0-only) when the F4 would enable it's DEF, unless you need the RRT of the F4 then ...."  etc.  "The widget can be used (except in F1) when the CCF1 register (Not available on all packages) is high...."

For now I am assuming... to retain sanity... 

I store 16bit CCR register values in a 16bit uint array.
I send Half words, aka 16bit words to the CCR register via DMA
When I sent the array as a 32bit uint pointer, I halve the length.
If I leave all of that alone, my frequency and duty cycle values should remain non-insane.

Anyway, now that I got that working, todays "It's quiet in work" is trying to get the F030 to animate 100 WS2812s.  The F1 was too easy.  Note 100 LEDs will more than fill the memory twice on the F030F4.  I only moved to an F1 because I wanted to stop dealing with heap and stack crashes until I got the LEDs at least working.  I've been tempted to just ASM bit bang them.  It's not like there will be much left of the F030F4 to do anything else while the DMA is transfering.

EDIT:

Code: [Select]

ld.exe: region `RAM' overflowed by 56 bytes
Hmmmm.....  what needs to go.

[newbrain]

However the DMA transfer function takes a uint32_t* for it's data to send and an ambiguous parameter, "Length".  Note, not Size, but Length.  I believe I have even seen it referred to as "The number of items to send"... what are items?

AFAICS (F0 HAL drivers), the HAL uses uint32_t, not uint32_t * for is source and destination addresses.
As much as I'd conceptually preferred void *, uint32_t reflects the base type of the destination DMA registers - no ambiguity here.
The length parameter is the number of items to be transferred, the size dictated by the DMA setup- it goes straight into the CNDTR DMA register.

Also note that in general you have to load one less than the count value in timer register (e.g. period 90 clock cycles -> register = 89).
Not sure STM32CubeMX (or equivalent in STM32CubeIDE) will do that for you - check the generated code.

EtA: Moving an array of uint8_t to the lower 8 bits of a 16 (or32)  bit wide destination is of course possible, check the 2nd row of the table in chapter "10.3.4 Programmable data width, data alignment and endians" of the RM.

[DavidAlfa]

Exactly. Check the DMA size: byte, half-word (16bit) and word (32bit).
So the dma engine accounts for number of transfers, no size.

DMA functions works for any size, DMA can access any data, so simply recast the pointer.

Anyways using PWM and 16-bit values to transfer a single bit it's *crazy* inefficient!
You should know the timing already:


With that, you can use the SPI running at 3MHz and reduce memory by a factor of 8.
To send a "1" transfer "110" (666ns high, 333ns low)
To send a "0", transfer "100"(333ns high, 666ns low)

So a single byte will pack 2 & 2/3 bits, one sub-pixel will use 3 bytes, and 9 bytes for a complete transfer, not 48!

Code: [Select]


 r0  r1  r2     r2 r3  r4  r5      r5 r6  r7
{000.000.00}    {0.000.000.0}     {00.000.000}

 g0  g1  g2     g2 g3  g4  g5      g5 g6  g7
{000.000.00}    {0.000.000.0}     {00.000.000}

 b0  b1  b2     b2 b3  b4  b5      b5 b6  b7
{000.000.00}    {0.000.000.0}     {00.000.000}


Edit: Simply send reset signal (>50us) by sending 18 zeroed bytes (Or few more to be sure), so your structure will have:

Code: [Select]

  DATA (900Bytes)          RESET (18Bytes)
{ 100* RRRGGGBBB }        { 18* 0x0 }


It'll go from 100x48=4800 bytes to just 100*9=900bytes! (918 bytes with reset)
You were sending 20 LED at a time (960bytes), so it'll fit perfectly.