STM32U5 UART: Unexpected Dependency on HAL_HalfDuplex API for RS485 Operation

[PatriceL]

hello community !

I'm facing issue wiht RS485 mod on USART3. Please find here a TL;DR of the issue, context, workaround and finaly request for answers.

HARDWARE PLATFORM

• MCU: STM32U595
• USART: USART3 configured in RS485 mode

PROBLEM DESCRIPTION:
During development of RS485 communication firmware for the STM32U595, we encountered an
unexpected issue that challenged our understanding of the USART configuration: USART3 is configured with RS485 mode via HAL_RS485Ex_Init() which correctly sets the DEM (Driver Enable Mode) bit in CR3 for hardware-controlled driver enable:

HAL_RS485Ex_Init(uart_handle, UART_DE_POLARITY_HIGH, 16, 16);

This is the documented, correct approach for RS485 with automatic driver enable pin control.

However, after extensive investigation and troubleshooting, we discovered that working RX/TX communication on this specific hardware appears to require ALSO calling:

HAL_HalfDuplex_EnableTransmitter(); // - before transmission
HAL_HalfDuplex_EnableReceiver(); // - in transmission complete callback

This is highly counterintuitive because:

• The HAL_HalfDuplex_* API functions are documented for single-wire half-duplex mode (HDSEL bit)
• Our USART is configured in RS485 mode (DEM bit), not half-duplex mode (HDSEL bit)
• These are mutually exclusive modes according to the reference manual
• We initially avoided using these functions because we knew they weren't the correct API for RS485

DEVELOPMENT HISTORY:
Initial Approach (Correct by Documentation):

• Configured USART3 with HAL_RS485Ex_Init() for RS485 mode (DEM bit)
• Did NOT use HAL_HalfDuplex_* API functions (as they target HDSEL mode, not RS485 DEM mode)
• Expected this to be the correct, documented way to use RS485 mode with hardware driver enable
• Result: Communication problems emerged during testing

Investigation:

• Attempted to enable DMA-based reception with HAL_UARTEx_ReceiveToIdle_DMA()
• Implemented proper error callbacks and recovery mechanisms
• Observed inconsistent data reception and communication freezing during RS485 bus activity
• Searched documentation and HAL code for potential issues

Breakthrough Discovery:

• During hardware testing with the engineering team, we systematically tested various configurations
• Testing removing/adding different initialization sequences
• Found that adding HAL_HalfDuplex_EnableTransmitter() before TX and HAL_HalfDuplex_EnableReceiver() in TxCpltCallback RESOLVED all communication issues
• This was unexpected because these functions are documented for single-wire half-duplex mode (HDSEL),
  not RS485 mode (DEM)

Current Production Code:

• HAL_RS485Ex_Init() - Configures RS485 mode (DEM bit)
• HAL_HalfDuplex_EnableTransmitter() - Called before transmission
• HAL_HalfDuplex_EnableReceiver() - Called in TxCpltCallback after transmission
• Result: Stable, reliable communication

TECHNICAL CONTEXT:
HARDWARE CONFIGURATION (DE Signal):

• GPIO PB14 is configured as alternate function GPIO_AF7_USART3
• This configuration allows the USART3 peripheral to automatically manage the RS485 DE
  (Driver Enable) signal without any firmware intervention
• When RS485 mode is enabled (DEM bit set), the USART automatically asserts/de-asserts DE
  on this GPIO pin during TX/RX transitions
• No manual GPIO control is needed or expected

This is the documented approach for RS485 with automatic DE management per the reference manual.

USART MODE CONFIGURATION:

• The HAL_HalfDuplex API functions are documented as targeting single-wire half-duplex mode,
  which uses the HDSEL bit in USART CR3 register, NOT the RS485 DEM bit.
• Our initialization uses RS485 mode (DEM bit), not HDSEL mode (HDSEL bit).

According to the reference manual and HAL documentation:

• HAL_HalfDuplex_EnableTransmitter() manipulates HDSEL and TE/RE bits for single-wire mode
• HAL_HalfDuplex_EnableReceiver() performs corresponding receiver manipulation
• These functions should have no effect on an USART configured in RS485 mode (DEM, not HDSEL)

The paradox: Despite GPIO PB14 being properly configured for automatic DE control by the USART hardware, and despite RS485 mode being correctly enabled, we observe that communication cannot be established without calling the HAL_HalfDuplex_* API functions (which are documented for a different mode).

This observation could indicate:

• A hardware behavior or interaction not detailed in current documentation
• An undocumented dependency between RS485 mode and half-duplex mode on STM32U595
• A specific initialization requirement that may not be explicitly documented
• A potential misunderstanding on our part regarding proper RS485 initialization

QUESTIONS:

Is there an undocumented interaction or dependency between RS485 mode (DEM bit) and the

• HAL_HalfDuplex_* API functions (which manipulate HDSEL and TE/RE bits)?
• Why would calling HDSEL-targeting functions affect an USART explicitly configured in
  RS485 mode (DEM, not HDSEL)?
• Could this be related to the specific interaction with DMA-based reception
  (HAL_UARTEx_ReceiveToIdle_DMA) or hidden settings (option bytes ?) ?
• What is the officially recommended approach to properly control transmitter/receiver
  switching in RS485 mode on STM32U595 when using DMA-based communication?
• Would clarification in the reference manual or an application example be helpful for
  developers implementing RS485 on STM32U595?

ADDITIONAL CONTEXT:

We have verified:

• Correct register bit configuration (DEM set, HDSEL not set)
• Proper RS485 transceiver hardware (external DE pin control)
• FIFO enabled, oversampling 16x
• DMA-based RX/TX with proper buffer management
• CRC error handling and automatic recovery

Despite all correct configurations by documented specifications, communication cannot be established without the HAL_HalfDuplex_* calls. This suggests either an undocumented hardware interaction or a critical aspect of USART initialization that we may have overlooked.

CURRENT SOLUTION:
After systematic investigation and testing, the configuration that achieves stable RS485 communication in our testing is:

• Configure USART3 with HAL_RS485Ex_Init() for RS485 mode (DEM bit)
• Call HAL_HalfDuplex_EnableTransmitter() before each DMA transmission
• Call HAL_HalfDuplex_EnableReceiver() in the transmission complete callback
• Add error detection and recovery callbacks (error handling for robustness)
• Enable FIFO mode (UART_OVERSAMPLING_16) for buffering tolerance
• Optimize DMA channel priority for RS485 USART

While this achieves reliable communication, it requires using APIs that are primarily documented for
a different mode (HDSEL). Understanding the reason for this dependency would help ensure this is the
optimal long-term approach and would benefit other developers implementing RS485 on this platform.

IMPACT:
This finding has significant implications:

• Documentation Gap: The STM32U595 reference manual does not currently detail this dependency for RS485 mode operation
• Maintenance Risk: Future developers may question why these particular API calls are in the code, which could lead to unintended changes
• Troubleshooting: This creates an unusual situation where the code implementation appears inconsistent with the documented USART modes (HDSEL vs RS485 are described as mutually exclusive)

We have performed systematic investigation and testing before implementing this solution.

We respectfully request insights from the community and STMicroelectronics product experts regarding:

• Whether this is expected behavior that should be formally documented
• If there are alternative approaches we may have overlooked
• Whether a technical note or application example would be beneficial for other developers

[Andrew Neil]

So where was the TL;DR ?