cancel
Showing results for 
Search instead for 
Did you mean: 

STM32CubeIDE and STM32CubeMx are a menace to productivity and sanity

tec683
Associate III

Allow me to vent for a moment while also exposing some real issues.

I've found it way too easy for CubeMX and/or CubeIDE to forget or mess up settings and delete my source modification without notice.

I am trying to figure out Azure RTOS USBX from all the oddly aimed and targeted examples to get a CDC ACM serial port interface to work on an F746 nucleo board with FS USB. Most of the examples are HS on a H723 or discovery boards with a HS USB transceiver.  I'm also finding the USBX documentation for the class devices to be lackluster. I'm going to just have examine the source code to see how to access it from my application.

The one example I tried from the STM32 Wiki was not CubeMX safe as significant parts were not positioned in user code areas.  So the first CubeMX code update deleted code.  That is annoying and I sort of saw it coming.  So I had to copy/reposition code so it wasn't being deleted. I got it compile but it was not recognized by Windows.

I pivoted to try the one USBX HID example targeting a F767 nucleo board.  I had that board so was able to get the HID example to compile and be recognized by Windows.  I don't think the windows driver worked.  But at least the hardware was talking.  I used an example from a MOOC USBX Lab youtube video/presentation to create a composite device.  I just took pieces of the code and added it to the example.  Yet again, this was aimed at high speed USB on a H723 board but there are many similarities so useful.

So got that to at least recognize a HID device and Serial device.  Neither driver was working on windows.

Where things got really annoying was I actually made what was a mistake to load the actual example from the video project into the workspace.  I wanted to see if perhaps there were CubeMX settings in the IOC I needed to transfer to my project.

CubeIDE updates things in a heart beat and importing this project caused H7 updates to be download.  Keep in mind these were targeted at an H7 series and in a totally different project.

Unfortunately, CubeMX has no hesitation destroying user input when packages have to be installed.  So I had to turn all the Azure ThreadX and USBX stuff back on.  Thus rendering pointless my attempt to see original settings.

Wait, there is more fun to come.

I go back to my original project which was separate and using an F7 as well to find its settings were all screwed up.  The ThreadX and USBX parts were not letting me access the settings. I ended up having to uninstall the F7 Azure package and reinstall.  Then re-enable.  Then update all my settings again.

It almost got me royally but I'm getting wise to its toxic relationship.  I had saved a copy of all the USBX related user files I had so painfully figured out and updated.  Because anyone that has used these tools can see this coming, the code update deleted all my work and replaced them with default files.

Thank god I had the back up or I would have been even more frustrated. This is a figuring out exercise as I learn what I need to do before transition to my production project. What I find is part of my timing is figuring out how to get CubeIDE/CubeMX working again.

I realize there is not much actionable by any front line STM people who may be monitoring these forums.  I do have the strong request that my user experiences be shared with the manager(s) responsible for CubeIDE and CubeMX.

Some basic development objectives would be nice.  Like DO NOT DESTROY user created inputs. Have the backup feature turned on by default.  Don't just reset CubeMX settings at seeming random.

An associated dream is that an effort is made to keep examples relevant and compatible with the current versions of the tools. Be more comprehensive in examples across more processor families. The full speed USB example support is quite lacking. 

All this being said, CubeMX and it's code generation is a power learning and development tool. When I don't want to strangle it. 

1 ACCEPTED SOLUTION

Accepted Solutions
Ghofrane GSOURI
ST Employee

Hello @tec683 

I tried to follow the scenario that you provided when we discussed in private :

 

Using CubeMX 6.10.0 and 6.9.2 and 6.8.0 :

* I created two projects with different firmwares.

* I kept the two projects opened at the same time.

* I added in both projects some lines of code in the user section code.

 

Actually, after migration ,  updating the firmware version and the X-Cube package version :

* all CubeMX versions conserve the user code that was placed in the user code section in both projects

* The user maintains to have the capability to change the settings for both projects

* The IOC configuration didn't change and kept the value chosen by user.

* Each STM32 project is typically isolated ,meaning  changes made in one project is not impacting another project.

===> The issue is not reproducible

 

Could you please send the log file when the issue occurs and any information that could be helpful to reproduce the issue.

 

The latest version of CubeMX is highly valuable due to the bug fixes and performance improvements that improve stability and provide new features and functionalities.

 

 

Thanks a lot for your cooperation 🙂

Ghofrane

View solution in original post

6 REPLIES 6
tec683
Associate III

An addendum.  At least the tools breaking is giving me an education in fixing them. 

I found when I compiled and tried to link, it now was complaining about over lapping sections with a .usbx_data section and .bss section.  It seems now that usb_otg file is specifying a section in the linker file that is not positioned well.  I was able to figure out the linker and then move it so there was space.

Only to expose the next issue.  The HAL timer, TIM6 was selected, wasn't implementing correctly. Further, the debug interface in SYS was reset and it was not even show where the 'Timebase Source' was set. This one left me stumped.

Thankfully this was a throw away learning project derived from an example project.  I could start over if I really needed to.

I went back to a previous project attempt and had learned enough to set it up so the USB works and windows driver is loaded properly.

> CubeMX and it's code generation is a power learning and development tool.

Yes. Like a bulldozer. It is just not that great when it comes to assembling clockworks.

JW

Oskar_H
Senior

I hear your frustration, this misfortune already happened to me sometimes.

I can share my general recommendations for a reliable way of working, based on my experience :

1. never upgrade the tool to the latest version if everything already works well, unless you really need it for a specific bug fix

2. never upgrade the FW to the latest version if everything already works well, unless you really need it for a specific bug fix or if it is no more compliant with the tool version you have

3. always do regular backups of your projects, especially before doing big changes and code re-generation

4. never trust the tool when it says "it is safe to put user data here and there, they will be kept as is", it is generally not true

5. use intensively text comparison tools before/after a change, to have a control on what has been really updated

6. use a version control tool (such as git), but beware of where you put the root of your repository: never in the root of the SW project, it could be automatically wiped out in a second ! Your root repository must be at a higher level for safety.

7. always be critical about the generated code: it is not because it compiles fine that it will work on your board. You can spend many hours understanding why this peripheral does not talk to that other, if you have not checked that the order of calls is correct, if the constants used in initialization structures correspond to what you have configured in the UI, verified whether the clock values are decent numbers and match the datasheet, and more...

If you follow all these advises, it will require some additional efforts but I can assure they could save you precious hours and save your nerves also !

LCE
Lead III

I have had the same experience, but luckily only in the beginning, and with much less complex stuff.

I only start my projects with CubeMX, and as soon as the basic setup (clock, GPIO) works I never touch that again.
In case I'm too lazy for register stuff, or to get an idea how HAL is doing something, I create a new project (or copy the original) in CubeMX, and then maybe copy the useful HAL sources, or build my own from there in the original project I'm working on.

And in CubeIDE I don't do anything but click build / clean. :D

Ghofrane GSOURI
ST Employee

Hello @tec683 

I tried to follow the scenario that you provided when we discussed in private :

 

Using CubeMX 6.10.0 and 6.9.2 and 6.8.0 :

* I created two projects with different firmwares.

* I kept the two projects opened at the same time.

* I added in both projects some lines of code in the user section code.

 

Actually, after migration ,  updating the firmware version and the X-Cube package version :

* all CubeMX versions conserve the user code that was placed in the user code section in both projects

* The user maintains to have the capability to change the settings for both projects

* The IOC configuration didn't change and kept the value chosen by user.

* Each STM32 project is typically isolated ,meaning  changes made in one project is not impacting another project.

===> The issue is not reproducible

 

Could you please send the log file when the issue occurs and any information that could be helpful to reproduce the issue.

 

The latest version of CubeMX is highly valuable due to the bug fixes and performance improvements that improve stability and provide new features and functionalities.

 

 

Thanks a lot for your cooperation 🙂

Ghofrane

Let me just compress your points into a few sentences:

- Never trust the system

- Be very cautious about new things

- Always investigate if the outcome is actually what you want