cancel
Showing results for 
Search instead for 
Did you mean: 

Project from TouchGFX Designer 4.23.2 Compiles Twice in IDE?

ttnickb
Associate III

# Overview

I have a TouchGFX GUI project based on STM32U5G9-DK2 evaluation kit.  

I initially generated the project in `TouchGFX Designer 4.23.2`.

Upon switching to `STM32CubeIDE 1.15.1` for development, it seems like the "Right Click -> Build Project" step runs two builds (?).

The first build usually shows some errors with include files in the Console:

ttnickb_1-1724099678408.png

At this point the progress bar shows ~25%.

The above Console errors are quickly overwritten by the second "build" which works OK:

ttnickb_2-1724099738432.png

 

# Questions

How I can remove the first "intermittent" build from this flow?  It seems like a waste of time (10-20 seconds) and is confusing that it shows errors when there are none.

6 REPLIES 6

Hello @ttnickb,

Normally, there shouldn't be two rounds of compilations since STM32U5G9J DK2 does not require a bootloader. 

Based on the first error, it seems like you have added some code related to led, however, the compiler cannot figure out how to connect this code with the rest of your project. And, I guess what happens is that STM32CubeIDE reverts and uses the previous successful build.

Could you please ensure that the required header files are added to the Paths and Symbols under C/C++ General settings in the project properties? Also, it would be nice to do a project cleaning and compile again. 

Cleaning ProjectCleaning Project

 

Mohammad MORADI
ST Software Developer | TouchGFX

Hi Mohammad,

It doesn't seem to matter whether I run "Clean Project" prior to "Build Project".  In the current state, the IDE runs two compilation flows regardless.

Since the Console is cleared and reset by the second compilation flow, I can't capture the Console of the first build very well.  The log file also doesn't show the first build output. From what I can tell as the Console flies by, the first build appears to do `make -j8 all` just like the second build...  But for some reason it has errors while the second does not.  

I confirmed the project paths are correct (else I don't think the second build would succeed).

I tried disabling the Scanner Configuration Builder, but didn't seem to make a difference:

ttnickb_0-1724161882256.png

 

In the STM32U5G9J DK2 project that TouchGFX Designer creates, make -j16 is used for the STM32CubeIDE project build setting (Parallel build). I'm now a bit suspicious about other possible changes in the project properties. 

STM32U5G9J DK2 TouchGFX Board SetupSTM32U5G9J DK2 TouchGFX Board Setup

Could you please share your project?

 

Mohammad MORADI
ST Software Developer | TouchGFX
ttnickb
Associate III

I cannot share the entire project in its current state since it is proprietary.  Starting a new project from TouchGFX as shown in your screenshot above is basically how I did it initially, and should give the same results if repeatable.

To my knowledge, both the IDE and TouchGFX have always used `-j8` in their compilation.  Snippet of TouchGFX build below:

ttnickb_0-1724238968686.png

The only things I've changed on the IDE project are adding source files in the `.project`, adding include paths, and adding several symbol definitions.

That's understandable.

Yes, TouchGFX uses -j8, however, the default settings for STM32CubeIDE in C/C++ Build -> Behavior should look like this:

Default build settings used by generated project from TouchGFXDefault build settings used by generated project from TouchGFX

Although, I don't think the issue stems from these settings because I'm not able to replicate the issue you are talking about. And, as I mentioned earlier, from the error that you have attached, your custom-added files are not correctly recognized by the compiler. But, I don't understand how the 'second build' can be successful if there was an error in the first one. 

Maybe we can dig into the project privately if it suits you.

Mohammad MORADI
ST Software Developer | TouchGFX

Hi Mohammad, since this isn't highly critical we have just been living with the double compile for now. At some point, sharing the project privately is probably the best bet. I don't have the time to remove all our proprietary code to share here presently.