STM32H7B3I-DK -  DISCOVERY KIT - Review

Table of contents

RoadTest: STM32H7B3I-DK -  DISCOVERY KIT

Author: abyraj

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?: The STM32MP157C, STM32H743I-EVAL

What were the biggest problems encountered?: The toolchain is a little difficult to manage with and the STMOD+ connector was not fitting as expected. Configuring STM32IDE and TouchGFX together takes up more time in the project creation. The add-on board cannot be used due to poor fitting.

Detailed Review:

Hi all,

 

This is my first ever road test review and I would like to present my work on the STM32H7B3I development board. I was always interested in STM32 boards and am still learning from the cool board given by ST.

The board presents itself as good potential candidate for industrial control and display solution for robotics and automation.  The FreeRTOS operating system used in the STM32IDE along with Touch GGX Designer offers a freeware solution for the design of graphics and RTOS based control.

 

Hardware used: STM32H7B3LI board, USB to serial converter, Xbee, arduino, 2.4 GHZ antennas

 

Software used: STM32IDE (1.4.2), TouchGFX Designer (4.14.0)

 

  1. Quick GUI test using Touch GFX designer.

This is a very simple way of making a GUI using the TouchGFX designer. First launch the window and add a new application by clicking on the Application template

Select STM32H7B3I-DK  and click create a new project.

image

 

The widgets and additional screens can be created from the menus on the left side of the designer screen and interactions and properties of widgets are available on the right side. Here, I have added a button on the black box area. 

image

For changing the button properties/colour of the screen, I can select the interactions menu, which will appear on clicking the button object. My intention is to change the screen colour to white on pressing the button.

 

image

 

There are finally 3 steps before finishing the project in this step:

 

  1. Run simulator: It will run the simulated GUI inside the software.
  2. Generate code: The necessary folders and ioc file will be generated by pressing the code generation button. The files can be viewed by clicking the browse code option at the bottom right corner.
  3. Run Target: When the run target option is selected, the machine code will be flashed into the controller and the code will run smoothly showing the GUI screen .

 

image

image

When the run target option is selected, the machine code will be flashed into the controller and the code will run smoothly showing the GUI screen .

 

2- Configuring STM32cube IDE with the Touch GFX designer

This is the area in which we need to watch out. The files generated by the TouchGFX contains all the necessary files which may not be present in the folders of STM32IDE generated project.  So some tweaks are needed here regarding this. Close the TouchGFX Designer and open the STM32 CubeIDE and create a new project by choosing from existing ioc file option.

image

Open the ioc file created in the TouchGFX folder and rename the project in new name. Click finish and create the new project. Press migrate for the migration option and click ok for the IP warning window.

 

TWEAKS NEEDED TO BE DONE AT THIS STAGE:

 

At this stage, there are very important points to be considered. Although that has been covered by other road testers, I would like to bring out them for a further warning to the reader:

 

  1. Avoiding software hang up by changing the RCC Power scale value to 0:

 

This is a very important step. If you don’t change RCC Voltage scale value in the controller configuration, the program can easily crash . Do this before proceeding to the next stage. Voltage scale value is zero.

image

 

2  - Adding the correct touch controller files from Touch GFX.

 

The TouchGFX Designer creates the necessary files but after the creation of project in the STMCubeIDE, it can be found out that the necessary functions are lacking in the generated files. So they gave to be copied over to the project folder. Go to the original TouchGFX folder  C:\TouchGFXProjects\Test_Application\TouchGFX\target and copy the four files( TouchFXHAL and STM32TouchController files )as in the picture to the project folder and paste in the TouchGFX-----generated folder.

 

image

image

 

 

You can overwrite the files as you paste them. Just give overwrite all in the window,

 

3) Adding the missing files for the project.

 

Now there needs to some important header files that needs to be added for a clean build process. This are needed in two folders called Common and Drivers in the project tree. The files are actually present in the repository section of the STM32Cube software but I had to manually add them to the project for a correct build. This is further clarified by fellow road testers (thanks guys ) in several sources and the experienced programmers in several videos. Although I am not going to open the topic again, I would like to point out the necessary files needed for a good compilation without errors.

 

image

 

image

 

So I copy the files every time a new project is created. The _conf.h is a slight modification needed in some of the files in each of these folders.

 

Also a slight edit is needed in the file mx25lm51245g_conf.h as follows.

 

/**
  ******************************************************************************
  * @file    mx25lm51245g_conf.h
  * @author  MCD Application Team
  * @brief   MX25LM51245G OctoSPI memory configuration template file.
  *          This file should be copied to the application folder and renamed
  *          to mx25lm51245g_conf.h
  ******************************************************************************
  * @attention
  *
  * <h2><center>© Copyright (c) 2018 STMicroelectronics.
  * All rights reserved.</center></h2>
  *
  * This software component is licensed by ST under BSD 3-Clause license,
  * the "License"; You may not use this file except in compliance with the
  * License. You may obtain a copy of the License at:
  *                        opensource.org/licenses/BSD-3-Clause
  *
  ******************************************************************************
  */


/* Define to prevent recursive inclusion -------------------------------------*/
#ifndef MX25LM51245G_CONF_H
#define MX25LM51245G_CONF_H


#ifdef __cplusplus
 extern "C" {
#endif


/* Includes ------------------------------------------------------------------*/


#include "stm32h7xx_hal.h"


/** @addtogroup BSP
  * @{
  */
#define CONF_OSPI_ODS                MX25LM51245G_CR_ODS_24   /* MX25LM51245G Output Driver Strength */


#define DUMMY_CYCLES_READ            8U
#define DUMMY_CYCLES_READ_OCTAL      6U
#define DUMMY_CYCLES_READ_OCTAL_DTR  6U
#define DUMMY_CYCLES_REG_OCTAL       4U
#define DUMMY_CYCLES_REG_OCTAL_DTR   5U


/**
  * @}
  */


#ifdef __cplusplus
}
#endif


#endif /* MX25LM51245G_CONF_H */


/************************ (C) COPYRIGHT STMicroelectronics *****END OF FILE****/

 

The filename should be included for resolving errors in the compilation.

After the three stages, there shouldn’t be any errors for compiling the project and a good build can be done. After compilation, press the debug option and system will flash the debug code to the controller. The paly button needs to be pressed for resuming the code from the breakpoint at MPUConfig area.

 

image

 

Project1: Touch-based screen change and onboard led control:

 

This project shows the capability of the STM32 board to control the hardware led on board. My goal was to control the LD2 led on the board. So I created two buttons and two virtual functions and two interactions. One button will light up the led and the other will light off the led. Along with, the screen colour will also change. The virtual functions can be created from the TouchGFXDesigner while they are defined and declared in the STM32Cube IDE.

 

image

 

The two virtual functions will be declared in the screenViewbase.hpp file in the GUI folder of TouchGFX folder and the function definition will be given in the screenView.cpp file

 

#ifndef SCREENVIEW_HPP
#define SCREENVIEW_HPP


#include <gui_generated/screen_screen/screenViewBase.hpp>
#include <gui/screen_screen/screenPresenter.hpp>
#include "stm32h7xx.h"


class screenView : public screenViewBase
{
public:
    screenView();
    virtual ~screenView() {}
    virtual void setupScreen();
    virtual void tearDownScreen();
    virtual void led_toggle();
    virtual void led_off();
protected:
};


#endif // SCREENVIEW_HPP










The function definition is in the screenView.cpp file in the GUI folder of TouchGFX folder

#include <gui/screen_screen/screenView.hpp>
#include"stm32h7xx_hal_gpio.h"
#include"stm32h7xx.h"
#include "cmsis_os.h"


screenView::screenView()
{


}


void screenView::setupScreen()
{
    screenViewBase::setupScreen();
}


void screenView::tearDownScreen()
{
    screenViewBase::tearDownScreen();
}


void screenView::led_toggle()
{
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_2,GPIO_PIN_SET);
}


void screenView::led_off()
{
HAL_GPIO_WritePin(GPIOG,GPIO_PIN_2,GPIO_PIN_RESET);


}

After compilation and debugging, the application works smoothly without any problems.

 

Project 2: HMI based Serial port control switch

 

This project involved a remote wireless-based solution for activating a remote microcontroller system. The STM32 board was used as a transmitter with the HMI interface consisting of two buttons. One button will send a char value of 'a' and the other will send a random value of characters. The wireless transmission is through Xbee and an arduino on the other end will receive and decode the values.

 

 

 

image

USART2 was set as an Asynchronous transmitter at 9600 baud rate and two virtual functions were used. The functions will correspond to the handlers of the two buttons. Since other pins couldn't be used, UART2 was taken. This corresponds to PD5 and PD6 on the STMod+ connector.


imageimage

The 9600 baud rate was used to match the Xbee Frequency. Bridging is to be done for line contact with the pins for the UART at 9 and 11 bridges

#include <gui/screen_screen/screenView.hpp>
#include "main.h"
#include "cmsis_os.h"
#include<string.h>
#include <stm32h7xx_hal_conf.h>


UART_HandleTypeDef huart2;




screenView::screenView()
{


}


void screenView::setupScreen()
{
    screenViewBase::setupScreen();
}


void screenView::tearDownScreen()
{
    screenViewBase::tearDownScreen();
}


void screenView::senda()
{
HAL_UART_Transmit(&huart2,(uint8_t*)"a",1,100);
}




void screenView::sendstring()
{
HAL_UART_Transmit(&huart2,(uint8_t*)"STRING",7,100);
}

For connecting the Xbee pins to the UART, I improvised by using led lead pins as jumper pins for the STMod connector. The connector is at a rather difficult position and needs an improvisation.

 

imageimage

On the other end, the arduino is programmed to light 13th led after receiving a character of 'a' over the zig bee.

char val;


void setup() {
  Serial.begin(9600); 
  pinMode(13,OUTPUT);
}


void loop() 
{
  
  if (Serial.available()> 0)
  {
    
    val=Serial.read();  
    if(val=='a')
    {
      digitalWrite(13,HIGH);
    }
    if(val!='a')
    {
      digitalWrite(13,LOW);
    }
  }
}

 

image

 

I've posted the final video of the working HMI device.

 

 

Overall Verdict :

 

This is one of the best boards with lots of functionality. Although the learning curve is a little bit time taking, I consider its worth it. I need to explore it to the fullest extent and would like to experiment more with the added features and more RTOS based content. The add-on board need to have a rigorous mechanical analysis before production but apart from that, this board is a marvel to work with. I would like to try out TouchGFX framework with my other boards.

Anonymous
  • Hi Jon,

     

    The question was not asked by me. I think it was posted by our fellow road tester, sytran. There seem to be some issues in the software but I hope it'll be fixed in the upcoming versions.

     

    Aby

  • Nice review.  It is interesting the different approaches to the STM32H7B3i-DK RoadTest.

     

    You posted a question on Jan's Slack channel for the RoadTest regarding the naming of the .ioc file and why I set it to STM32H7B3I_DISCO.ioc rather than STM32H7B3I-DK.ioc as was created by TouchGFX.  I am not sure it was fixed in a newer version of the software applications, but when I set it to STM32H7B3I-DK.ioc, I was getting a bunch of compiler errors where it was looking for STM32H7B3I_DISCO.ioc which makes sense since the project name that TouchGFX set is STM32H7B3I_DISCO.

    However, you still need the STM32H7B3I-DK.ioc since TouchFGX is expecting this.  I did not track down where it is setting this so I just left it with the two files.

     

    This seems like an inconsistency with the software and something I did post on the STM Community forum as an issue, among other things.

     

    Jon