{"id":4205,"date":"2021-03-23T20:00:06","date_gmt":"2021-03-23T19:00:06","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4205"},"modified":"2025-12-27T16:03:25","modified_gmt":"2025-12-27T15:03:25","slug":"first-steps-with-touchgfx-on-stm32-and-a-dedicated-shield","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/first-steps-with-touchgfx-on-stm32-and-a-dedicated-shield\/","title":{"rendered":"First steps with TouchGFX on STM32 and a dedicated shield"},"content":{"rendered":"\n

Doing graphics on microcontrollers is always a huge challenge. Even more so if it\u2019s supposed to look nice. For years we\u2019ve known simple so\u2011called GFX libraries that let us draw bitmaps or various fonts. However, that\u2019s not enough, because often our GUI still looks like it came from 1990s devices, or even worse. TouchGFX comes to the rescue!<\/p>\n\n\n\n

TouchGFX on STM32<\/h1>\n\n\n\n

What is this mysterious TouchGFX? According to the manufacturer, it\u2019s an advanced software graphics framework optimized for STM32. That wording sounds a bit complicated. What does it mean in simple terms?<\/p>\n\n\n\n

I would say that TouchGFX is essentially a graphics engine for microcontrollers. It uses STM32 microcontroller resources such as the Chrom-ART\u2122 accelerator to efficiently manage what happens on the display.<\/p>\n\n\n\n

TouchGFX includes TouchGFX Designer. It is WYSIWYG software (hard word, huh?) that allows us to design the entire graphical look of our application.<\/p>\n\n\n\n

Not only the look, but also animations, transitions between screens, and behavior when touching the touchscreen panel or pressing defined buttons.<\/p>\n\n\n\n

In this Designer we create the entire GUI, which in terms of appearance is no different from modern creations. It\u2019s said that TouchGFX lets us generate smartphone-like GUIs. Just see for yourself.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

It looks pretty nice, doesn\u2019t it? Wait until you see how it works \ud83d\ude42<\/p>\n\n\n\n

I\u2019ll write about how the whole TouchGFX works in the next articles. Today I\u2019ll focus on running it for the first time.<\/p>\n\n\n\n

Demo platform<\/h2>\n\n\n\n

ST Microelectronics being ST Microelectronics \u2014 they provide ready-made and easy (we\u2019ll see about that) demo programs to run. The same is true for TouchGFX.<\/p>\n\n\n\n

You can run the demos, for example, on STM32 Discovery<\/a> kits with a display. However, today I\u2019ll use another option. Recently ST released a dedicated TouchGFX shield<\/a> for Nucleo-64<\/a> boards.<\/p>\n\n\n\n

This shield<\/a> is meant to show that TouchGFX can also be used on smaller microcontrollers that don\u2019t have many resources like e.g. RAM.<\/p>\n\n\n\n

RAM is very much needed with displays. It\u2019s where all graphics are drawn using buffering. If we don\u2019t have enough RAM, then what?<\/p>\n\n\n\n

TouchGFX supports partial buffering and that\u2019s exactly what the demo uses for the NUCLEO-G071RB<\/a> combined with the X-NUCLEO-GFX01M1 shield<\/a>.<\/p>\n\n\n\n

You can buy a ready-made set in my store. It\u2019s cheaper as a bundle.<\/a>
<\/strong><\/p>\n\n\n

\n
\"touch<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

Let\u2019s run the demo program<\/h2>\n\n\n\n

So let\u2019s move on to waking TouchGFX up for the first time. It would be nice to see it come alive.<\/p>\n\n\n\n

ST has prepared easy-to-run (well\u2026 let\u2019s say) example projects here. However, we need the TouchGFX Designer program.<\/p>\n\n\n\n

Starting from version 4.16.0, this program no longer exists as a separate entity. It was pulled into the Cube extension X-CUBE-TOUCHGFX<\/a>. It\u2019s like a plugin for Cube that makes it easier to integrate a TouchGFX project with a Cube project.<\/p>\n\n\n\n

You can download and unpack it, or you can install it using Cube itself. I recommend installing it from within Cube, because you\u2019ll need it there anyway. However, you need to know where on your computer you have the repository of libraries for Cube.<\/p>\n\n\n\n

After installing it, you\u2019ll need to find the TouchGFX Designer installer in it under the path (Windows) <Repository>\\Packs\\STMicroelectronics\\X-CUBE-TOUCHGFX\\<version>\\Utilities\\PC_Software\\TouchGFXDesigner<\/strong><\/p>\n\n\n\n

A terribly complicated path! As if they couldn\u2019t keep providing the installer separately.<\/p>\n\n\n\n

There is an installer there, so install the program and we move on. Launch the installed TouchGFX Designer. You\u2019ll get a welcome window like this.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

This is the screen for creating a new project. You choose an application template (the hardware it is to run on), and a UI template, i.e. the look. This time we won\u2019t use that. At the top you have a tab like Online Applications. That\u2019s where the demo programs for ST eval boards are, downloaded from the Internet. We go there.<\/p>\n\n\n\n

Now you only have Online Application to choose from. Enter it and find the appropriate demo. In the case of NUCLEO-G071RB<\/a> with the X-NUCLEO-GFX01M1 shield<\/a> it will look like below.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

Click Select. You still need to provide the application name and the path for the project. Here you have freedom \ud83d\ude42 I wouldn\u2019t recommend Polish characters, though, because they are not handled well by CubeIDE and the compiler.<\/p>\n\n\n\n

Once you have everything, click Create.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

At this moment our demo application is being pulled from the ST repository. After that you\u2019ll see the Designer screen.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

<\/p>\n\n\n\n

What you\u2019re looking at is something we\u2019ll deal with another time. There are tons of features here that, even on the day I\u2019m writing this article, I have no idea about.<\/p>\n\n\n\n

You can look around this program. You\u2019ll find, for example, all the images that the demo GUI uses as well as the texts. The main \u201cworkhorse\u201d is the first screen called Canvas, though.<\/p>\n\n\n\n

It\u2019s exactly where you design the entire look of your application. We\u2019ll get to know it intensively. I can\u2019t wait myself \ud83d\ude09<\/p>\n\n\n\n

Alright, but our goal is simply to run the example. On the top right you have 3 buttons.<\/p>\n\n\n\n

    \n
  1. Run Simulator \u2014 runs the simulator of your TouchGFX project. You can test the GUI without flashing it to the microcontroller. Great stuff. In our case there is one problem. We use a joystick on the Shield<\/a> for navigation, so we have no way to move around in the simulator. It will work great in applications with a touchscreen panel.<\/li>\n\n\n\n
  2. Run Target \u2014 I haven\u2019t managed to run this yet. It should work so that we run the project directly from TouchGFX Designer on our evaluation kit.<\/li>\n\n\n\n
  3. Generate Code \u2014 this is what we\u2019re interested in right now. TouchGFX should generate a complete project for CubeIDE, which can then be imported.<\/li>\n<\/ol>\n\n\n\n

    So I try to generate. A blue bar should appear at the bottom of the window, indicating code generation. When it finishes \u2014 you can open STM32CubeIDE. Only which one? Unfortunately it\u2019s hard to find a document that says which CubeIDE is appropriate for projects from a given TouchGFX Designer version.<\/p>\n\n\n\n

    But, but, but! This applies if you install those two tools separately. If you installed TouchGFX Designer by pulling the add-on in CubeIDE, it should all work together.<\/p>\n\n\n\n

    I have the STM32Cube IDE 1.6.0 + TouchGFX Designer 4.16.0 set. Let\u2019s launch CubeIDE and go.<\/p>\n\n\n\n

    As the Workspace, choose the one you entered in TouchGFX Designer at the very beginning. Then import the project generated by TouchGFX Designer.<\/p>\n\n\n\n

    Now an important thing. When trying to run the Cube file do not update the HAL libraries! Click Continue. Do not click Migrate!<\/strong><\/p>\n\n\n\n

    Why? We use HAL for STM32G0, because that\u2019s what my Nucleo is. The project was written for HAL FW_G0 V1.3.0. The latest V1.4.1 has a horrible bug in the register definitions and you have to paste a few definitions into the headers\u2026<\/p>\n\n\n\n

    It\u2019s not worth bending over backwards \ud83d\ude42 Let\u2019s wait until they fix it.<\/p>\n\n\n\n

    After importing and launching Cube, we see a view like this.<\/p>\n\n\n

    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    On the left we see a few additional elements that you don\u2019t have when creating a bare project in CubeMX.<\/p>\n\n\n\n

    First, we see folders like generated, gui, TouchGFX<\/em>. These are things generated by TouchGFX Designer, as well as the TouchGFX library itself.<\/p>\n\n\n\n

    In these generated things there are headers informing where images and fonts are located, and also what our screens in the application look like.<\/p>\n\n\n\n

    Below there is one more cool folder with the mysterious name MB1642B. This is the code for the Shield with the display. This folder contains the display driver, SPI Flash memory, and joystick.<\/p>\n\n\n\n

    We\u2019ll get to that later, but in short: for the TouchGFX engine you need to provide exactly such drivers. This engine has to know how to interact with the display and the Flash memory in order to work properly. In the future we\u2019ll try to write such a driver ourselves.<\/p>\n\n\n\n

    Before we run the code, I have one more note. I always repeat that you should tick in Cube \u201cGenerate peripheral initialization as a pair of \u2018.c\/.h\u2019 files per peripheral\u201d. It allows you to keep better readability of the project.<\/p>\n\n\n\n

    For demo programs we do not tick it.<\/strong> Such splitting unfortunately breaks the example code written by ST. They refer to files that are created exactly in the way we get after generating in TouchGFX Designer, and it\u2019s better not to touch it.<\/p>\n\n\n\n

    Problem with generating bitmaps<\/h2>\n\n\n\n

    Unfortunately, I\u2019m struggling with quite a big problem. If I create yet another project in TouchGFX Designer based on the online example \u2014 headers for images are not created.<\/p>\n\n\n\n

    It works nicely the first time, when I have a fresh installation. With each subsequent one \u2014 I get the following compilation error of the generated project.<\/p>\n\n\n

    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    No image definitions exist in the project. I reported the error to ST, but they can\u2019t reproduce it. Let me know if you also have such problems.<\/p>\n\n\n\n

    Maybe it won\u2019t happen with other projects\u2026<\/p>\n\n\n\n

    Issue reported on the forum HERE<\/a><\/p>\n\n\n\n

    External Loader Flash SPI<\/h2>\n\n\n\n

    If everything succeeded, you can build the project. You\u2019d probably like to flash it to the microcontroller already, but no! It still won\u2019t work.<\/p>\n\n\n\n

    TouchGFX uses external Flash memory where it stores all images. For the program to work correctly, those images have to be placed there.<\/p>\n\n\n\n

    But how do you do that? After all, it\u2019s SPI memory connected to the microcontroller?<\/p>\n\n\n\n

    Here ST developed something some time ago called External Loader. While programming the microcontroller, we can also program the Flash memory connected via SPI.<\/p>\n\n\n\n

    It\u2019s a great solution and I will definitely want to practice it on my own examples. The problem is that a single loader is dedicated to a single microcontroller and a specific hardware configuration.<\/p>\n\n\n\n

    It\u2019s a small firmware that lets you transfer data coming from ST-Link to SPI Flash (or another memory).<\/p>\n\n\n\n

    You need to tell the script that loads our program that it must use the External Loader.<\/p>\n\n\n\n

    For our example it is located in the project folder <Project>\\gcc and it is the file MX25L6433F_STM32G071B_NUCLEO.stldr<\/strong><\/p>\n\n\n\n

    We need to copy it to CubeIDE plugins.<\/strong> For me it\u2019s under the path <installed CubeIDE>\\plugins\\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.6.0.202101291314\\tools\\bin\\ExternalLoader<\/p>\n\n\n\n

    Again, an inhuman path, right? \ud83d\ude42<\/p>\n\n\n\n

    Paste this file into that location and return to CubeIDE. Launch the debug configuration.<\/p>\n\n\n

    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    You now need to point to the file you copied. Go into the project debug configuration, then the Debugger<\/em> tab, and at the very bottom you have the Misc.<\/em> section.<\/p>\n\n\n\n

    Tick the checkbox next to External Loader<\/em> (if it\u2019s not already ticked). You should see some file that was assigned to the project. That loader is outdated and you need to choose the new one you copied.<\/p>\n\n\n\n

    Press Scan and select your file. In the screenshot below you have all those elements marked.<\/p>\n\n\n

    \n
    \"\"<\/a><\/figure>\n<\/div>\n\n\n

    Save the configuration \u2014 via Apply \u2014 and run debug.<\/p>\n\n\n\n

    Demo in action<\/h2>\n\n\n\n

    Now the program and the contents of the external SPI Flash should be programmed. You\u2019ll see during flashing when the External Loader is executed. It\u2019s quite distinctive.<\/p>\n\n\n\n

    The whole flashing process takes a bit longer due to the external Flash.<\/p>\n\n\n\n

    However, when everything succeeds, you can run the program. You\u2019ll see a beautiful demo prepared for our Shield. I recorded a short video showing the program in action.<\/p>\n\n\n\n