cancel
Showing results for 
Search instead for 
Did you mean: 

Why the CubeIDE can't generate an STM32H747 based project, and why can't generate the TouchGFX also the GUI? (STM32CubeIDE 1.7.0; TouchGFX 4.0.17)

Szabolcs Vass
Associate II

Hi guys,

I want to develop a project, for which needs a display, and i chose the TouchGFX way. I'm using the STM32H747 microcontroller. In TouchGFX exists demos for STM32H747I Disco board, but my application will run on a custom designed board.

So I tried to create a new CubeIDE project also for the STM32H747I Disco board.

Firstly: When i chose the TouchGFX and the FreeRTOS on the CubeMX configurator, and generated them, the CubeIDE couldn't build them because didn't find any headers and references from TouchGFX and FreeRTOS. After i added manually to include path and source location also didn't find any references. (In this time, didn't find, because these files not yet generated from TouchGFX).

Secondly: After i entered to the .touchgfx.part and set up a simple screen, when i tried to generate the GUI teh TouchGFX couldn't generate them. It said:

   "   Post Generate

       touchgfx update_project --project-file=simulator/msvs/Application.vcxproj

       Done

   Post Generate Target

       touchgfx update_project --project-file=../../workOnCard2.ioc --platform=m7

       Unable to locate D:/SVT_work/TouchGFX_Learn/Firmware/workOnCard2/.cproject

       Dual core detected. TouchGFX running on M7

       .project files generated at the root of the application

       Failed

   Failed"

So nor the CubeMX generating isn't working correctly, nor the TouchGFX generator. How can i develop in this way, with thesse tool?

Thirdly: If i try the above processes with a single core H7 microcontroller all generation works fine, and i can modify on both side, the generators doesn't fail.

Fourthly: If i try to use the STM32H747 demos inside of the TouchGFX i can't debug in STM32CubeIDE. This directory structure totally different from the above mentioned new prject.

Can you help me?

Do you have existing solutions for the dual core generations?

Kind regards,

Szabolcs Vass

7 REPLIES 7
Romain DIELEMAN
ST Employee

Hi,

I would recommend to include the STM32CubeIDE tag in your post. The STM32H747 is a dual core which implies that it requires a STM32CubeIDE project for the M4 cortex and one for the M7 cortex (you can see this as you said in the TBS for the STM32H747disco board available in TouchGFX Designer).

I am surprised that you cannot debug in STM32CubeIDE when working with the examples from TouchGFX Designer, it works in my case. Could you share screenshots of your issue ? or share your project ?

My suggestion would be to start your project from STM32CubeMX instead of STM32CubeIDE and then generate a STM32CubeIDE project. I believe this will give you a better project structure.

/Romain

Szabolcs Vass
Associate II

Hi,

Thank you for the fast response. I attached 2 projects. The first one is "MyDemo2" and the second one is "TrialEx". The first one is that i mentioned on the post above, this still can't debug. The picture from the error message also attached(ST.png). After your answer i tried to create another project(TrialEx) from TouchGFX, but this one is debugable. So i can debug it without any problem. I don't know what is the difference between 2 projects.

I will try to start a project from STM32CubeMX and i will return with the response. I have a question: the STM32CubeIDE also involve the STM32CubeMX, why should i start a project from standalone STM32CubeMX? The built-in CubeMx and the standalone version generate the projects with different way?

Br,

Szabolcs

Szabolcs Vass
Associate II

Hi again,

I checked your advice with starting the STM32CubeMx way and this one is working. Thank you for it :)

Meanwhile I detected the main difference between CubeMx generated and CubeIDE generated code.

In the CubeMx at "Project manager" tab, you can check or uncheck the cehckbox "Generate Under Root". If you starts a new project with CubeIDE, there this checkbox is unchangable, and is checked in default. (I attached 2 pictures from the Cube and MX Project manager.)

If this checkbox is checked both the CubeMX and the CubeIDE generates a same directory structure, that the TouchGFX doesn't recognize well, and therefore fails on the gui generating.

The Cube MX way that you advice is working, if you leave unchecked the "Generate Under Root" checkbox.

I have 2 proposals what can solve this problem:

  1. If this is possible, please correct the CubeIDE bug, leaves changable the above mentioned checkbox, and set the default state to uncheck.
  2. If this is easier, correct the TouchGFX to handle both directory structure.

Br,

Szabolcs

Harvey White
Senior III

I'm working on this, having looked at most of the recent answers about TouchGFX and CUBEIDE.

my conclusions are, after a bit of time....

1) TouchGFX and CUBEIDE are not meant to work together.

2) while TouchGFX is meant to work with any number of other compilers, I don't see a "here's your compiler, and here's how to make it work"

3) There seems to be a lot of missing "here's how to make it work"

4) There's a new version (who knows when) of either CUBEMXIDE coming out that *may* fix the problem ( having to do with "compile under root and the resulting software structure"

5) until this is fixed, I'm not sure that there are any ST micro tools that work here. I did try making the project under CUBEMX, and then importing it under CUBEMXIDE. It didn't import well, if at all.

6) there's a project structure difference between compiling under root (which does NOT work with TouchGFX) and not compiling under root (very different project structure and I still haven't gotten it to work).

7) perhaps we need a brain dead "do it like this, and here's why" for a Touch GFX project *with* a defined board and starting with CUBEMX_IDE..... since that's how we are supposed to define projects

I can do most of this with my own software. Know where the bodies are buried, and it follows a "created under root" structure.....

I'd like to tap into the rest of the ST TOUCHGFX system.

Any idea when we get a new version *with* enhancements to make it all work?

Szabolcs Vass
Associate II

I have no other issues related with TouchGFX, at the moment, but if i find any other issue, i come back and indicate.

Hi,

Thank you for the feedback. I would recommend to have a look at the online TouchGFX documentation and the different videos made by ST or other users like HP or Karl. We try to not focus on only one toolchain as not everybody use the same but we do have multiple examples and user guides (most videos only use STM32CubeIDE). The TBS and Board Specific Demos are good source of inspiration to understand how to set up your boards and use the ST Cube Environment. Concerning the "under root" situation I agree it is really confusing and I hope it will be improved, we recommend in our documentation to never generate code under root for "optimal" project structure and to simply ease the process.

Concerning point 5) when you start a project from STM32CubeMX you can generate a STM32CubeIDE project. Why did you try to import it to another project ?

Concerning point 7) we actually recommend to start from STM32CubeMX rather than STM32CubeIDE.

/Romain

I've finally managed to get a working, downloadable TouchGFX project.

I started with the one demo for the 469I, this was a blank screen). I had to add the CUBEPROG. Naturally, your example is for all compilers, so I just left it as is.

As far as "do not generate under root" is concerned, all of my other projects are generated under root, and work rather well. It's TouchGFX that does not work at all when generated under root. Generating under root leaves out the ST directory under the "THIRD PARTY" selection, and even if that were added, I think that the inherent structure built into TouchGFX expects something different.

Looking only at ST tools (others are expensive or limited, and I am doing large projects), there seems to be only CubeIDEMX, and the TouchGFX environment.

concerning importing: I did start with CubeMX, only to find that the project it generated would not import into CubeMXIDE, it seemed to be lacking the .project file amongst perhaps other things. CubeMXIDE said that there wasn't a project there, etc... So I had no luck generating a complete CUBEMXIDE project in CubeMX

As far as generating under root for CubeMXIDE, that's the only option.

Since I generally work with the Nucleo board series (and now the 469I DISCO board), I'm familiar enough with working with the IOC hardware configurator. I did find, and thanks for this, that the DISCO demo project filled in a lot of the gaps on the older BSP driver examples and should make a more coherent project under MXIDE.

As far as the "start here" recommendations, it took me a long while to find them, and even looking at the tutorials on the net, a good while to understand the "baked into the program structure: 'here's how you're going to be using this'" BTW, that's almost never explained for any program. Not necessarily the "how" but the "why".

I have a relatively complex program that allows me to generate graphics screens, and talk to peripherals. I can either talk to a sensor directly or talk to one using packet communications. I should be able to do much the same with any remote display. I wanted to swap my own graphics solution out for yours.