There are often cases where STM32 developers configure the STM32CubeMx and generate initialization code based on the HAL library, but when it comes to the DMA function, they find that the DMA function is invalid, but they can't seem to find the reason from the configuration operation and the code itself.

Does the Initial Configuration Order of STM32CubeMx Affect the DMA Function?

Someone once gave feedback that he used STM32F4 series chip for product development, configured and generated initialization code by STM32CubeMx, and used DMA transfer of UART.

But he found that DMA did not work at all. Later he inadvertently found out that it was because he had inadvertently adjusted the order of the UART peripheral and DMA peripheral initialization code before and after in the user code, and when he re-adjusted the order of the two everything was fine. At this time, the DMA initialization code is before and the UART initialization code is after. He wants to know how this order affects the DMA function.

Case Study began:

To fix this problem, I did a test as following:

I took a STM32F334 Nucleo board and enabled the data communication function of UART1/UART3, using DMA for cyclic data transfer. UART1 sends data and UART3 receives data. After configuring based on STM32CubeMx generate the initialization code and add the user code. As shown in the following figure.

After testing and verifying, it is found that the DMA transfer function based on UART1/3 is normal. Combined with the customer's feedback, I switched the initialization order of DMA and UART before and after, as follows.

I really found that the DMA is not working, and there is no data communication between UART1/UART3. The data register content of UART1/3 maintains 0 value without any change, especially the data register of UART1 as the transmitter side is also unchanged.

It seems that the order of the initialization code of DMA and UART does affect the function of both, that is, if the code is based on the initialization code generated by the existing CubeMX, the initialization order of both cannot be adjusted at will, so what is going on?

First, I looked at the contents of the two initialization codes to try to find a clue. Unfortunately, the reason was not found quickly. Later, when looking again at the specific contents of the DMA initialization function MX_DMA_Init();, I found that the code was actually quite simple, with two actions: One action is to turn on the clock for the DMA peripheral, and the other is to enable DMA-related interrupt vector control.

Since this is the case, I tried to keep the location of the DMA initialization function body after the UART initialization code, but extracted the code that turns on the DMA peripheral clock from the DMA initialization function and moved it to before the UART initialization code, and verified it accordingly. This time, the result is all right.

It seems that based on the existing initialization code, this DMA clock turn on has to be placed before the UART initialization code, so why is that?

Looking back at the initialization code of the UART in detail, I found a clue there in a sub-function HAL_UART_MspInit() of the UART initialization function.

MX_USART1_UART_Init()==》HAL_UART_Init()==》HAL_UART_MspInit();

Because we have enabled the DMA function related to the UART transmission event, there is not only the configuration of the multiplexing function for the GPIOs related to UART in HAL_UART_MspInit(); function, but also the DMA configuration related to the UART event. It seems that the initialization of UART is still related to DMA.

Combined with the above DMA initialization function in the sentence to turn on the DMA peripheral clock code, to here basically understand what is going on.

Conclusion

1. For STM32CubeMx, if we do not turn on the clock of DMA peripheral in advance, and there is no code to turn on the clock of DMA peripheral in the UART initialization function, the configuration operation of DMA in UART initialization code is not guaranteed to be effective.

2. Do embedded development process, many of the initialization configuration is based on the hardware itself, some initialization sequence may have hardware timing requirements. About these, each chip manual will generally have a clear description and instructions. We must follow the relevant provisions when writing the initialization code. Of course, some configuration sequences may have to be combined with specific applications, the actual experience and do flexible adjustment.

3. Back to the case in the article, generally speaking, the STM32CubeMx has already taken the initialization timing into account when generating the initialization code, but the user may have unintentionally adjusted the initialization order of the two in the process of organizing the code without knowing it, plus we lack sufficient understanding of the initialization code itself and may once be in trouble.

4. According to personal experience, in practice, this order may also be disrupted when we adjust the configuration back and forth based on CubeMx. Please note this. To be honest, this place is very hidden, and even if you know there is such a thing, you may still forget or ignore it.

When a DMA transfer exception occurs as a result, it is very difficult to find the problem without tracing debugging or reading based on the code, because the configuration operation and the called library code itself are fine. The core problem is the order of execution of the initialization code.

Further Reading:  STM32-based Temperature Control System Simulation