Bug Report: CubeMX 4.11 EWARM User Files

[jean-francois]

Posted on October 23, 2015 at 16:47

There seems to be a bug in the new 4.11 release of STM32CubeMX.

Previously in 4.10, regenerating an EWARM project with CubeMX kept the files manually added to the project. Now in 4.11, regenerating an EWARM project resets the project entirely. Is this a bug, a removed feature, or am I missing a setting somewhere in 4.11? I even reinstalled 4.10 to check that it keeps user files. Unfortunately 4.10 won't open files modified in 4.11 #bug-stm32cubemx

[stm32cube-t]

Posted on November 16, 2015 at 11:45

Dear user,

We don't reproduce your issue. Can you please describe the different actions done that lead to this problem? Thanks in advance for your feedback

[sumenko]

Posted on November 16, 2015 at 12:22

Same for me. It affects project tree not a User Code areas inside src's. How to reproduce:

1) Take generated IAR project2) Place custom user files into project tree (no matter into new or existing virtual folder)3) Save4) Go to cube and regenerate a project5) All added user files and virtual folders will disappear from IAR Tree

[Tesla DeLorean]

Posted on November 16, 2015 at 15:13

The tool isn't really designed for iterative coding, it is designed to create a rough framework. I'd strongly suggest the use of merge tools, where you manage one primary user modified source tree, and have CubeMX generate into it's own sandbox, and you merge the new/alternate code into your modified tree. This way you're less likely to lose all your work if the process goes awry.

[hbarta2]

Posted on November 17, 2015 at 18:13

Hi clive1,

It does seem that a lot of effort has gone into making this an iterative tool, what with the ''USER CODE BEGIN'' and ''USER CODE END'' sections in many of the generated files. And this is appreciated. In my particular case the H/W has changed several times (and once or twice I did not get it right on the first try. ;) ) I am also using MX to upgrade to newer libraries. (I will certainly take your recommendation to heart the next time I structure a project and will hopefully avoid this issue.)And I'm here to report that this bug has bitten me as well. I am in the process of migrating from MX 4.9 to MX 4.11 and HAL 1.5 to HAL 1.9. We are running IAR EWARM 7.40.Overall I like a lot of things they have done between these versions. Naming GPIO pins after my designations is good as well as adding the extra comment blocks. Thanks!Having to manually add my files back to the project... Not one of my favorite features.My process was to rename the existing MX install directory (not wishing to burn bridges) and installing 4.11 to a new directory. Then I opened MX (4.11) and imported the 1.9 STM32F4 library, opened my project (.ioc) and answered 'yes' to the offer to migrate to a newer library. After tweaking a few settings I saved and regenerated code. After building I saw that some include paths seem to have been left out as well as some custom defined macros (both on the compiler preprocessor tab in IAR)And then I saw that the MX generated files were moved from a folder I had created (MX, strangely enough ;) ) and put back in User folder and all of my files in the User folder were no longer listed.I'll let you know if I find anything else.best,hank

[stm32cube-t]

Posted on November 26, 2015 at 15:39

Dear user,

Indeed there are several limitations with 4.11 version. However, they will be fixed with STM32CubeMX release 4.12 coming out next month: the user files/groups added within IAR will not be lost at the next CubeMX project generation. Best regards

[johndevos9]

Posted on August 08, 2016 at 19:03

I've seen this issue twice recently using STM32CubeMX v4.15.1.  I'm working on a project in IAR's EWARM v7.70 that includes FreeRTOS via STM32CubeMX.  On both occasions, after making changes to FreeRTOS settings in STM32CubeMX and generating code, the EWARM project had reset to include only the generated files.  On other occasions this worked, and I'm not sure what other conditions are necessary for this to happen.  In my case I'd added a configuration to the EWARM project so I could manage settings in a way I believed STM32CubeMX wouldn't touch.  This configuration was also deleted when the project reset, as was an EWARM workspace containing all this.

I almost always have the project open in EWARM when generating code, and simply reload the project when EWARM notices the change.  This has worked many times, though I'll try closing & reopening it now.Something else maybe worth mentioning: I've noticed that STM32CubeMX uses iso-8859-1 encoding for the project (.EWP) file, but EWARM uses UTF-8.  I've seen this change back and forth about 6 times in the history of my EWP file, so this isn't the culprit, just maybe relevant.

[howard n2wx]

Posted on January 11, 2017 at 18:17

 ,

 ,

I'm seeing regression in 4.18.0 of CubeMX... The issue may be back

EDIT to correct regressed version ♯