RoadTest: STM32H7B3I-DK - DISCOVERY KIT
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 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.
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:
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).
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.
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):
Thank you STmicroelectronics and the element14 road test program for the opportunity to evaluate this great kit.
Top Comments
Very good road test report Jan.
DAB
Good road test Jan, thanks.
MK
Good road test Jan. Would/will you use this to front end your eLoad or stick with the MSP430?