Release build not defining compiler

[Dave Jones]

Posted on March 29, 2018 at 22:22

I am using the latest TrueStudio with a project for STM32L452 created using the latest STM32CubeMX.

The created project contains both a debug and a release build. When I set the debug as active and look in one of the files that contains conditional compiles based on the compiler (core_cm4.h) I see that the lines for __GNUC__ are not grayed out. So obviously that compiler is defined somewhere.

However when I set the release build as active and look at that same file, all the conditional statements based on compiler are grayed out, and the final 'else' for 'unknown compiler' is the one not grayed out. So clearly __GNUC__ is not being defined anywhere.

Also, when I go to the build settings and select the release build I see a warning at the top that says 'Orphaned configuration. No base extension cfg exists for com.atollic.truestudio.exe.release.1518366166'. I don't get that when I select the debug build.

So, what does that warning actually mean, and why is the compiler not defined in the release build? (and where is it normally defined?)

[Dave Jones]

Posted on April 01, 2018 at 22:25

Any idea what that 'Orphaned Configuration' error means???

I tried using a copy of the same project to create an output for System Workbench (SW4STM32), and that one does not have this error in the release configuration, and it does define 'GNUC' in both the debug and release builds. So it's not the project that is at fault. It's something to do with how STM32CubeMX is generating files for TrueStudio.

[Imen.D]

Posted on April 02, 2018 at 16:36

Hello

Jones.Dave.002

,

May be your release Run configuration in TrueStudio is corrupted and not correctly created.

So, please

try to

recreate the new one with properly

path.

Kind Regards,

Imen

[Dave Jones]

Posted on April 02, 2018 at 20:36

I was able to delete the Release build and create a new one with that name by copying the Debug build, and then setting the Debugging settings in the assembler and compiler to 'None'. I don't know what else is supposed to be different in the Release build.

But that corrupt Release build was created by STM32CubeMX. Not corrupted by me.

To prove that I went to STM32CubeMX and created a new, very simple project. I created a project for the L452 (same chip in my other project) and simply set one pin as a GPIO input and another as a GPIO output. I then saved that project for TrueStudio.

When I open that new project in TrueStudio I get the same corrupt Release build as before. The debug build doesn't show that error mentioned in my first post, but the Release build does.

Taking a closer look at the build settings, I find that the problem may be in the Build Settings > C/C++ General > Preprocessor Include Paths, Macros, etc...

In there, selecting Debug build shows an entry for 'Atollic ARM Tools Language Settings', but that is not in the Release build. When I expand it in the debug build (with the little [+]) I can see all sorts of defines, including the __GNUC__ that is missing from the Release build. When I click the Providers tab and try to add the Atollic ARM Tools Language Settings to the Release build, back in the Entries tab there is no [+] to expand it, so none of those same preprocessor symbols are listed.

So whatever this issue is, STM32CubeMX is the thing creating the bad Release builds for TrueStudio. At least for this specific processor. I didn't try other processors. But I did try the same projects created in CubeMX for SW4STM32 and those created working Release builds.

[Imen.D]

Posted on April 05, 2018 at 17:25

Hello

Jones.Dave.002

,

Thanks for reporting such problem.I tracked this issue internally for check and investigation.

Best Regards,

Imen

[Yukiyo Watanabe]

Posted on April 06, 2018 at 02:53

Hello everyone

I am in trouble with the same problem altogether.

I am performing GPIO and UART (RX only DMA) with STM32F030 (NUCLEO - F030R8).

I hope this problem will be solved quickly.

Best Regards,

Yukiyo

[SZank]

Hi all,

after starting the Atollic Truestudio I'm facing exactly the same problem. Unfortunately I had to realize that STM is not really willing to help so I'm not expecting any answer.

 

Unfortunately I had to realize multiple times that STM is not really willing to help so I'm not expecting any answers.

Kind regards

Sebastian

[Imen.D]

Hello @SZank​ ,

This issue is confirmed from our side and will be fixed in the next release of STM32CubeMX.

Sorry for the inconvenience it may bring and thank you for your understanding.

Kind Regards,

Imen

[Markus Rudolf]

It's more than 3 Months and still not fixed in CubeMX 5.10. Instead of making a fancy new GUI no one really likes you should concentrate on making the tool fit for everyday use. This bug is annoying and shows internal testing could not be very intense when even such basic stuff does not work.

I would really like to have a proper bug tracking ticket system instead of this forum based approach. There is only a handful of moderators stating bugs are reported but you rarely get feedback if it's fixing, under which ticket ID the case is reported and so on.

[SZank]

Hi @Imen DAHMEN​ 

thanks for the reply. Is there a possibility to restore at least the settings somehow? I configured many things like include paths, library paths ...

Kind regards

Sebastian

[WBOUG]

Hi @SZank​ 

It's a good idea from you and I thank you.

Your request has been submitted and it will be corrected in the next release  of STM32CubeMX.

Best Regards,

Wael

[alister]

@Imen DAHMEN​ and @WBOUG​ you'd posted 3 months ago this would be fixed and @Markus Rudolf​ reports it isn't. So there's a disconnect. Can you describe at least what was fixed please?

[alister]

I too observe STM32CubeMX unnecessarily taints the project files of IAR and TS. Best practice, after regenerating a configuration, is to diff the project files and correct by hand any damage, same as for merge conflicts.

[WBOUG]

Hi @alister​ @SZank​ @Markus Rudolf​ @Yukiyo Watanabe​ @Community member​ 

This problem is fixed already and it will be found in version 5.2.0 CubeMX.

Best Regards,

Wael

[Markus Rudolf]

Any idea about a release date? I have some deadlines to meet with my current project....

[WBOUG]

It will be Q2

[Markus Rudolf]

Simplest example: say you change only the pull-up/-down of a GPIO, you know it needn't make any change to the project files. Be suspicious if it has. You may revert them.

@alister​ That would imply there was actually a working version of the .project and .cproject files which to my knowledge is never the case. Even a fresh project shows the errormessage in the header of this post about the orphaned config. I have everything in GIT and can try go to the different versions but I doubt I will find something that works.