Generate Under Root: code gen overwrites lib location in IDE

[DragonSal]

TouchGFX version 4.25.0 CubeMX version 6.17.4*  STMCubeIDE version 2.0.0

*edited version

I created a development environment starting with TouchGFX and used Generate Under Root in CubeMX.  This did a great job of setting up the directory structure without links so that it is easier to navigate in the STM32CubeIDE application.

Part of this process automagically moves the middleware and driver directories from the STM32CubeIDE directory to the root directory.

When the .project file is created by the TouchGFX code generation it handles the movement of all these files and include directories like a champ, except the Properties=>C/C++ Build=>Settings=>MCU/MPU G++ Linker=>Libraries=>Library search path for the libtouchgfx-float-abi-hard.a library.

It sets the path to "${workspace_loc:/STMCubeIDE/Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc}" instead of "${workspace_loc:/${ProjName}/Middlewares/ST/touchgfx/lib/core/cortex_m7/gcc}"

It's a quick fix to edit it to the correct value.  Unfortunately every time you Generate Code in TouchGFX and do a refresh of the project in the STM32CubeIDE application it changes it back.

My question is:  Can this be fixed by the developers in a future release?

I've attached a word document with instructions on how to set up the environment.  I apologize for the overuse of screenshots.  I tried to make it so that the instructions could be followed by myself in six months.  The document was also written with the intention of combining what the IDE gives for a new project on the STM32F769I-DISCO board with what TouchGFX gives for a new project.  The IDE gives no display, and TouchGFX gives no GPIOs besides the display.

Tony

[Osman SOYKURT]

Hello @DragonSal ,

Thank you for the document, I'll review it. However, I would like to understand why you need to select "Generate under root", and what issue you face when you don’t use it.

When TouchGFX generates code, it actually searches for a folder in which it can modify the project file by adding new links, dependencies, and everything needed for correct compilation. For this reason, we have the folders "EWARM", "MDK-ARM", and "STM32CubeIDE".

The EWARM and MDK-ARM toolchains do not have a "Generate under root" option, so it is simpler for us to unify everything at the code generation step by always looking for the project file one level below the root.

I hope this clarifies the reason behind this behavior.

[DragonSal]

Hi @Osman SOYKURT 

I am trying to use the full functionality of the STM32F769I-DISCO board.  As stated at the end of my comments above, "The document was also written with the intention of combining what the IDE gives for a new project on the STM32F769I-DISCO board with what TouchGFX gives for a new project.  The IDE gives no display, and TouchGFX gives no GPIOs besides the display."

I have searched ST documents, tools, community boards, and tutorials to determine how to combine them in an official manner.  What I have found is other people trying to do the same thing with no clear answer on how to do it

I have tried many ways of combining what TouchGFX gives and what the IDE gives so that there is a project that uses the full functionality of the discovery board.  When I use the STM32CubeIDE directory, the header files are set up in the IDE as reference links.  This results in the search for references and definition tools that are part of the IDE to not work.  As a result, you have to manually search through the codeset to find what you want.

When I use "Generate from Root" I am able to use those tools in the IDE because the links are gone.  And honestly, it's just easier to work with the IDE when you can actually see where the code exists instead of having to go through levels of obfuscation.

Using the steps I have given in the document, you can combine the two projects together and have everything working.  It isn't too difficult to do, and there is only one issue that remains.  The issue is with the path to the library being overwritten every time TouchGFX generates code.

If you have an STMicro way to combine the TouchGFX and STMicro IDE tools so that the full functionality of the discovery boards is available, please point me to it.  It would be great to not to have to go through all these extra steps.

I do find it strange that the code and directory paths for everything except that library are properly moved, yet that library directory path is an issue.  The library itself is moved along with the rest of the code.

Regards,

Tony Saladino

[ferro]

Hi @DragonSal 

this might help

https://community.st.com/t5/stm32-mcus-touchgfx-and-gui/touchgfx-application-missing-library-amp-header-files/m-p/876171/highlight/true#M45918

 

[ferro]

@DragonSal 

Or try a simpler fix compared to my previous post.

You need to change project name in .cproject as well - that is where GfxDesigner fetches project name to point to libs.

Go towards the end of .cproject and change 2 places where old project name is

 

 

 

[DragonSal]

Hi @ferro 

Thanks for the suggestions.

I have made the changes to add the relative directory as you suggested in the linked post.  The issue is that when you "Generate code" in TouchGFX, it resets it back to the old, now incorrect, directory.  It removes the relative path.

The line you show in the .cproject file is updated in my .cproject file.  I believe when you update line 3 in the .project file to show the correct name, it will update the .cproject file.  If it doesn't, I just missed it when I documented the steps I took.

Cheers,

Tony Saladino

[ferro]

Hm, try to delete those paths in CubeIDE and run GfxDesigner again.

[ferro]

@DragonSal 

Create build variables pointing to libs so that GfxDesigner does not overwrite.

Example how to create a variable

And now, create linker lib paths using those build variables

"${ProjDirPath}/${LibPathTouchGfxFloatAbiHard}"
"${ProjDirPath}/${LibPathNemaFloatAbiHard}"
"${ProjDirPath}/${LibPathTouchGfxNemaFloatAbiHard}"

Tyou should see this

 

 

[DragonSal]

Hi @ferro 

Thank you very much for your help.  I will be trying the suggestions you have made, but I will not be able to get to them for at least 2 weeks.

I feel like a kid giving excuses, but A) a different project I'm working on has recently become highly visible and I need to focus on that, B) My work computer was replaced and I have no IDEs currently installed on my PC, C) I have major surgery next week and will be out for at least a week.  At least with installing the IDEs you'll know I'm at the latest and greatest.

Your solution looks good and I will try it as soon as I can.  I'll start from scratch using my document and install your steps into it.  Once I verify your solution I will "Accept as Solution"

[ferro]

No worries. I think this might be the best solution, as these custom library paths go under the radar of GfxDesigner.

I also always convert the project to “Under Root” in CubeMX for exactly the reasons you described. So I had to deal with the interaction between CubeIDE, CubeMX, and GfxDesigner. Not for the faint-hearted.