And again: Incorrect handled UART overrun error in stm32f4xx_hal_uart.c

[UMau.1]

I have to design a special USB <-> RS485 converter using an STM32F401.

I realized the project at first with a STM32F4071G eval board with DMA supported USART functions and without RTOS using STM32Cube with FW-F4_V1.25.1 and all worked fine.

After porting the software to a Nucleo eval board with the target MCU STM32F401 the transfer from RS485 to USB also works perfect up to baudrates of 115200 and kilobytes of data per shot.

But from USB to RS485 after sending all data correct to the RS485 port the UART overrun ISR is called and the HAL remains in a permanent loop to resend the data getting now immediately the overun error and can only stopped by a reset.

The error occurs independent from baudrate (I tried it down to 300) and byte count. If I send only one byte over USB it crashes in the same manner as if sent 64 bytes (the maximal number of bytes for one USB transfer). The data will all be transfered and reach the RS485 device but the HAL_UART_TxCpltCallback will not be called than but the overrun interrupt.

I searched meanwhile here in the community and in the internet for a solution. But although this issue often was reported (especially for the STM32-HAL) by different users nowhere a solution was proposed.

The system clock is set to 84MHz, the APB1 peripheral clock to 42MHz. I can understand if in case of a slow MCU a overrun error may occur when receiving data from UART. But how this can occur when sending only one byte of data supported by DMA over UART? And how can I prevent the HAL from the permanent and senseless try to send the data again?

[TDK]

An overrun is something that would happen on reception, not transmission. Perhaps you can share more details (code) about what is actually failing. Hard to provide advice otherwise.

[Tesla DeLorean]

Watch that callbacks are done under interrupt context, it is very important not to block as the interrupt can't preempt itself.

[UMau.1]

@Community member​ 

I'm sure, that this was considered, the more so as the structure of the software was derived from a STM demo project and works fine on STM32F407.

@TDK

Yes, and that's why I was so baffled about the occurence of this interrupt after transmission.

I tested it in this constellation:

Terminal1 on PC <-> [ STM32 Nucleo USB <-> STM32 Nucleo USART1 ] <-> FTDI USB/Serial TTL <-> Terminal2 on PC

The transfer from Terminal2 to Terminal1 (means USART is receiving) works fine and the data reaches Terminal1, the transfer from Terminal2 to Terminal1 (means USART is transmitting) is blocked after transmission of the first packet even though the data reaches Terminal1 one time.

The USART1_IRQHandler is called cyclic from the overrun error interrupt and the HAL_UART_TxCpltCallback will never be reached.

For tests I removed the connection from the FTDIs TxD port to the PA10 (RxD) of the NUCLEO board to be sure that no incoming data reaches the UART. Regardless the overrun interrupt occured.

Attached is a stripped project with the critical parts for the NUCLEO-F401RE eval board to demonstrate the issue.

Create within the directory UART_OVERRUN with STMCube the source code from UART_OVERRUN.ioc. Than copy the content from UART_OVERRUN_USER to UART_OVERRUN and you can build the Project.eww in UART_OVERRUN/EWARM/.

LD2 represents the direction control for the RS485 converter in the final hardware. It is activated prior the start of the USART transmission and should be deactivated after the end of transmission. But you will see, that it will keep lighting until you press the reset button. Hitting only one key in Terminal1 is sufficient to block the transmission from Terminal1 to Terminal2 permanently. But the transmission from Terminal2 to Terminal1 stays functional after the occurence of this issue.

[UMau.1 · Accepted solution]

Thanks for your support.

The problem was sitting at the keyboard.

Porting the project from a completely different source file structure to the actual structure generated by CubeMX there arised two different UART-handles in two files where only one was initialized.

The issue is solved.