All boards marked obsolete in CubeMX IDE and general rant about software quality.

[PPati.17]

Today I decided to start a fresh project on my NUCLEO-F429ZI board. As I tried to select the board, I was notified that that board is obsolete, and CubeMX won't generate code for it. Soon, I found that all boards are marked obsolete! So I am pretty sure it is a bug. But that means I can't proceed with my work unless I am willing to spend time on finding and setting up the old working version - if at all it is still available for download. and then merge my code to the latest CubeMX generated code when the bug is fixed. This is a lot of extra work.

There should be more stringent testing done on software before releasing it. This is not the first instance of ST's software creating trouble. I do understand presence minor bugs. But the kind of bugs I come across with ST give an impression that the software development processes are far from mature.

Examples:

1. When you make some changes in the .ioc file and regenerate the code, once in a while it says firmware not available in repository even thought it is very much available. Then it does not even try to download it again, instead, it deletes everything - all project files and also the .git folder which hosts the GIT repository!! This means any local commits to GIT are lost and even if you have pushed the commits remotely, your project is now just a bunch of files disconnected from the git repo! Anybody who uses version control (and everybody in software business should be using one), would know that .git and certain other critical files are not to be deleted.
2. STM32H743ZI firmware was extremely buggy. Had to discontinue trying to make it work and switched Cortex M4 as I did not trust H7 line to be stable enough for use.
3. Firmware updates and code generation logic jostle all code around. If you compare the source file using a version control system, you will feel the file has changed completely. But what has indeed happened is the code generator decided to shuffle the position of routines, add some white space remove some white space etc. So if I want to see what exactly has changed between versions, I can't do it efficiently, the tool tells me every single line has changed! Instead, if you maintain the order and not fool around with white spaces, it would make comparing changes much more manageable. It is important to know what has changed so that you can trace back errors to specific changes if something that worked in the previous version does not work in the new version. This makes me feel that the writers of the software gave no consideration to how software development works , or perhaps they don't follow best practices themselves and were therefore oblivious to how important this is.

My sincere request to Management:

Please focus on software quality. We don't need 1000s of different part variants. Even 10 parts would enough but build robust software around them. The amount of time I have wasted fighting ST's tools and generated code makes me wonder if I should stay put with ST.

Please on-board some new members with good experience in best practices around software development. If I may suggest, get someone from pure software development background this person need not have any idea about hardware or firmware - you need someone like a enterprise software programmer with experience of working in large teams and using version control systems to the hilt and someone who knows the best practices in software. My observation has been that embedded software engineers are in general not as good with best practices around code management as their pure software counterparts are. I have seen too may embedded engineers saving dozens of copies of their work-space as a crude and error prone version control system.

[S.Ma]

As from the embedded space, for version control, it seems that code interleaving should be minimized.

Exemple: main.c (generated by ST)

  /* USER CODE BEGIN 1 */
 My_Init(); // this part may change from user intiative
  /* USER CODE END 1 */
 
  /* MCU Configuration----------------------------------------------------------*/
 
  /* Reset of all peripherals, Initializes the Flash interface and the Systick. */
  HAL_Init(); // this part may change from ST initiative
 
  /* USER CODE BEGIN Init */
 MyConfig();
  /* USER CODE END Init */
 
  /* Configure the system clock */
  SystemClock_Config();
 

Code interleaving coming from different version control systems seems an additional handicap for the programmer. (makefile don't manage slices of source file), dates, updates from both MX and user, etc..., Cube erased my code!...)

This also applies for SW drivers coming from different sources.

Add a pressure sensor SW driver from Bosch, a CO2 sensor SW driver from Sensirion, use mBed TLS, activate filesystem, communicate with LwIP, etc...

If there are many souces files coming from different version source or even partners, that's a lot of file compare to do when anything changes.

Code interleaving seems nice at first, until version control/maintenance is factored in?

[PPati.17]

Yes, code interleaving is a terrible idea, but that's the pattern ST want's us to follow. Ideally, all the "USER CODE" sections should be external functions that the user optionally implements in a separate file. It might make reading code a little inconvenient as compared to when everything is in the same file, but the major advantage would be that ST will be free to do whatever they want to their code as the user's code won't be touched.

[Tesla DeLorean]

I think they have a bunch of software only people, problem there is they don't understand how to test and stress hardware.

The SPI hardware, conversely, was designed by someone who read a handful of data sheets and never programmed any actual devices, or wrote any drivers.​

There is a chronic lack of rigour​ to the testing, and quality assurance.

They need some managers with cross discipline grasp of the problem space to raise the bar on what the deliverables should look like.

I wonder if Larry Ellison's cat is available?

[rnone]

I can't agree more with Priyank Patil but would like to had a grain of salt.

Coming from 35 years working on software dev and hardware integration in the high speed network industry and recently got back to small electronic design, I found the environment very refreshing. Everything documented. Everything available. Datasheets everywhere. PCB and components a click away and fun in assembly. It was a breeze compared to managing millions of lines of C/C++ code and heavy build/distribution systems alongside with bug tracking and end user documentation. All this with dozens of closed firmwares able to trash the whole things anytime without a possibility to get into (well, humm..).

My main concern with embedded software is: while the code is very simple and "OS" side is restricted to a few basic sources, the tools are overly complicated. I use "complicated" as opposed to "complex". Complicated means that obfuscation is everywhere: Hidden automatic file management. hidden downloads/repocopy/updates, hidden defines, hidden compiler/linker/mapping constants, IDE's everywhere, private formats, etc.... Guys !! 100s of MB of Java stuff to manage let say 50.000 lines of C ? You kidding ?

Digging a bit into the domain, I found that there is mainly three interests:

1) The SDK code is provided as working examples. It is designed to run on many cheap demos platforms and to work "out of the box". It often is an assembly from various origins (hence style(9) disregard) with average naming and directory architecture (I mean neither good nor poor. You can live with it). This mainly comes from each components team having to provide a basic driving (generally good includes) alongside with whatever they imagine would be interesting for users (this is bottom-up design).

2) To expand the reach of SDKs, they are integrated to "professional" (read costly) IDEs where the bundle can drop in without touching the borders. This helps reduce the unpack-to-working time which is very important for engineer's pleasure (hence acceptability). Depending on time, various IDEs are hired in. Let me say you this is a NO-GO for software engineers. I myself will NEVER EVER rely on tools I can't assembly and inspect. I have rejected perfect components provided only with IAR private objects.

3) You. While you (embedded programmers) have the opportunity to grab the whole code from boot to end-users into your mind, you still see projects as brick and mortar assembly of externally provided files/libs around an as little as possible main file. You are too much working like you were managing Gigs of libraries.

In my opinion, there is no fault. There is just a lack of understanding between actors. IDE makers make a living on selling products and supports. Chip makers just demonstrate the possibilities with working prototypes (Ooops... Reference Design). Devs just follow the path of less efforts.

This results in frustrated actors: Chip makers receiving rants about code quality/usability on production, IDE makers trying to put their fat fingers into all and every aspects of coding making more bad than good and Devs frustrated by complications and unexpected behaviors.

What is important to understand is that everyone needs to simplify things. As a software engineer (when I switch hat from electronic design), here is how I proceed for evaluation to fully take over a sample:

1) Get a working SDK and platform, extract the whole stuff (in the required system if not an archive).

2) Collect every piece of sources, includes, libraries and linker script, preserving the directory hierarchy

3) Move the whole on a software workstation (really really BIG screens with lot of CLI tools, no IDE)

4) using cscope, find the main() of the closest to your goal application example

5) iteratively copy, in a single initially empty directory, all dependent sources and includes from the project (using exctags to locate functions, definitions and files)

6) repeat until your gcc (or llvm) cross-compiler successfully build an elf file without a glitch (Note: tricky part is the linker script you may hopefully find or will need to write). Also gather needed libs (from SDK or externally (nano libc, libm, etc...)) into a lib subdir.

7) When you have verified that you can flash it and run on the SDK companion board, you know you built your playground (sandbox) without any external dependencies nor external tools. You are ready to understand the way all this is built, how it works, how to rearchitecture things, etc... you can now delete all remaining proprietary stuffs and start to work.

To get to the initial point, the embedded software devs should not, in my opinion, adopt the utterly bad software habit of building baroque software piles automagically working on a lot of hopes, hairy assumptions and higher entities invocations. On the opposite, leveraging the small size of the code, they should capture the real power lying in fully understanding all and every aspect of each line of code they adopt inside their project. This notion of "making that code mine" is the key point: "That SPI driver is mine, from an ST sample". "This is MY BLE stack". The simplest way to do this is renaming (Good naming is the most important way to attach semantic to reality (aside reducing world suffering)), re-styling, re-indenting, simplifying then move to the right subdir. A good versioning system will be happy to help you into realizing the most important metric of mastering a software bundle: Starting from an empty directory on a disconnected system, extract all and everything into it, run make(1) and end up with a flashable image without any warning message.

In an environment where code is small, documentation is plenty and sources are open, nobody can really put the burden on someone else for not finding it's own shoe size. So yes, there may be some methodology to import from SoftDev (like sending to bonfire those who think an include's filename is not case sensitive) but it have to come from users. Believe me, your life is much much easier in embedded than on young school soft dev (unless you enjoy being a passenger in a car rushing into a wall honking).

Thanks for reading.

Rémy.

[Thomas Borowczak · Accepted solution]

Dear community members

The issue that many of you have faced and reported here these last 2 days, where our boards were marked as "obsolete" in STM32CubeMX and STM32CubeIDE has been solved.

Sorry for the inconvenience.

Best regards,

Thomas

[Ozone]

The ideal world you describe existed (more or less) some years ago.

But then, ST went for the lowest common denominator (i.e. the dumbest ond most ignorant user).

And see what we have now ...