Skip to main content
oekk
Associate
November 19, 2019
Question

STMH743XI-E02 fails to validate NN model on target. LOAD ERROR: STM32 - no connected board(s), invalid firmware or the board should be re-started.

  • November 19, 2019
  • 6 replies
  • 8035 views

Hi, I am trying to deploy a Keras model that fits in the board STMH743XI-E02. In order to do so, I've created the model, and loaded it into the project according to the current documentation.

I've tried to use several USART ports to enable communications with the board, and I've tested the USART communications with an example project that correctly send the data to my terminal. Meaning, that my configuration is correct, at least on the board to use the USART.

But when it comes to use STM32CUBEMX and the AI additional package, after analyzing the model, and validate it on desktop, the following error appears to me, once and again:

LOAD ERROR: STM32 - no connected board(s), invalid firmware or the board should be re-started

  • My last configuration usses USART1 Asynchronous for communications. I'be tried with pins:
    • PB14, PB15
    • PA9, PA10
    • PD8, PD9 (USART3)
  • I've used the validation template on the AI package.
  • The clock is set to 480MHz on the Clock configuration tab.
  • Minimmum Stack size to 0x2000 on the Project Manager tab.
  • The model fits without compression, occuping:
    • 324.78 KBytes Flash
    • 9.37 KBytes RAM
    • 290840 MACC
  • I have my own validation data inputs and outputs and on desktop they work ok.
  • I'm using the latests version of the tools.

My questions are:

  1. Do I need to perform further configuration to generate the code?
  2. What actions do I need to perform to be able to validate the model on target using the UI? Any option to achieve this stage without UI?

Attached, project.ioc, the STMCUBEMX project and the model I've used along with the validation data.

Thank you very much for your time.

This topic has been closed for replies.

6 replies

fauvarque.daniel
ST Employee
November 19, 2019

on this board there are some jumpers to put in the right place to have the USART1 sent to the ST-Link

0690X00000AsDfyQAF.jpgand the USART1 is connected on PB14 and PB15

You should be able to use the automatic validation on the target specifying explicitly USART1 and PB14/PB15 for the ports

Otherwise you can always add the validation AI component to your project, enable USART1 in asynchronous mode, then in AI configure the Platform Settings to USART1, generate the code, flash it on the board then go back to MX to launch the validation on the target without auto generation

I've seen on some boards, after a first connection on the PC there is a need to do a reset by hand for the validation to work correctly.

A good practice is to configure the USART to run at 115200 Bauds, this is the default value taken by the underlying command line for validation.

Regards

Daniel

oekk
oekkAuthor
Associate
November 19, 2019

Thank you for your response on such short notice.

  • I am aware of the jumpers, I have them on the right possition.
  • The USART is configurated at 115200 Bauds too.
  • My connections to the board are power (PSDU DC5V) and usb on CN23 (ST-LINK/V3E).

> I've seen on some boards, after a first connection on the PC there is a need to do a reset by hand for the validation to work correctly.

What do you mean by this?

fauvarque.daniel
ST Employee
November 20, 2019

Just that a first validation on the target failed after flash, hitting the reset button and restarting the validation made it work. I didn't see this behavior on this specific board actually.

To move forward on the debugging of your issue, you can launch a pseudo tty on the COM port on the PC and press the reset button on the board. Normally you should see some text displayed.

You can also verify that your main.c looks like that:

 MX_GPIO_Init();

 MX_CRC_Init();

 MX_X_CUBE_AI_Init();

 /* USER CODE BEGIN 2 */

 /* USER CODE END 2 */

 /* Infinite loop */

 /* USER CODE BEGIN WHILE */

 while (1)

 {

  /* USER CODE END WHILE */

 MX_X_CUBE_AI_Process();

  /* USER CODE BEGIN 3 */

 }

and in app_x-cube-ai.c you have something like:

void MX_X_CUBE_AI_Init(void)

{

  MX_UARTx_Init();

  aiValidationInit();

  /* USER CODE BEGIN 0 */

  /* USER CODE END 0 */

}

void MX_X_CUBE_AI_Process(void)

{

  aiValidationProcess();

  /* USER CODE BEGIN 1 */

  /* USER CODE END 1 */

}

fauvarque.daniel
ST Employee
November 19, 2019

BTW you can always use the stm32ai command line but as the UI triggers the command line you'll have the same answer.

fauvarque.daniel
ST Employee
November 20, 2019

If you see some strange characters it may be due to the mismatch between the USART configuration and the TeraTerm configuration.

Both should be at the same baud rate (115200 by default) 8 bit word length, no parity, 1 stop bit.

oekk
oekkAuthor
Associate
November 20, 2019

I do have that configuration.

fauvarque.daniel
ST Employee
November 20, 2019

Just tried a project with STM32CubeMX 5.4, X-Cube-AI 4.1.0, IAR EWARM and it worked fine on that board

Here is what I did

start from the STM32CubeMX board selector and select STM32H743I-EVAL

answer no to initialize peripherals to their default values

add X-Cube-AI 4.1.0 Core and Validation

enable USART1 Asynchonous (it will go to the right pins)

In X-Cube-AI enter the platform settings (USART1) and enter your network

In Project Manager, give a name for the project and in the Code Generator section check "Copy only the necessary library files"

generate the code, compile and flash it.

then go back in X-Cube-AI and launch the validation on the target.

I used the default board configuration (clock at 64Mhz). If you change the D1CPRE clock to 480Mhz you need to also change the RCC Power regulator voltage scale to "Power Regulator Voltage Scale 0"

Hope it helps

Daniel

oekk
oekkAuthor
Associate
November 20, 2019

Thank you for your time Daniel.

I am using the exact same versions, and steps as you do, and still the same error.

Is it possible that there is a defect on my board? If so, how to spot it?

fauvarque.daniel
ST Employee
November 20, 2019

This is the project I'm using,

https://drive.google.com/open?id=1VrBfuy1YlSn29tk4GtkZLPO5hX44TEJn

if it is not working it seems that the USART1 is not sent to the ST-Link correctly.

You said in an earlier post that with another program you saw something on the STLink Virtual Com Port, so I assume that the jumper configuration is correct.

fauvarque.daniel
ST Employee
November 22, 2019

the difference between the 2 projects is the configuration of the pullup and port speed.

You can try to change in the stm32h7xx_hal_msp.c those 2 parameters to the values below:

 GPIO_InitStruct.Pull   = GPIO_PULLUP;

 GPIO_InitStruct.Speed   = GPIO_SPEED_FREQ_VERY_HIGH;

oekk
oekkAuthor
Associate
November 25, 2019

Hi, I've tried that too, and nothing different happens. I believe that the two projects are generated very differently.

BK.1
Associate
March 8, 2020

I'm having the same trouble with STM32F407 discovery board... any suggestions ?

I'm using x-cube-AI 5.0.0 version