CubeMX, IAR code regeneration ''project generation have a problem'' it says

[childresss]

Posted on April 22, 2015 at 23:27

A recurring big problem with CubeMX (all versions. using v4.7/latest now)....

After making pin mapping and peripheral config changes, I run GENERATE CODE, as often I do. Too often I get this from CubeMX:

''The Code is successfully generated under (mypathname), but EWARM 6.70 project generation have (sic) a problem.''

The EWARM 6.70 part is irrelevant - I use a much later version of EWARM.

It's telling me that all the sources were regenerated but it got some unsaid error when regenerating the IAR EWARM project files.

I don't know what I do that causes these errors to begin after many prior error-free sessions. No big changes in file/folder tree arrangement.

If I continue to ignore the error, I can get IAR to build and run with ST-Link OK.  I dearly wish the error message would give some semblance of a clue as to the error that occurred.

[childresss]

Posted on April 24, 2015 at 19:20

ST?

Anyone?

[childresss]

Posted on April 29, 2015 at 00:26

Anyone - ST ?

Please?

[stm32cube-t]

Posted on April 29, 2015 at 15:30

Hello Steve,

It happens that sometimes some files get set in ''access denied'' mode by EWARM preventing successful MX project generation. Trying to generate again usually works. Please let us know if you have identified some actions that leads systematically to the problem.

[childresss]

Posted on May 01, 2015 at 05:57

Thank you for the reply.

Your recommendation

''Trying to generate again usually works. ''

Do you mean to simply run CubeMX's Generate Code? I've done this many times, before posting here. No help. I can launch the eww file and build/run/debug as usual.

I can't say what causes it - other than generally it happens often, after using CubeMX without error. Once it happens, there's no cure other than to abandon and start anew. This is far too onerous, as I've found no way to more or less export the configs.

[olegh]

Posted on May 06, 2015 at 13:41

I have same problem, too. Try to place your project into folder without spaces and international letters in name. It usually helps to me.

[childresss]

Posted on May 18, 2015 at 18:18

More than one user reports this problem. Spaces in path name isn't the cause.

ST, PLEASE RESPOND.

[spa23]

Posted on May 28, 2015 at 15:20

I have same problem, too....

[denny2]

Posted on June 12, 2015 at 11:23

I have the same problem:

STMCubeMX generates all the code necessary, except it doesn't create a ''EWARM'' directory (nor any content). If I create this myself and use IAR to set up a Project I can use the code generated. What gives?

Edit: If I change the directory to a not so deep path it works! A nested path six directories deep doesn't, but two does.

[hexel2]

Posted on November 16, 2015 at 18:55

As for me, a looked toward filepath with spec characters/spaces. for the time CubeMX was installed, it worked good, but today refused to make a EWARM files for me. the reason was a russian-named folders, containing repository.

moving reps to simple-named folder had overcome the issue

[Jim Frederick]

Posted on December 07, 2015 at 22:55

I see the ''have a problem'' problem frequently. Today,  I was working on a CubeMX .ioc file that generated code for OpenStm rather than IWARM. I tried simplifying the path name (by copying the project to the equivalent of D:\, removing spaces or other 'odd' characters), deleting the .mxproject file and deleting the directories created by CubeMX (Drivers and, in my case, SW4STM32) and re-generating code. That didn't work - there was no change in behavior.

This worked: I renamed the .ioc file and edited the .ioc file with a text editor to replace all instances of the old name with the new name (3 instances inside the file) and then code generation worked.

A note to ST: Could you point us to an error log or some means of getting more specific error information? I tried using Process Monitor from Windows Sysinternals but didn't see any obvious errors. The Event Viewer didn't reveal obvious errors either.

Edit: I saw the ''have a problem'' problem again using CubeMX to generate an OpenStm32 project. Adding a file to the OpenStm32 project (a very common scenario, right?) causes the ''have a problem'' problem to appear. Maybe the problem that CubeMX is having is editing/modifying the .project file used by Eclipse in an OpenStm32 project. It's almost as if the vague fractured-English error message really does mean that the .project file could not be regenerated and it's not clear what other files could not be regenerated.

The only work-around I've found so far is to let CubeMX generate and regenerate files in one directory and then merge changes (using something like Meld) over to a 'real' directory used for compiling. I tend to do something like this meld/merge anyway for main.cpp because I use a main.cpp but CubeMX generates a main.c file. I tend to regenerate projects with CubeMX frequently during development when tweaking parameters such as clock frequencies, timer clocks, GPIO configuration etc.

Note to ST: consider indicating what files could or could not be generated. If there's a conflict, consider modeling behavior the way source-control packages handle merge conflicts. One example: go ahead and generate a new clean file but keep the old one with a modified name and alert the user about the conflict.