cancel
Showing results for 
Search instead for 
Did you mean: 

Nodes are not declared global in the "Low Level" initializations performed by STM32CubeMx with STM32U5 processors

JVERN.18
Associate III

I want to manage a uart in reception with a DMA in circular mode using "low level" functions on a STM32U575ZITxQ processor. The initialization of my code is done with STM32CubeMx 6.13.0.

In the "Project Manager->Advanced Settings", I chose "LL" for "GPIO", "GPDMA", "TIM" and "USART".
In "Sytem Core->GPDMA1" channel1 is configured in circular mode with a "request" = USART1_RX.

When I generate the code, the following code is generated for the uart initialization function:

image.png

Unfortunately, as we can see, the node "Node_GPDMA1_Channel1" is declared local to the function, which makes its effective use impossible (unlike the "HAL" functions which make the node global).
For my code to work (and it does), it is necessary that I take the node declaration out of the function and make it global.

Of course, I have to repeat this change every time I regenerate the code with STM32CubeMx...

Is there something I didn't do correctly, or is this an STM32CubeMx issue?

 

5 REPLIES 5
Ghofrane GSOURI
ST Employee

Hello @JVERN.18 

First let me thank you for posting.

By checking the generated code using CubeMx 6.13.0 : 

/* Private variables ---------------------------------------------------------*/

LL_DMA_LinkNodeTypeDef Node_GPDMA1_Channel1;
LL_DMA_LinkNodeTypeDef Node_GPDMA1_Channel0;

/* USER CODE BEGIN PV */

/* USER CODE END PV */

Node_GPDMA1_Channel0 and Node_GPDMA1_Channel1 are global variables ,they are declared outside of any function.

Could you provide more details to push further the investigation.

THX

Ghofrane

Hello Ghofrane,

I did other tests (using CubeMx 6.13.0), and I realize that the faulty behavior that I see occurs in the case where we select the option "Project Manager->Code Generator->Generate peripheral initialization as pair..."

In this case, the node "Node_GPDMA1_Channel1" is indeed declared locally:

 

/* USER CODE BEGIN Header */
/**
  ******************************************************************************
  * @file    usart.c
  * @brief   This file provides code for the configuration
  *          of the USART instances.
  ******************************************************************************
  * @attention
  *
  * Copyright (c) 2025 STMicroelectronics.
  * All rights reserved.
  *
  * This software is licensed under terms that can be found in the LICENSE file
  * in the root directory of this software component.
  * If no LICENSE file comes with this software, it is provided AS-IS.
  *
  ******************************************************************************
  */
/* USER CODE END Header */
/* Includes ------------------------------------------------------------------*/
#include "usart.h"

/* USER CODE BEGIN 0 */

/* USER CODE END 0 */

/* USART1 init function */

void MX_USART1_UART_Init(void)
{

  /* USER CODE BEGIN USART1_Init 0 */

  /* USER CODE END USART1_Init 0 */

  LL_USART_InitTypeDef USART_InitStruct = {0};

  LL_GPIO_InitTypeDef GPIO_InitStruct = {0};
  LL_DMA_InitTypeDef DMA_InitStruct = {0};
  LL_DMA_InitNodeTypeDef NodeConfig = {0};
  LL_DMA_LinkNodeTypeDef Node_GPDMA1_Channel1 = {0};
  LL_DMA_InitLinkedListTypeDef DMA_InitLinkedListStruct = {0};
  RCC_PeriphCLKInitTypeDef PeriphClkInit = {0};

  /** Initializes the peripherals clock
  */
  PeriphClkInit.PeriphClockSelection = RCC_PERIPHCLK_USART1;
  PeriphClkInit.Usart1ClockSelection = RCC_USART1CLKSOURCE_PCLK2;
  if (HAL_RCCEx_PeriphCLKConfig(&PeriphClkInit) != HAL_OK)
  {
    Error_Handler();
  }

  /* Peripheral clock enable */

 

The code therefore seems different (and faulty in one case) depending on whether we generate separate files or not for the initializations.

The problem seems the same regardless of the device and the direction of the transfer

If you can't see the problem, I can send you my ioc file...Kind regards,

Jean-Louis

Hello @JVERN.18 

Your contribution is much appreciated.

A ticket  has been escalated to the development team in order to fix this issue . Internal ticket number 200663 

I'll keep you informed about any updates.

THX

Ghofrane

Hello Ghofrane, and thank you for your answer.

Is there a solution to see what is the follow-up given to a ticket? and/or can we know which tickets have been solved when a new version of STM32CubeMx is released?

 

Jean-Louis

Hello @JVERN.18 

Each new version of STM32CubeMX comes with Release Notes that detail bug fixes, enhancements, and modifications made since the last version. These notes typically include information about resolved issues and can help identify which tickets have been addressed 

STM32CubeMX release 6.13.0 - Release note

STM32CubeMX errata 6.13.x - stm32mcu

Also a  post is published for each release. STM32CubeMX 6.13.0 released - STMicroelectronics Community 

THX

Ghofrane