Skip to main content
GMeta.1
GMeta.1
Associate III
October 18, 2024
Solved

Linker errors updating from older touchgfx

  • October 18, 2024
  • 1 reply
  • 1232 views

So I bit the bullet and upgraded my touchgfx from 4.19.1 to 4.24.1 because the older version was unusable in that it locked up as soon as you looked at it.

Now I have several linker errors after I have generated code from the designer in my stm32cubeide project:

undefined reference to `touchgfx::paint::rgb565::lineFromColor(unsigned short*, unsigned int, unsigned long, unsigned char, unsigned long)'

This post here seemed to have the same problem but I don't understand why it mentioned cubemx? Surely when I click on F4 from designer it generates all the code needed for my stm32cubeIDE project? Or at least it used to. CubeMX is dealing with .ioc files which my project doesn't have, I have a .cproject which opens with stm32cubeide.

There is talk of 'regenerating the files' from the IDE. What does this mean? A clean build or a refresh?

How do I somehow update my cubeIDE to match the new version of designer (this is what I want)?

This is why I don't normally update IDEs halfway through a project because now I am stuck in limbo and cannot move forward. I shudder to think what will happen when I try and build my simulator build using Visual Studio because that will probably be broken as well. These ST tools are a nightmare to work with especially the ones that generate files for other IDEs.

 

Best answer by GMeta.1

Hi.

Thanks for taking the time to reply. I guess the reason I don't have an .ioc file is that the project was originally part of a package from an EDT smart display with an STM32F746 device on. I guess they had already created all the BSP type stuff based on their hardware. It's been so many months or couple of years even since I started this, I can't remember how it started.

I have got something working but not sure how reliable. I noticed in the release notes for touchgfx that it mentioned the same linker errors:

https://support.touchgfx.com/docs/miscellaneous/known-issues

It's recommended solution was to add the following header declarations in any .cpp file thusL

#include <touchgfx/hal/Paint.hpp>
#include <touchgfx/hal/PaintRGB565Impl.hpp> // 16bpp painting routines
#include <touchgfx/hal/PaintRGB888Impl.hpp> // 24bpp painting routines

I might still try your recommendation using the STM32 I have although I think I'll probably end up in a worse state than before. It's a shame touchgfx 4.19.1 was so unstable because I had no other reason to upgrade the tools for new features etc.

1 reply

M
Mohammad MORADI ESFAHANIASL
ST Employee
October 18, 2024

Hello @GMeta.1,

You need the latest versions of STM32CubeMX and STM32CubeIDE to ensure the best compatibility between your project files. When you use TouchGFX 4.24.1, the generated files for a TouchGFX Board Setup (TBS) are also based on the latest version of STM32CubeMX since TouchGFX and STM32CubeMX are tightly coupled. 

To be honest, I am a bit confused by your statement that you are using TouchGFX in your project without an .ioc file. I assume you already have a project in TouchGFX 4.19.1 and you want to upgrade it to 4.24.1. 

First, create a backup of your old project, then right-click on the .touchgfx file and open it with TouchGFX 4.24.1.
Then, open a new instance of TouchGFX 4.24.1, select the platform that you are developing on (for instance, STM32F469I Disco), and create a project:

STM32F469I Disco TBSSTM32F469I Disco TBS

After that, click on Edit -> Import -> GUI. In the new opened window, click Browse and look for the project you converted to TouchGFX 4.24.1:

Import GUIImport GUI

Now, you have your GUI in TouchGFX 4.24.1, and you should be able to run the simulator with no issues. 
It is worth mentioning that you need to reapply the settings and custom code you have for the hardware parts (code related to the main.c file, UART connections, etc.)

I hope this helps you! 
Don't hesitate to ask more questions if you have any

GMeta.1
GMeta.1AuthorBest answer
Associate III
October 18, 2024

Hi.

Thanks for taking the time to reply. I guess the reason I don't have an .ioc file is that the project was originally part of a package from an EDT smart display with an STM32F746 device on. I guess they had already created all the BSP type stuff based on their hardware. It's been so many months or couple of years even since I started this, I can't remember how it started.

I have got something working but not sure how reliable. I noticed in the release notes for touchgfx that it mentioned the same linker errors:

https://support.touchgfx.com/docs/miscellaneous/known-issues

It's recommended solution was to add the following header declarations in any .cpp file thusL

#include <touchgfx/hal/Paint.hpp>
#include <touchgfx/hal/PaintRGB565Impl.hpp> // 16bpp painting routines
#include <touchgfx/hal/PaintRGB888Impl.hpp> // 24bpp painting routines

I might still try your recommendation using the STM32 I have although I think I'll probably end up in a worse state than before. It's a shame touchgfx 4.19.1 was so unstable because I had no other reason to upgrade the tools for new features etc.

M
Mohammad MORADI ESFAHANIASL
ST Employee
October 21, 2024

Oh, I see. That explains the lack of a .ioc in your project to some degree. So, if you are using one of EDT's smart displays, you cannot use the board setup for STM32F746G Discovery Kit. 

It would be better if you could contact them regarding the .ioc file.

I'm sorry about the inconvenience, but I hope the project that you are running now does not cause any trouble, and that you get relevant support from EDT. 

Let me know if I can help more!

Best regards,

Terms & ConditionsAccessibility statement