cancel
Showing results for 
Search instead for 
Did you mean: 

Link errors - implementing TouchGFX with MbedOS

George Journeaux
Associate II

I've been attempting to get TouchGFX running with MbedOS. I've got the program compiling but I'm getting some consistent link errors. Any suggestions on this?

Using ARMC6 (6.13) I get the following:

```

[Warning] @0,0: L3912W: Option 'legacyalign' is deprecated.

[Error] @0,0: L6218E: Undefined symbol touchgfx::HAL::instance (referred from BUILD/DISCO_F746NG/ARMC6/Middlewares/ST/touchgfx/framework/source/touchgfx/containers/CacheableContainer.o).

[Error] @0,0: L6218E: Undefined symbol touchgfx::Bitmap::dynamicBitmapGetAddress(unsigned short) (referred from BUILD/DISCO_F746NG/ARMC6/Middlewares/ST/touchgfx/framework/source/touchgfx/containers/CacheableContainer.o).

...

...

Finished: 0 information, 1 warning and 164 error messages.

```

All 164 errors are consistent undefined symbols coming from touchgfx files.

Correct me if I'm wrong, but this seems to be down to static members of a class not being defined in a .cpp that they are used in (Defining these members seems to fix the error)

(Like this: https://stackoverflow.com/questions/185844/how-to-initialize-private-static-members-in-c)

Is there any way other than correcting this in the 164 occurrences? (I'd rather not do this every time the touchgfx libraries are updated)

I've also tried using GCC ARM (9-2019-q4-major) as I thought it may be more compatible and I get the following:

```

[ERROR] c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core_release

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core_release

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core

c:/program files (x86)/gnu tools arm embedded/9 2019-q4-major/bin/../lib/gcc/arm-none-eabi/9.2.1/../../../../arm-none-eabi/bin/ld.exe: cannot find -lchgfx_core_release

collect2.exe: error: ld returned 1 exit status

```

Any ideas?

Thanks!

13 REPLIES 13
Martin KJELDSEN
Chief III

In the last case, for arm-gcc, the linker path has to be wrong in your makefile. How did you create this project?

/Martin

LTimm.1
Associate III

Martin beat me to it. 🙂

We are also using TouchGFX together with Mbed-OS, so can confirm that it's doable and working 🙂

I haven't tried the ARMC6 compiler though, we are using GCC....

Great to hear, @LTimm.1​ ! 🙂 Just out of curiosity, any interesting issues getting this to work? Seeing that CubeMX only supports FreeRTOS /CMSIS OS and the TouchGFX Generator therefor is only able to provide OS Wrapper/Driver for that.

/Martin

Martin KJELDSEN
Chief III

E.g. here's the linker path in our arm-gcc Makefiles (/gcc/Makefile - in the root of an appliation created from an Application Template with the designer)

library_include_paths := $(touchgfx_path)/lib/core/$(platform)/gcc

Where touchgfx_path points to the touchgfx folder, most often in Middleware/ST.

/Martin

Mbed-os is cmsis compatible, so we just used the provided OSWrapper_cmsis.cpp. Can't remember if we needed to do any tweaks. It was minimal if any.

We don't use CubeMX or TouchGFX generator. We started our project before those came along. I started with the STM32L4 demo project that the Designer can generate, and then took the elements I needed from that.

We still use the Designer for all UI updates though.

Perfect. That's a good point, actually. I think that's something i probably missed in the documentation - Emphasizing that any CMSIS compliant OS will work with what's being generated. People may be confused about the fact that Middleware/FreeRTOS in CubeMX says "FreeRTOS" but when you reach the OS configuration in the TouchGFX Generator it says "CMSIS V1" or "CMSIS V2"

@Martin KJELDSEN​ , thanks for the quick response!

I started from a demo project from the TouchGFX designer and took the files I needed. From reading through the touchGFX support documentation I suspected that it was something to do with the linker path, but I have no experience in linkers - probably something worth me reading up on if anyone can recommend anything? - I'll give this a go and let you know!

@LTimm.1​, sounds like you've done this in a similar way.

If you don't use CubeMX, are you setting up the peripherals using the Mbed library functions? - I'd be interested in doing this to have a MbedOSxTouchGFX template that is somewhat compatible with any MbedOS compatible boards.

If you could share a bit more detail on how you set up your project that'd be super helpful!

If we were to remove the dependency on FreeRTOS Middleware we would somehow need to inform users to add the code for their CMSIS compliant OS manually and create the tasks manually as well. But, i guess it could be done in a clean way.

/Martin

Okay, let me know! 🙂 It should be pretty apparent from the Makefile. You just have to locate the library in your project folder

/Martin