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.


Any news on this feature?

Associate II

This is a much needed feature, as well as a packet detection method like CR/LF detection or $ and *xx for GPS etc.

>> packet detection method like CR/LF detection or $ and *xx for GPS etc

No it doesn't, where do people learn how to code minimally simple tasks these days? You get an interrupt on every character, a high school kid should be able to code that state machine. SMH

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..
Associate II


Mary Solomo
Associate II

I also looking forward to this feature. Any news on this one?

Associate II

+1 on this request. Although easy to implement the simplistic approach proposed above, it still may be a source of issues when upgrading HAL versions

You're always going to have issues upgrading HAL, even from ST releases, and especially if they entirely change the paradigm, see the "New" CAN for a prescient example.

I'm not sure of any project that can survive an 18-month dependency on a vendor vs a refactoring task that might take less than a day across a whole slew of HAL / parts for a clean/concise implementation. There are about 3 USART implementations across 11+ years of silicon. The HAL USART code is already a rats nest and bulky, robust software does not come from doubling down on that, and it's patently clear ST doesn't rigorously test all the code paths or do regression testing.

Tips, Buy me a coffee, or three.. PayPal Venmo
Up vote any posts that you find helpful, it shows what's working..

Thanks for the heads-up, I'll try to avoid upgrading HAL then 🙂 Or at least do a full diff between versions to see how it impacts my application

Associate III

I managed to get this working relatively painlessly within the STM32CubeMX/HAL framework (without changing the driver). Thanks to Tilen Majerle and Lix N. Paulian.

Associate II

The STM32L4R5 also supports a 16-byte hardware FIFO that is completely ignored by CubeMX. This would not be needed if the serial port library supported the IDLE detect, or receiver timeout better.