How to Integrate ThreadX with TouchGFX on STM32F746

[Vivek711]

I’m working on an STM32F746-based project. I know how to port ThreadX to this board, and I want to use the ThreadX source available on GitHub. My question is about integrating ThreadX with TouchGFX.

Specifically, I want to understand:

What steps are needed to make TouchGFX run on top of ThreadX?

Do I need to modify the TouchGFX-generated code or middleware when using ThreadX from GitHub?

How should I create and manage the TouchGFX task inside ThreadX?

What is the recommended project structure for combining STM32F7 + ThreadX (GitHub version) + TouchGFX?

Are there any example projects or references for this integration?

Any documentation, sample projects, or practical guidance would be very helpful.

[mƎALLEm]

Hello @Vivek711 and welcome to the ST community,

You can refer to this TouchGFX tutorial link: especially the section ThreadX

[Vivek711]

I have already checked the TouchGFX tutorial, including the ThreadX section.

My requirement is different: I am manually porting ThreadX (from the GitHub source) to the STM32F746, and I want TouchGFX to run on top of this manual port.

Since I am not using the CubeMX-generated ThreadX middleware, I need guidance on:

What TouchGFX OS wrapper or configuration needs to be modified for a custom ThreadX port.

The correct initialization sequence (ThreadX start vs TouchGFX task creation).

How to configure the TouchGFX task, timer, and vsync handling when using a custom ThreadX setup.

Any steps or references for integrating TouchGFX with a manually-ported ThreadX would be very helpful.

[misteralex844]

Enable ThreadX in STM32CubeMX (or add the X-CUBE-AZRTOS ThreadX pack), then regenerate your TouchGFX project with ThreadX selected so the generator creates a GUI task for you; put all TouchGFX HAL/driver init (LTDC, DMA2D, display controller, touch) in the board init before starting the RTOS, create a dedicated high-priority TouchGFX thread (stack and memory pool large enough), and ensure your framebuffers live in non-cached RAM or that you do CPU cache clean/invalidate around DMA transfers (otherwise you’ll see corrupted frames); also set ThreadX tick to 1ms if TouchGFX expects millisecond timing and keep LTDC/DMA2D interrupt priorities lower (numerically higher) than the OS tick so rendering isn’t preempted incorrectly. Follow TouchGFX’s RTOS/ThreadX guide and the TouchGFX Generator instructions for the exact CubeMX options and memory settings, and check community notes about I2C/HAL calls from GUI threads if you use peripherals from the same context.

[Vivek711]

---

@misteralex844 wrote:

Enable ThreadX in STM32CubeMX (or add the X-CUBE-AZRTOS ThreadX pack), then regenerate your TouchGFX project with ThreadX selected so the generator creates a GUI task for you; put all TouchGFX HAL/driver init (LTDC, DMA2D, display controller, touch) in the board init before starting the RTOS, create a dedicated high-priority TouchGFX thread (stack and memory pool large enough), and ensure your framebuffers live in non-cached RAM or that you do CPU cache clean/invalidate around DMA transfers (otherwise you’ll see corrupted frames); also set ThreadX tick to 1ms if TouchGFX expects millisecond timing and keep LTDC/DMA2D interrupt priorities lower (numerically higher) than the OS tick so rendering isn’t preempted incorrectly. Follow TouchGFX’s RTOS/ThreadX guide and the TouchGFX Generator instructions for the exact CubeMX options and memory settings, and check community notes about I2C/HAL calls from GUI threads if you use peripherals from the same context.

---

Thank you for the detailed explanation.

In my case, I am not using STM32CubeMX or the X-CUBE-AZRTOS pack.

I am manually porting ThreadX from the GitHub source and building the project completely without CubeMX.

So I want to understand what minimum integration TouchGFX requires when ThreadX is brought up manually. Specifically:

How to correctly create the TouchGFX task/thread when ThreadX is not Cube-generated.

Which OS wrappers or TouchGFX middleware files must be adjusted for a custom ThreadX port.

What initializations must be done before calling tx_kernel_enter() so that TouchGFX runs correctly.

Any required modifications for framebuffer/cache handling when using a fully manual ThreadX setup.

I understand the Cube workflow, but I need guidance for integrating TouchGFX + manually-ported ThreadX.

Any specific steps or references for a non-CubeMX setup would be very helpful.

[mathiasmarkussen]

How did you get to where you are now? Are you running custom hardware or a discovery kit?

I would advise that you use CubeMX to generate your project to get TouchGFX. If you are using a discovery kit, I would also base the project on the Board Setup for TouchGFX, so you know everything will work.

If that is impractical, because you are already too far with your current project, I would set up a project on the side to copy code from.

Once you have TouchGFX for FreeRTOS in your project, remove FreeRTOS and set TouchGFX to custom OS in CubeMX and regenerate code. You should not need to generate code for touchGFX in CubeMX any more at this point.

To figure out what you need to do from there, I would set up two new projects for STM32U5G9J-DK2. It has board setup for both ThreadX and FreeRTOS out of the box. You can then either compare the projects or go through some manual steps:

In the FreeRTOS project:

Remove FreeRTOS, set TouchGFX OS to custom and generate code. Commit these changes to your version control.

Then set up ThreadX to match the settings in the ThreadX project, and select ThreadX as TouchGFX OS. 

The changes you see in your version control at this point should give you a rough idea about what you need to do in your own project.

[Vivek711]

Thank you for the detailed guidance.

To answer your question:

I am working on the STM32F746 Discovery board, but my project is not CubeMX-based. I have already manually ported ThreadX from the GitHub source, and the system is running correctly. Now I want to integrate TouchGFX on top of this manual ThreadX port.

Using CubeMX for OS generation is not practical in my case because:

My project structure is fully manual (no Cube/HAL init code).

I want to keep the ThreadX port exactly as I built it from GitHub.

I only need to know the required TouchGFX integration layer for ThreadX.

Your suggestion about generating comparison projects is helpful.

What I specifically want to understand is:

Which TouchGFX OS interface or porting layer is required for ThreadX when not using CubeMX?

What exact components from the Cube-generated ThreadX TouchGFX setup must be replicated manually (GUI task creation, message queue, timing functions, etc.)?

What are the minimum required hooks for TouchGFX Scheduler, VSync handling, and task priorities in a pure manual ThreadX environment?

I can compare Cube-generated projects as suggested, but if there is any documentation or summary of the required OS porting layer, it would save a lot of digging.

Thanks again for your help.

[mathiasmarkussen]

I do not believe we supply that information. But in short, as far as I remember, there is a different OS wrapper file compared to FreeRTOS, definition of memory pools for TouchGFX and a thread that calls TouchGFX continously.

I guess all the needed code would actually be the result if you follow the steps I outlined, except setting up ThreadX, then committing, then setting TouchGFX to ThreadX instead of doing that in one step.

There should not be a lot of files to dig through in that case.

[mathiasmarkussen]

Here's a git patch with what I believe to be relevant.