Showing results for 
Search instead for 
Did you mean: 

CubeMX Feature Request: Add USART RX IDLE Handling

Steve H
Associate III
Posted on May 23, 2017 at 16:36

I'm preparing to implement an STM32 project that does high-speed async serial communications, and needs to send and receive variable-length messages. My receive messages are characterized in that they are *always* continuous byte streams on the serial line, with no inter-byte gaps; when the RX serial line goes idle, the message is complete. Because the bit rate is high, I prefer to use DMA for TX/RX message handling. I've written code to do this task before, and I know exactly how to set up the USART, DMA, and interrupt handlers to do the job.

It would be great to use the CubeMX HAL's UART routines for this project, BUT they have an essential lack here: They don't provide handling for the UART_FLAG_IDLE interrupt flag in HAL_UART_IRQHandler(). This means that DMA receive operations using the HAL routines are limited to fixed-length messages, because there is no way to handle the RX idle interrupt that is generated when the last byte of a short message comes in.

I have three equally unappealing options in this case: 1) Continue rolling my own UART support code outside the HAL framework, replacing the hal_usart module for each new target MCU I write for, and creating an integration headache; 2) Hack a local copy of the hal_usart module to add the feature (again, for each target MCU I write for), creating maintenance headaches; or 3) give up on USART DMA receive operations, creating a potentially unacceptable performance bottleneck with all that USART polling or IRQ overhead.

A quick browse of these forums and others like StackOverflow tells me that a number of other developers have faced this same issue, so there's a decent chance this feature will be generally useful.

Here's the specific feature I'd like to see added to the hal_usart drivers:

  • Add code to HAL_UART_IRQHandler() to handle the UART_FLAG_IDLE condition when receiving under DMA, with a callback hook that is invoked when the RX idle condition occurs. Based on the current organization of the hal_usart module, it probably makes best sense to add a separate callback hook, e.g., 'HAL_UART_RxIdleCallback()' or similar.
  • Provide a way for the RX idle callback to determine how much data the RX DMA has received, probably by adding or reusing a member of UART_HandleTypeDef.

With this addition, it should be possible to use the stock HAL routines to manage variable-length RX messages while preserving the efficiency advantages of DMA.

I'm going to try hacking a copy of the hal_usart driver to add this feature, and if it's wildly successful, I'll post it as an update for the curious.

Associate II

USART RX IDLE Handling in HAL is very important feature! When will it be supported in HAL?!

Tamas Novak
Associate III


is there advance at any STM32 lines' HAL as of March 2020 (speaking of DMA-receiving of IDLE separated variable-length UART messages)?

The stock HAL can already be used with DMA and idle line detection. That's what I'm doing now. Just enable the idle interrupt and respond with your own user code in the user code areas of the UART ISR. The user code areas are preserved when the CubeMX is used to re-generate code, so you can already insert a call to your own callback function, or do what I do and just put the interrupt response that you want directly into the ISR. Either way, the HAL is already compatible with what you want to do.

What's not supported as far as I know is to interrupt on a specific byte value, which would be really handy for responding to carriage returns, etc.


Good morning all

Can ST do anything about this problem?

I use the register_callbacks in order to leave my code clean and I therefore use a DMA channel in RX with HAL_UART_RX_HALFCOMPLETE_CB_ID and HAL_UART_RX_COMPLETE_CB_ID. It is just missing a HAL_UART_RX_IDLE_CB_ID ......

Is it so difficult to add an IDLE callback to MX Cube?

For now, I am forced to modify a user section in the IRQ Handler. It's just rotten.

Does HAL have a chance to see this callback appear?

The first post dates from 2017 ?! We are in 2020 no ?

Thank you.


2021 !!! happy new year !!!