Using the STM32 UART interface with HAL

This tutorial shows how to use the STM32 UART interface in different modes using the HAL libraries. We will show how to use direct mode, interrupt-based mode and DMA-controlled mode and will use a logic analyzer to compare the precise timings of various events.

Before you begin, install VisualGDB 5.2 or later.

  1. Start Visual Studio and open VisualGDB Embedded Project Wizard:01-newprj
  2. Select “Create a new project with MSBuild -> Embedded Binary”:02-msbuild
  3. On the next page select your STM32 device. We will use the Nucleo-F410RB board that has the STM32F410RB chip:03-device
  4. Proceed with the default “LEDBlink (HAL)” sample:04-sample
  5. Connect your board to USB and let VisualGDB automatically recognize it and configure debug settings:05-debug
  6. Press “Finish” to create the project. We will begin with a simple program that will read bytes via UART and echo them back in groups of 4. This requires four steps:
    1. Enabling the clocks for the UART and GPIO peripherals.
    2. Configuring the GPIO pins corresponding to UART to actually act as UART pins (as opposed to manually controlled GPIO) pins.
    3. Initializing the UART module by specifying the operating parameters.
    4. Actually reading and writing the data.

    Replace the code in your main source file with the following:


  7. We are using UART2 and pins PA2 and PA3 as the Nucleo-F410RB board has them connected to the on-board ST-Link UART interface, so we can use a terminal to interact with the board. You can find the GPIO pin numbers and the alternate function numbers corresponding to the UART interface on your device by searching the datasheet for the Alternate Function Mapping section:aftableFor STM32F410RB connecting UART2 to pins PA2 and PA3 requires enabling alternate function #7.
  8. Build the code by pressing Ctrl-Shift-B:06-build
  9. You can use a terminal program to talk to your STM32 board over the UART interface. If you are using VisualGDB Custom Edition, simply enable the Raw Terminal in VisualGDB Project Properties and it will show a terminal window inside the Visual Studio window: 07-terminal
  10. Press F5 to start debugging. Try typing some text in the terminal window and see how after every 4 characters the program echoes them back:08-echo
  11. Now we will explore the UART timings using a logic analyzer. First of all, modify your code to continuously output “test\r\n” and use GPIOC10 to signal the lifetime of the HAL_UART_Transmit() function:

  12. We will use Analyzer2Go to turn another STM32 board into a full-featured logic analyzer. Connect your second board to your computer, start Analyzer2Go and select the board type: 09-a2go
  13. Connect the following signals between the boards:
    Signal Board running firmware Board running logic analyzer
    Ground GND GND
    UART output TX Any of the supported inputs
    HAL_UART_Transmit() lifetime indicator PC10 Any of the supported inputs


  14. Enable the connected signals in Analyzer2go to begin watching them. See how the HAL_UART_Transmit() function (red) is active during the entire transmission (blue):10-capture
  15. Press the “Record” button to record several packets in a  row. Then stop recording and zoom into one of them:12-zoomed
  16. In order to automatically decode the UART bytes, open the Protocol Analyzers tab, drag/drop the UART analyzer and connect it to the corresponding signal:13-parsed
  17. You can analyze the raw encoding of the UART signals by selecting the decoded characters and creating notes for some of them:14-note
  18. Then switch to the “Raw” view to see the signal shape. You can click the “set clock period” button to highlight individual zeroes and ones:15-period
  19. The ‘t’ character was encoded as 0 0010 1110 1, which corresponds to a start bit (0) followed by a value of 0x74 (ASCII code for ‘t’) followed by a stop bit (1):16-data
  20. Try changing the stop bit amount to 2:

    See how the stop bit is now twice longer:17-2stopbits

  21. Although calling HAL_UART_Transmit() for every transmission is simple, it has one major disadvanrage. While the transmission is active, the program cannot do anything else and has to wait for it to complete. We will now use the interrupt-based transmission to free up some of the CPU cycles. Replace the code in your main source file with this:

    Don’t forget to copy the previous initialization code for UART and GPIO.

  22. Set a breakpoint in HAL_UART_TxCpltCallback(), start debugging and wait for it to trigger. Then check the call stack:stackYou can see how the UART interrupt got invoked when the main() function was already running HAL_Delay(). The USART2_IRQHandler() handler called the HAL_UART_IRQHandler() and the HAL_UART_IRQHandler() in turn called the HAL_UART_TxCpltCallback() once it determined that the last byte got transmitted.
  23. Remove the breakpoint and restart the program. Then add the C11 and C12 signals to Analyzer2Go and make another recording. Note how the HAL_UART_Transmit_IT() function returns immediately (red) and the interrupt handler (green) is called after each byte is queued for transmission. Finally, the HAL_UART_TxCpltCallback() (orange signal switching to 0) is called once the last byte was physically sent:18-isrmode
  24. Most of the time during the transmission the CPU will be able to run code unrelated to the transmission. It will only be interrupted by occasional UART interrupts. You can measure the overhead of the UART interrupts by comparing the byte transmission period to the width of the ‘ISR’ pulse. For STM32F410RB the overhead is 12 out of 96 microseconds (12.5%) regardless of the buffer size:19-usage
  25. In order to reduce the interrupt-related overhead, we will show switch UART to use DMA (direct memory access). In this mode the DMA controller will automatically feed the entire buffer to the UART byte-by-byte and only raise an interrupt once the entire buffer is sent.  Add the following static variable:

    Then replace the code below the code initializing GPIOC with the following:

    Remove the UART interrupt handler and add the DMA interrupt handler and 2 UART callbacks:

    Note that different devices have different DMA channel and stream numbers assigned to UART. Use the DMA Request Mapping table in your device’s reference manual (not datasheet) to get the correct numbers:dma

  26. Start the program and ensure you still can see the stream of ‘test’ messages:20-dmarun
  27. Go back to Analyzer2Go and and check the timing. See how now the DMA interrupt is only called twice per the entire transmission (once for each half of the buffer):21-dmaIf you measure the interrupt overhead now you should get 41 microseconds out of 670 (for the entire packet) or ~6%. The DMA interrupt overhead also doesn’t scale up when you increase buffer size, so sending 70 bytes in a packet instead of 7 would reduce the overhead to 0.6%.
  28. Having a separate callback for each half of the buffer allows implementing double-buffering. While the DMA is transferring the first half of the buffer, you program could fill the second part with the next frame and vice versa. The same technique would also work for other DMA-capable peripherals, such as SPI (see the SPI tutorial for more details).