{"id":4291,"date":"2019-12-11T20:00:38","date_gmt":"2019-12-11T19:00:38","guid":{"rendered":"https:\/\/msalamon.pl\/?p=4291"},"modified":"2025-12-27T18:32:44","modified_gmt":"2025-12-27T17:32:44","slug":"uart-reception-with-dma-on-the-f103-thats-also-simple","status":"publish","type":"post","link":"https:\/\/msalamon.pl\/en\/uart-reception-with-dma-on-the-f103-thats-also-simple\/","title":{"rendered":"UART reception with DMA on the F103? That’s also simple!"},"content":{"rendered":"\n

Not long ago I wrote an article about how to implement UART reception via DMA. I successfully wrote such a \u201chands-free\u201d implementation for STM32F411<\/a>. Many of my readers also use cheap boards with F103<\/a> and porting the library caused huge problems. I adapted my code and I will show you what the differences were and the potential difficulties.<\/p>\n\n\n\n\n\n\n\n

First, I encourage you to read the post for STM32F411<\/a>, in which I described in detail how I managed to implement UART reception via DMA. In this post I only deal with porting this method to the STM32F103C8<\/a> at the request of readers.<\/p>\n\n\n\n

Differences between F4 and F1<\/h1>\n\n\n\n

Among the significant differences I would mention just one. It is the DMA module, which plays an important role in reception. In STM32F1 series microcontrollers, DMA is more \u201climited\u201d. Each DMA module contains only a few channels through which we can fetch data. In the F103C8 there are 12 channels in total.<\/p>\n\n\n\n

STM32F4 has a bit more \u201cbells and whistles\u201d in DMA. Since I already mentioned channels, you can sense that this is where the difference lies, right? In F4 we have something called Streams. The F411RE has as many as 16 of these streams (8 for each of the two DMA controllers). Each such stream consists of up to 8 channels. This is one of the main differences that can cause trouble when porting.<\/p>\n\n\n\n

Since we have a more extensive DMA, of course there will be different registers responsible for everything. In my code, I partially used \u201cbare\u201d registers. I will discuss the exact differences alongside the code.<\/p>\n\n\n\n

There is one more important \u201csmall\u201d difference. Do you remember that \u201ctrick\u201d where stopping DMA would automatically trigger a transfer-complete interrupt? This is true only for Streams, i.e., e.g., F4 microcontrollers. For the STM32F103<\/a>, stopping the DMA channel will unfortunately not trigger such an interrupt.<\/p>\n\n\n\n

STM32CubeIDE \u2013 configuration<\/h2>\n\n\n\n

Let\u2019s start with the configuration in CubeIDE. The version I use is v1.1.0 with integrated CubeMX v5.4.0, while the HAL libraries are F1 v1.8.0.<\/p>\n\n\n

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

As a test platform I used the well-known BluePill<\/a>, which you can buy from a reliable source \u2014 from me \ud83d\ude42<\/a>
The configuration is very similar to the one from the previous post, which concerned the F4 family<\/a>. You need to configure UART2 (or another) to 115200 Bits\/s and enable the DMA channel for reception on this UART. In addition, you need to enable global UART2 interrupts to be able to use the IDLE interrupt.<\/p>\n\n\n

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

<\/p>\n\n\n

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

Besides that, you need a few more things. Set pin PC13 as output. It has the on-board LED, which we will control with UART commands.
Finally, enable Debugging via Serial Wire \u2013 it makes work much easier \ud83d\ude09<\/p>\n\n\n

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

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

and set a higher HCLK clock. I used 64 MHz.<\/p>\n\n\n\n

Code<\/h2>\n\n\n\n

You can generate the project configured like this. I\u2019ll start with the main.c<\/em> file. Nothing changes here compared to the F4 code. You initialize the library in the same way and simply parse the data coming from UART2.<\/p>\n\n\n\n

  \/* USER CODE BEGIN 2 *\/\n  UARTDMA_Init(&amp;huartdma, &amp;huart2);\n  \/* USER CODE END 2 *\/\n\n  \/* Infinite loop *\/\n  \/* USER CODE BEGIN WHILE *\/\n  while (1)\n  {\n\t  if(UARTDMA_IsDataReady(&amp;huartdma))\n\t  {\n\t\t  UARTDMA_GetLineFromBuffer(&amp;huartdma, ParseBuffer);\n\t\t  if(strcmp(ParseBuffer, \"ON\") == 0)\n\t\t  {\n\t\t\t  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_RESET);\n\t\t  }\n\t\t  else if(strcmp(ParseBuffer, \"OFF\")  == 0)\n\t\t  {\n\t\t\t  HAL_GPIO_WritePin(LED_GPIO_Port, LED_Pin, GPIO_PIN_SET);\n\t\t  }\n\t  }\n    \/* USER CODE END WHILE *\/\n\n    \/* USER CODE BEGIN 3 *\/\n  }\n  \/* USER CODE END 3 *\/\n}<\/pre>\n\n\n\n
Trying to copy the library from F4 will end with lots of errors. Remember to insert the interrupt handler code properly.<\/strong> The errors result from the aforementioned differences between DMA in both microcontrollers. This is what the register tree looked like for the F411<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
And this is for today\u2019s hero \u2013 F1<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
You can see that the difference is quite large. However, it only looks scary at first glance. Many functions of the registers overlap but are named differently. You can notice similarities such as DMA_LISR\/DMA_HISR and DMA_ISR. The double register results from the greater number of statuses in F4.
Let\u2019s get rid of the compiler errors!<\/p>\n\n\n\n
\u201cIncorrect\u201d register names<\/h3>\n\n\n\n
The most common error will be an unknown register or bit name that we use. Let\u2019s go from the top of the file. The first thing that shows up is<\/p>\n\n\n\n
huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CR &amp;= ~DMA_SxCR_EN;<\/pre>\n\n\n\n
The compiler does not know the CR register or the DMA_SxCR_EN bit. Looking into the F411 reference manual, we can see that this is the Stream configuration register, to which we write the negated bit to enable DMA. We are in the UART IDLE interrupt function, so this is simply disabling DMA after receiving a string of characters.
What needs to be done? Find how the register and bit responsible for the same thing are called in F103! As I said, the registers have similar names. In fact, most of them differ in that in F411 they are called \u201cStream X\u2026<\/em>\u201d, and for F103 \u201cChannel X\u2026<\/em>\u201d. That\u2019s exactly the case for the CR register, i.e., the Configuration Register<\/em>.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
A quick look at the Reference Manual and we already know that the register is abbreviated as CCR<\/strong>, and the bit enabling DMA is EN<\/strong>. According to the HAL naming convention, the erroneous line should be corrected to<\/p>\n\n\n\n
huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CCR &amp;= ~DMA_CCR_EN;<\/pre>\n\n\n\n
And the compiler leaves it alone. Bring on the next problem. This time the compiler complains that it doesn\u2019t know StreamBaseAddress<\/em>. This is a member of the HAL DMA structure. No wonder it doesn\u2019t know it, because in F1 there are no Streams<\/em>. Logically, this variable is a pointer to the base address of the DMA stream. It should be changed to DmaBaseAddress<\/em>. I found this by browsing the definition of that structure.
So replace<\/p>\n\n\n\n
DMA_Base_Registers *DmaRegisters = (DMA_Base_Registers *) huartdma-&gt;huart-&gt;hdmarx-&gt;StreamBaseAddress;<\/pre>\n\n\n\n
with <\/p>\n\n\n\n
MA_Base_Registers *DmaRegisters = (DMA_Base_Registers *) huartdma-&gt;huart-&gt;hdmarx-&gt;DmaBaseAddress;<\/pre>\n\n\n\n
However, here you might not notice something. A moment earlier such a structure was defined<\/p>\n\n\n\n
typedef struct\n{\n\t__IO uint32_t ISR;   \/\/ DMA interrupt status register\n\t__IO uint32_t Reserved0;\n\t__IO uint32_t IFCR;  \/\/ DMA interrupt flag clear register\n} DMA_Base_Registers;<\/pre>\n\n\n\n
These are the base registers, i.e., the status and interrupt clear registers. Between them there is one Reserved0<\/em> field. Why? Notice that in F411 you have two registers. There are \u201chigh\u201d and \u201clow\u201d ones. A total of 64 bits for status and clearing. In the structure this was represented in such a way that after the 32-bit LISR there are another 32 bits, which can be treated as the next part of the total \u201cvirtual\u201d 64-bit ISR register.
In F103 you don\u2019t have \u201cupper\u201d and \u201clower\u201d registers. There is only one ISR and IFCR. Therefore, you can remove this reservation so that the names match what they will point to.<\/p>\n\n\n\n
typedef struct\t\n{\t\n\t__IO uint32_t ISR;   \/\/ DMA interrupt status register\t\n\t__IO uint32_t IFCR;  \/\/ DMA interrupt flag clear register\t\n} DMA_Base_Registers;<\/pre>\n\n\n\n
Now we have a slightly different problem. The compiler reports that in the line<\/p>\n\n\n\n
maRegisters->IFCR = DMA_FLAG_TCIF0_4 << huartdma->huart->hdmarx->StreamIndex;<\/pre>\n\n\n\n
there are two errors. An unknown flag and a shift. A quick look at the documentation lets you notice that the DMA_FLAG_TCIF0_4<\/em> flag is the Transfer Complete flag for Stream 0 or 4 depending on which register we are dealing with in F4. It\u2019s easy to see that you need to replace it with its F1 equivalent, i.e., DMA_IFCR_CTCIF1<\/em>. The StreamIndex<\/em> variable is not known to the compiler for exactly the same reason as a bit above it didn\u2019t know the base address of the DMA registers. Just replace Stream with Channel to get the following<\/p>\n\n\n\n
DmaRegisters-&gt;IFCR = DMA_IFCR_CTCIF1 &lt;&lt; huartdma-&gt;huart-&gt;hdmarx-&gt;ChannelIndex;<\/pre>\n\n\n\n
Next there is a visible problem with the register that stores the number of items remaining to be transferred by DMA. Here it\u2019s simple, because according to the documentation<\/p>\n\n\n\n
Length = DMA_RX_BUFFER_SIZE - huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;NDTR;<\/pre>\n\n\n\n
is enough to change to<\/p>\n\n\n\n
Length = DMA_RX_BUFFER_SIZE - huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CNDTR;<\/pre>\n\n\n\n
The last differences in the DMA interrupt handling can be found at its exit. There are lines related to clearing the DMA interrupt, setting the memory address for DMA to write to, setting the number of data to transfer via DMA, and starting the DMA itself.
In each of them the compiler returns errors.<\/p>\n\n\n\n
DmaRegisters-&gt;IFCR = 0x3FU &lt;&lt; huartdma-&gt;huart-&gt;hdmarx-&gt;StreamIndex; \t\t\/\/ Clear all interrupts\t\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;M0AR = (uint32_t) huartdma-&gt;DMA_RX_Buffer; \/\/ Set memory address for DMA again\t\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;NDTR = DMA_RX_BUFFER_SIZE; \/\/ Set number of bytes to receive\t\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CR |= DMA_SxCR_EN;            \t\/\/ Start DMA transfer<\/pre>\n\n\n\n
After the earlier explanations, you should be able to handle them already. Maybe with one small exception\u2026
You can notice the mysterious value 0x3F<\/em> written to the IFCR<\/em> register. In this register, interrupt flags are cleared by writing a one to the appropriate place. So why 0x3F? It comes from the fact that the first 6 flags refer to one Stream in F4. This value is shifted left by the StreamIndex<\/em> to select the appropriate flags.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
In F1 there are fewer of these flags, only 4, so you will have to write 0x0F to the appropriate register.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
Searching and matching all the names for F1, the whole thing comes down to the following<\/p>\n\n\n\n
DmaRegisters-&gt;IFCR = 0x0FU &lt;&lt; huartdma-&gt;huart-&gt;hdmarx-&gt;ChannelIndex; \t\t\/\/ Clear all interrupts\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CMAR = (uint32_t) huartdma-&gt;DMA_RX_Buffer; \/\/ Set memory address for DMA again\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CNDTR = DMA_RX_BUFFER_SIZE; \/\/ Set number of bytes to receive\nhuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CCR |= DMA_CCR_EN;            \t\/\/ Start DMA transfer<\/pre>\n\n\n\n
In the entire code there is only one incorrect line left during the initialization of the UARTDMA library. It concerns disabling the half-transfer interrupt. The name of the register and the bit changes, of course.
In F4 it was like this<\/p>\n\n\n\n
huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CR &amp;= ~DMA_SxCR_HTIE; \/\/ Disable DMA Half Complete interrupt<\/pre>\n\n\n\n
and in F1 it is like this<\/p>\n\n\n\n
huartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CCR &amp;= ~DMA_CCR_HTIE; \/\/ Disable DMA Half Complete interrupt<\/pre>\n\n\n\n
A simple change \ud83d\ude42<\/p>\n\n\n\n
Will it work?<\/h3>\n\n\n\n
Not yet! Do you remember how I wrote a little higher that for DMA with channels like in F103 the Transfer Complete interrupt will not be triggered after stopping DMA? What to do? I came up with simply manually calling the interrupt handling function before exiting the interrupt handling the UART IDLE. 
The whole function will therefore look like this<\/p>\n\n\n\n
void UARTDMA_UartIrqHandler(UARTDMA_HandleTypeDef *huartdma)\n{\n\tif(huartdma-&gt;huart-&gt;Instance-&gt;SR &amp; UART_FLAG_IDLE)       \/\/ Check if Idle flag is set\n\t{\n\t\tvolatile uint32_t tmp;\n\t\ttmp = huartdma-&gt;huart-&gt;Instance-&gt;SR;                      \/\/ Read status register\n\t\ttmp = huartdma-&gt;huart-&gt;Instance-&gt;DR;                      \/\/ Read data register\n\t\thuartdma-&gt;huart-&gt;hdmarx-&gt;Instance-&gt;CCR &amp;= ~DMA_CCR_EN; \t  \/\/ Disable DMA - it will force Transfer Complete interrupt if it's enabled\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t  \/\/ BUT! It's only for DMA Streams(i.e F4), not for Channels like there in F103!\n\t\ttmp = tmp; \/\/ For unused warning\n\t\tUARTDMA_DmaIrqHandler(huartdma); \/\/ Since DMA IRQ won't start independently for Channels, we have to handle it manually\n\t}\n}<\/pre>\n\n\n\n
However, remember that the UARTDMA_DmaIrqHandler(huartdma)<\/em> function should also be placed in the Transfer Complete interrupt handler. Although we assume that messages should be shorter than the DMA buffer, it may happen that something longer arrives (life verifies :)). Then there is a danger that the DMA buffer will fill up and you will not yet receive the UART IDLE interrupt. In this case, clearing the DMA buffer will be performed in the Transfer Complete interrupt.<\/p>\n\n\n
\n
\"\"<\/a><\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
Summary<\/h2>\n\n\n\n
Was porting from F411<\/a> to F103<\/a> that difficult? Yes and no\u2026 Changing the registers themselves was easy. It was worse to come up with the idea that the DMA TC interrupt would not be triggered after \u201cmanually\u201d disabling DMA. At first I didn\u2019t know what was going on that the interrupt didn\u2019t \u201cwake up\u201d \ud83d\ude42 However, everything ended well and you get from me a ready-made guide to such porting and code for the BluePill<\/a> \ud83d\ude09<\/p>\n\n\n
\n
\"STM32<\/a><\/figure>\n<\/div>\n\n\n
 (this online course is conducted in Polish)<\/p>\n\n\n\n
The full project along with the library can be found as usual on my GitHub: link<\/a><\/p>\n\n\n\n
If you noticed any error, disagree with something, would like to add something important, or simply think you\u2019d like to discuss this topic, write a comment. Remember that the discussion should be polite and in accordance with the rules of the Polish language.<\/span><\/p>\n\n\n
\n            \n
\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n    \n
\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n            
\n            \n\n
<\/div>\n        <\/div>\n    <\/div>\n<\/div>\n                \n\n
\n            <\/span>\n    <\/div>\n    <\/div>\n","protected":false},"excerpt":{"rendered":"
Not long ago I wrote an article about how to implement UART reception via DMA. I successfully wrote such a \u201chands-free\u201d implementation for STM32F411. Many of my readers also use cheap boards with F103 and porting the library caused huge problems. I adapted my code and I will show you […]<\/p>\n","protected":false},"author":1,"featured_media":3344,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","_links_to":"","_links_to_target":""},"categories":[160],"tags":[175,176,174,177],"class_list":["post-4291","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-stm32","tag-electronics","tag-programming","tag-stm32","tag-stm32cubemx"],"_links":{"self":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/comments?post=4291"}],"version-history":[{"count":3,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4291\/revisions"}],"predecessor-version":[{"id":4392,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/posts\/4291\/revisions\/4392"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media\/3344"}],"wp:attachment":[{"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/media?parent=4291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/categories?post=4291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/msalamon.pl\/en\/wp-json\/wp\/v2\/tags?post=4291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}