Showing results for 
Search instead for 
Did you mean: 

FreeRTOS and DMA issue

Associate III


We are currently using the STM32MP1 DK2 board for our project.

We have to use FreeRTOS + UART7 and USART3 with DMA

Our issue arise when FreeRTOS is used with an UART (USART3 or UART7 in our case) which use the DMA.

We have reduced the project to the minimal configuration :

- The linux image on the A7 is the one provided by ST and is flashed with STM32CubProgrammer.

- The project is generated from CubeMX (started from the DK2 board with the peripheral enabled and FreeRTOS with a single UART (7 or 3 in our case) using DMA).

- The CubeMX generated device-tree is compiled and used by the kernel.

When executing, the issue appears after the first call of __HAL_DMA_DISABLE() in the function HAL_DMA_Init() in file stm32mp1xx_hal_dma.c

(MX_UART7_Init() -> HAL_UART_Init() -> HAL_UART_MspInit() -> HAL_DMA_Init())

After the final instruction of (__HANDLE__)->Instance)->CR &= ~DMA_SxCR_EN is executed, the content of the current stack is modified and the previous stacked return address is corrupted, leading to a hardfault when HAL_UART_Init returns.

We don't see why this is happening and why executing the previous instruction leads to this stack corruption.

We don't reproduce the issue in Engineering mode.

We don't reproduce the issue when FreeRTOS is not present (even if at this stage of execution the presence/absence of FreeRTOS should not have influenced).

Do you succeed to reproduce this issue or do you have some explanation of such a behavior ?



ST Employee

Hi @romain2​ 

First assumption would be a stack overflow.

Can you try to extend _Min_Stack_Size in .ld file ?

If this not fix you problem please providing your .ioc file would be of great help for us to duplicate.



In order to give better visibility on the answered topics, please click on 'Accept as Solution' on the reply which solved your issue or answered your question.
Associate III

Hi Olivier,

Thank you for your answer.

We have already tried to extend the stack size. This doesn't change the behavior of the program.

You will find attached one of the .ioc which trigger our issue.



ST Employee

​Hi Romain,

Did you manage to investigate this issue a bit further?

I've loaded your .ioc , generated the code in cubemx and run it in Engineering and Production mode. I don't see any issue regarding DMA configuration since the program run ok (reaching oskernelstart breakpoint and can go beyond).

You said you've loaded the cubemx generated device tree, in production mode do you have the same issue if you use the default device tree configuration?

or use the config 3 at boot?

  • 3: stm32mp157c-dk2-m4-examples-sdcard