Skip to main content
MDega.2
Associate II
September 30, 2021
Solved

Potential bug for STM32F303 for LL USART and DMA operation

  • September 30, 2021
  • 1 reply
  • 1186 views

Hello,

I created a simple project for a board NUCLEO-F303RE enabling USART2 and DMA for transmit and I believe there is a bug in the code generation that doesn't configure properly the peripherals.

The generated code has:

 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_USART2_UART_Init();
 MX_TIM2_Init();
 MX_DMA_Init();
 MX_USART3_UART_Init();
 /* USER CODE BEGIN 2 */

Then the MX_USART2_UART_Init has:

 /* USART2_TX Init */
 LL_DMA_SetDataTransferDirection(DMA1, LL_DMA_CHANNEL_7, LL_DMA_DIRECTION_MEMORY_TO_PERIPH);
 
 LL_DMA_SetChannelPriorityLevel(DMA1, LL_DMA_CHANNEL_7, LL_DMA_PRIORITY_LOW);
 
 LL_DMA_SetMode(DMA1, LL_DMA_CHANNEL_7, LL_DMA_MODE_NORMAL);
 
 LL_DMA_SetPeriphIncMode(DMA1, LL_DMA_CHANNEL_7, LL_DMA_PERIPH_NOINCREMENT);
 
 LL_DMA_SetMemoryIncMode(DMA1, LL_DMA_CHANNEL_7, LL_DMA_MEMORY_INCREMENT);
 
 LL_DMA_SetPeriphSize(DMA1, LL_DMA_CHANNEL_7, LL_DMA_PDATAALIGN_BYTE);
 
 LL_DMA_SetMemorySize(DMA1, LL_DMA_CHANNEL_7, LL_DMA_MDATAALIGN_BYTE);
 
 /* USART2 interrupt Init */

But it is run BEFORE the MX_DMA_Init, which enables the clock for the DMA:

 /* DMA controller clock enable */
 LL_AHB1_GRP1_EnableClock(LL_AHB1_GRP1_PERIPH_DMA1);

So I believe this causes the DMA not to get configured properly: I stepped the program during the USART init and the DMA regs are not changing when setting the increment for the memory (Line 10 above).

A quick fix I could do is to copy the DMA Init also before the auto generate inits as in:

 /* USER CODE BEGIN SysInit */
 MX_DMA_Init(); //Manually copied here too because the clock is not enabled for DMA config done during UART setup
 /* USER CODE END SysInit */
 
 /* Initialize all configured peripherals */
 MX_GPIO_Init();
 MX_USART2_UART_Init();
 MX_TIM2_Init();
 MX_DMA_Init();
 MX_USART3_UART_Init();
 /* USER CODE BEGIN 2 */

This seems to fix the problem and everything behaves as expected

This topic has been closed for replies.
Best answer by Imen.D

Hello @Community member​ and welcome to the Community :)

There is an issue in CubeMX v6.3.0, that the DMA Init function MX_DMA_Init() is called after the peripheral initialization.

The MX_DMA_Init shall be called before any other peripheral initialization, when DMA is used.

Our CubeMx team is aware of this issue, and working to resolve this in the coming releases.

Internal ticket 112040 (This is an internal tracking number and is not accessible or usable by customers)

Thanks for your contribution.

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

1 reply

Imen.DBest answer
ST Technical Moderator
September 30, 2021

Hello @Community member​ and welcome to the Community :)

There is an issue in CubeMX v6.3.0, that the DMA Init function MX_DMA_Init() is called after the peripheral initialization.

The MX_DMA_Init shall be called before any other peripheral initialization, when DMA is used.

Our CubeMx team is aware of this issue, and working to resolve this in the coming releases.

Internal ticket 112040 (This is an internal tracking number and is not accessible or usable by customers)

Thanks for your contribution.

When your question is answered, please close this topic by choosing Select as Best. This will help other users find that answer faster.

Imen

In order to give better visibility on the answered topics, please click on 'Best answer' on the reply which solved your issue or answered your question. Thanks