{"id":4297,"date":"2019-10-30T18:40:58","date_gmt":"2019-10-30T17:40:58","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4297"},"modified":"2025-12-27T18:36:38","modified_gmt":"2025-12-27T17:36:38","slug":"uart-reception-using-dma-is-a-piece-of-cake-lesson-from-the-stm32-course","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/uart-reception-using-dma-is-a-piece-of-cake-lesson-from-the-stm32-course\/","title":{"rendered":"UART Reception Using DMA Is a Piece of Cake (Lesson from the STM32 Course)"},"content":{"rendered":"\n

Recently in my mailing group I asked a question about which STM32 topic interests you the most right now. I received lots of different answers, but one topic came up several times. It was receiving messages of arbitrary length from UART via DMA<\/strong>. If the reader wants it \u2013 I\u2019m writing it!<\/p>\n\n\n\n\n\n\n\n

Many myths have grown around this topic. Some say it can\u2019t be done. Others claim it\u2019s a huge effort. I have no idea where that came from. Perhaps it\u2019s partly because the HAL libraries don\u2019t take into account the very important UART IDLE interrupt at all, which is essential here. Maybe also because it can be done in several ways and each has its pros and cons.<\/p>\n\n\n\n

How to receive UART via DMA?<\/h1>\n\n\n\n

As you know, or are just finding out \u2013 when starting DMA reception, we must declare the number of characters after which a DMA transfer-complete interrupt will be generated. At half of that count, a half-transfer interrupt will also fire.<\/p>\n\n\n\n

UART communication is such that device messages often have different lengths. Take for example this GPS I described here recently<\/a>. If there\u2019s no fix, the messages will be very short with no data between separators in the form of commas. After GPS lock, messages can be several dozen characters long. Additionally, different message types also have different lengths. How are you supposed to know how long the next message will be?<\/p>\n\n\n\n

You could simply wait for the fixed amount of data to overflow. Then one, two or more messages might arrive before the DMA interrupt is triggered. But what if no more messages come in and the last one was critical? That\u2019s not the most convenient situation, is it?<\/p>\n\n\n\n

UART IDLE LINE interrupt<\/h3>\n\n\n\n

STM32 microcontrollers have lots of interesting interrupts. One of the more interesting is UART IDLE LINE. It can be used for multi-master communication, but it can also serve us to detect the end of a message.<\/p>\n\n\n\n

How does it work? After detecting the first incoming character on the UART, the receiver line is monitored for activity. If there is no activity on this line for a period equal to the length of one character, an interrupt is raised.<\/strong> Do you already see the use case?<\/p>\n\n\n\n

Let\u2019s say exactly 20 characters are coming to the microcontroller over UART. After the time of the 21st character we get the IDLE interrupt. End of message detected. What next?<\/p>\n\n\n\n

End of message and the DMA matter<\/h3>\n\n\n\n

Alright, but what does DMA have to do with this? During my research I saw several implementation approaches. One interesting way was to cyclically start DMA for, say, 10 characters. In my opinion it generates a lot of unnecessary work restarting DMA. On the other hand, it needs little RAM and is completely independent of UART message length.<\/p>\n\n\n\n

My proposal is a DMA buffer that can hold the longest possible message we can expect. So where do we get the DMA interrupt from? There\u2019s a nice relationship that by stopping the \u201cracing\u201d DMA you generate a transfer-complete interrupt<\/strong>. And that\u2019s the key to success!<\/p>\n\n\n\n

It\u2019s enough to stop DMA in the IDLE interrupt to enter the DMA transfer-complete handler. Magic!<\/p>\n\n\n\n

DMA interrupt handling<\/h3>\n\n\n\n

There are two \u201cunfortunatelys.\u201d One is that the HAL libraries don\u2019t handle the IDLE interrupt. You have to write your own and replace the standard HAL interrupt handling. The second unfortunately is that Cube will always try to restore the default interrupt handling when regenerating the project, and you have to remember that<\/strong>.<\/p>\n\n\n\n

There\u2019s also a big plus in HAL. It generates separate handlers for each UART and each DMA channel. Replacing the interrupt is therefore harmless to other interrupts.<\/p>\n\n\n\n

Okay, enough theorizing. Let me walk you through the implementation.<\/p>\n\n\n\n

UART reception via DMA project<\/h2>\n\n\n\n

I wrote the code for the Nucleo F411RE<\/a> using STM32CubeIDE 1.0.2 and HAL libraries version 1.24.1. There won\u2019t be a schematic this time. I didn\u2019t connect anything extra to the board. <\/p>\n\n\n\n

\"\"<\/a><\/figure><\/h1>\n\n\n\n

Generate the project with the standard peripherals initialized. You can easily do this by selecting the Nucleo<\/a> board instead of the microcontroller when creating the project.<\/p>\n\n\n\n

Since you chose the default peripherals, you already have the UART and the built-in LED enabled. We\u2019ll use both today.<\/p>\n\n\n\n

However, you need to further configure the UART. Configure the DMA request for USART2_RX in Normal mode. Also add the USART2 global interrupt in the NVIC tab. See the screenshots below.<\/p>\n\n\n

\n
\"\"<\/a><\/figure>\n<\/div>\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

And that\u2019s it on the Cube side. Let\u2019s move on to the code. I prepared a library to handle the whole thing. It allows you to use more than one UART in DMA receive mode. However, it requires a few steps and modifications of the generated code to work.<\/p>\n\n\n\n

Code<\/h3>\n\n\n\n

First, a small note. I noticed that the latest CubeMX v5.4.0 swaps the initialization order of DMA and UART2, which results in incorrect DMA operation! <\/strong>Make sure that before the while(1) loop you have it as below.<\/p>\n\n\n\n

  \/* Initialize all configured peripherals *\/\n  MX_GPIO_Init();\n  MX_DMA_Init();        \/\/ &lt;- IMPORTANT: DMA MUST BE BEFORE USART2!!!\n  MX_USART2_UART_Init();\n  \/* USER CODE BEGIN 2 *\/\n\n  \/* USER CODE END 2 *\/\n\n  \/* Infinite loop *\/\n  \/* USER CODE BEGIN WHILE *\/\n    while (1)\n    {<\/pre>\n\n\n\n
I\u2019ll start by discussing the structure that is the core of each UART you want to use for DMA reception.<\/p>\n\n\n\n
typedef struct\n{\n  UART_HandleTypeDef* huart; \/\/ UART handler\n\n  uint8_t DMA_RX_Buffer[DMA_RX_BUFFER_SIZE]; \/\/ DMA direct buffer\n  uint8_t UART_Buffer[UART_BUFFER_SIZE]; \/\/ UART working circular buffer\n\n  uint16_t UartBufferHead;\n  uint16_t UartBufferTail;\n  uint8_t UartBufferLines;\n}UARTDMA_HandleTypeDef;<\/pre>\n\n\n\n
It contains a handle to the UART and two buffers:<\/p>\n\n\n\n