Table of contents


Author: Jan Cumps

Creation date:

Evaluation Type: Development Boards & Tools

Did you receive all parts the manufacturer stated would be included in the package?: True

What other parts do you consider comparable to this product?: Othe controllers with an LCD and Touch interface. Renesas RX65N

What were the biggest problems encountered?: Toolchain and version stability. Connecting the fan-out board.

Detailed Review:



The Development Kit


The STM32H7 is a well equipped microcontroller. Fast, with a lot of memory and a rich set of peripherals.

The development kit gives you access to many of the goodies.The controller is clocked at 280 MHz. You have access to several of the typical GPIO,  I2C, SPI, UART ports.

A touch screen is integrated, and an extra memory IC. That makes the board a good candidate to test the controller's graphic capabilities. And they broke out a CAN bus.

The board design is neat, the build quality flawless.

The board documentation is detailed, but even though almost all inf about the board is available there, it's not written in an intuitive style. You need to work through it to understand the design.


I'll start with the hot potato: what worked and what didn't. Because the start isn't smooth.




The controller is top notch. The options on the board offer a great way to test many of them.

The LCD screen with touch support is a good choice. Big enough to do decent work. And the controller resources allow for a responsive application.


The CubeIDE is a good Eclipse implementation. It follows the traditional IDE ways of working closely.

The MX configurator, that initialises the hardware and the hardware software, is easy to use.  Compared to the tools of other tool chains, this one is at the top edge.

The HAL and TouchGFX APIs are neat, clean and at a good abstraction layer. I never used STM's layers but it was easy to adapt.

Good granularity, clear function naming. Easy to get a standard module working. Not too hard to get UART with interrupts working.

Easy way of importing examples into the IDE. Easy to allocate hardware, controller pads. Most modules easy to configure .

Many examples. For the peripherals and for the graphical engine. They cover the majority of the controller and graphic part.

In particular those demos that show how to manage the limited memory with rich graphic content are excellent.




The overall stability and ease-of-use of the tool chain is good. TouchGFX designer - a program I never used before - is easy to work with.

With good examples and extensive documentation. Don't forget to click the breakout links in the documentation.

There's useful info hidden there. And links to downloadable examples that aren't covered in the usual documentation and in the IDE repository.




A lot at the start. More than what I typically experience when using a new family or tool chain.

There were hurdles when evaluating the controller. The most obvious one is the fan-out board that's included in the package.

It does not fit. There is a Grove connector on the fan-out PCB that collides with the fixed WiFi board on the main board.

For the road tester that's an indication that the supplier never tried to mate the two parts of the kit together..


I installed the official latest versions of the CubeIDE and Firmware package for this controller. And the matching TouchGFX Designer.

There are several incompatibility issues between those released versions.

This makes me thing that ST never tried to create a fresh project for the current released toolchain.

A simple Hello World! with the LCD and a button would have shown the experts that the integration is not ok in this release.

It caused a significant and unnecessary learning ramp for me as new user.

I didn't struggle with the tool concepts. I struggled with incompatibilities, inconsistencies and bugs.

It's a known thing with TouchGFX and ST controllers it seems. I've watched several video on youtube that show a TouchGFX howto - older versions and the one-but-latest.

Vloggers spend a bit of time to configure the tools as per documentation. Then the remainder of the video is spent copying code over from several locations, fixing missing/incompatible code parts manually, ...





Latest version of CubeIDE needs TouchGFX version 1.14. The latest  firmware versioncis 1.8. But TouchGFX 1.14  Designer creates Firmware 1.6 code.

TouchGFX Designer 1.14 creates projects that aren't compatible with CubeIDE Mx (it creates an .ioc file but it does not integrate in CubeICE project).

CubeIDE Mx - if you use an existing configuration file - generates TouchGFX projects with missing code parts that render a project without working  LCD and touch screen.

I had to manually add missing virtual function declarations and implementations because the wizards did not create them.

Al is fixable, but it takes sleuthing. That's why I wrote STM32H7B3I - ... Pt 1: Screen Works  and STM32H7B3I... Pt 2: Touch Works.

I also experienced that if you start a fresh CubeIDE Mx with Generator 1.14 project with firmware 1.8 and then use TouchGFX Designer 1.14 to supplement the graphical integration, you end with many compile errors.

I didn't try to find out what they were.


Examples are ported from older versions - even though they are part of the Firmware 1.8 / TouchGfx 1.14 package. They build successful and run correctly. But don't reflect the experience of starting a new project.

As mentioned above, they have issues with the Mx configurator and the debugger scripts that is loaded with those examples.


The WiFi does not seem to be working.I have a fairly typical setup (2.4 and 5.0, WPE, broadcasted SSID, strong signal), but the module fails to connect to my network.

The on-board demo detects it but fails to connect. I leave it to my fellow testers to dive into that.

It seems to be related with the Out of Box example. If I test the latest version (1.8.0) of the Cloud and Weather example, the WiFi module connects to my access point and reaches the internet.



Detailed Review


Building an Application


Thanks to the good integration of freeRTOS (the CMSIS flavour) in the configuration and designer, it's not hard to build a maintainable application.

I was interested in a project that provides a touch screen GUI for existing hardware. With the focus on loose coupling and good peripheral usage.

Drawing a GUI and setting out the integration points between GUI and the backend system was easy. I used the Designer to draw the elements and provision integration points.

Then used a very good document and example to tie the user interface with the instrument logic.

This documentation is rich and well explained. An excellent guide to graphic development for embedded solutions.



image source: mock of the GUI I build for this road test, run in TouchGFX Simulator


I've documented my steps from startup to getting a working integration in a set of 79 blogs:


Related Posts
First Experience with CubeIDE
Create a TouchGFX Project with support for the Designer, CubeIDE and Debugger - Pt 1: Screen Works
Create a TouchGFX Project with support for the Designer, CubeIDE and Debugger - Pt 2: Touch Works
TouchGFX Simple Example: react on a button click
USB, freeRTOS ,Task Notifications and Interrupts
the Development Kit STMod+ Connector and Using UART2
TouchGFX Application Framework: Model, View, Presentation, Message Queue
TouchGFX Application Framework: A Mock GUI - Show Statuses, Switch Screens
TouchGFX Application Framework: MVP and the ModelListener
Write a CubeIDE MX application: Hardware Cryptography with DMA



What I tested there was building the GUI. React on a user click on the touchpad.

Update a widget based on changed data.

Setting up a serial communication with interrupt support.

Rich RTOS features like inter-task notification, messaging, scheduling and interrupt handling.

Building a scalable and fast layer between presentation (touch screen) and business (electronic instrument).

Investigate the excellent Model - View - Presentation pattern that TouchGFX uses.




This was a great experience. The RTOS integration is well implemented, and is a good glue between hardware parts, GUI, processing power.

The documentation made me learn some advanced concepts that I hadn't sen in a manufacturer's guide before. Not the easy way out, but sound design with clean integrations.


video: testimony, showcasing the application




In the project I used, I was supported by the good hardware decisions made on the kit.

Almost every signal that you're interested in is available. Great for evaluating the capabilities.

Some connection pins can be connected to more than one controller pad. In that case, the PCB provides solder bridges.

That's a good way to provide access to more signals than what would be physically possible on this board otherwise.

As an evaluator, you'll most likely want to check the options for the STmod+connector. There are many options that you configure by making and breaking bridges.



image source: development kit user guide from STmicroelectronics



Jumpers make it easy to run the board in isolation, without the debugger. You can select a number of power inputs. 5 V regulated or a 7-12 V supply.

There's easy access to CAN, I2C, UART and SPI externally. There are audio in/out connectors and a SD card holder.

The Arduino headers are a booster to evaluate how the controller works together with other hardware (3V3).

Many suppliers have evaluation kits with this footprint and you can easily evaluate how they work with the controller.




The kit has an on-board STLink debugger. Supported from the IDE, from the TouchGFX designer, from the STMCube programmer and command line.

A good programmer with excellent GDB support (including debug scripting).


Tool Chain and Libraries


A wealth: there's the IDE and the GNU tool chain itself. Well integrated.

The HAL layer is - in my opinion - good. Granularity and abstraction level are so that they are easy to use without estranging you from the underlying hardware.

The Mx configurator helps to reserve the modules and configure them. The driver code that's generated is overall clean.


The Information Center screen is a good way to get started with the board. Either to kick off a brand new project, or to import one of the existing examples.

The search functionality is great - you can look for examples based on your board, controller, the peripheral you want to use.

I have used this mechanism to build my road test project.



image source: TouchGFX documentation


The TouchGFX designer and libs are also good. They use C++ in a healthy way. Kudos for using an OO library. The model-view-presentation pattern is well implemented.

The integration with freeRTOS features (and general RTOS principles) is up there with the best.

There's a natural blend between ST's own HAL, the TouchGFX architecture and freeRTOS. All connecting together at a good level.

STmicroelectronics also integrate with emWin. A graphic solution I've used in the past. I didn't focus on it in my review (I tested the example) because I focused on TouchGFX - but it's an excellent GUI lib and design solution too.




Power Profile: Standby and Normal


You can measure the current consumed by the controller, by replacing jumper JP2 with a current meter.

The only current going to that trace is the MPU supply. The measurement isn't influenced by any external electronics.

I've used a µCurrent in mA range to avoid voltage drop while measuring. In this setup, the maximum burden voltage was below 5mV. That's ok for a 3.3V supply.


I loaded the STM32 firmware written for this test: PWR_STANDBY.


After a reset (or wake-up from STANDBY mode), LED2 is ON and MCU is in RUN mode.
The system enters STANDBY mode after 5s, LED2 is OFF.
A rising edge on WAKEUP pin WKUP4 (User Button) PC.13 will wake-up the system from STANDBY.
Alternatively, an external RESET of the board will lead to a system wake-up as well.
The LED2 blinks once in order to indicate the system was resumed from Standby mode.
These steps are repeated in an infinite loop.


In normal mode, the measured current is approx. 44 mA.

The sleep mode is harder to get stable. I get between 140 and 300 µA.







Road test too short? Not enough pictures? No unboxing?

Please check out the nine separate articles linked in above. They show the experience from nowhere to a real project.

Covered (with photos, videos, cheers and rants):

  • the controller,
  • the board configuration file, the Mx Configurator. HAL provisioning and API use.
  • TouchGFX generator and Designer.
  • freeRTOS concepts such as tasks, queues, notification (semaphore light). Using interrupts with rtos.
  • The TouchGFX abstraction layer.
  • Real world situations
  • a real project and a few demonstration ones. With the project code attached to the blogs. For your review or reuse.


Thank you STmicroelectronics and the element14 road test program for the opportunity to evaluate this great kit.


  • The support for this controller is also decent. Getting started with the IDE, peripherals and freeRTOS (easiest start with an RTOS for me until now)  was not hard. Well supported by examples.

    Understanding the DMA engine was harder. Not unlike other controllers. I still struggle when I have to set up a DMA chain for the TI Hercules controller - the ARM MCU I know best.

    The hardest was getting started with TouchGFX. That may be me. But I think it's made unneccessary hard by integration bugs between CubeIDE, TouchGFX and CubeMX. Let's check the reports of the fellow testers.

    It was not hard to develop with TouchGFX - their documentation is great. It was hard to start a project that was supported by IDE, TouchGFX designer and MX Configurator.

  • I would be much like you. However, as I've been playing with Mbed OS 6 and Mbed Studio, I did notice that many of the ST boards are Mbed compatible and so if using the lastest mbed, you could say that the toolchain and examples are much improved.

  • These days all microcontrollers have great performance and a low price. We're spoiled. I find that what makes one stand out from the other is the quality of the toolchain, documentation and examples. I also found that's not great for ST devices which is why I don't tend to use them.

  •   wrote:


    Excellent review Jan.

    Just out of curiosity, how many hours did you spend with this KIT all in all for this RoadTest?



    I did not count. When I received it, 2 long weekends, Friday - Monday. I wrote my report that last Monday, when everything was still fresh (I think just after the 7th blog post).

    Since then, a few evenings per week. I adapted the report based on experience and added a few blog posts.

    I try to learn a few things while running the test. Time well spent image.

  • Excellent review Jan.

    Just out of curiosity, how many hours did you spend with this KIT all in all for this RoadTest?



  • A mock of a possible GUI for the load



  • Thanks for the offer Jan, but I’ve got a fair bit on at he moment so I wouldn’t want to agree to review then not follow up!  I was originally thinking about it as a potential alternative to a 4duino when I come to write up he firmware for my control board.  I may still do so if I can’t get the 3 processors on my 4duino interacting nicely together.


    it does seem fairly complicated to someone who isn’t that experienced with these things!

  • If you have access to an ST board with LCD and octo-spi support (PM me if you're interested in reviewing the kit once I finished):

       ExtFlashSection : { *(ExtFlashSection) }>QSPI_TGFX
       FontFlashSection : { *(FontFlashSection) }>QSPI_TGFX


    These two sections (a single shared area in the external memory though), defined in the linker/loader script, are available to TouchGFX. You can indicate that a bitmap or font has to go to the external memory by selecting that section in TouchGFX Designer.