cancel
Showing results for 
Search instead for 
Did you mean: 

How is the proper way of recovering from a UART overrun condition in STM32F030R8T6 ?

Marcelo Barros
Associate III
Posted on April 17, 2016 at 16:36

Hello,

We are using a discovery kit based on STM32F030R8T6 uC and facing a strange condition. When using both serials (UART1 and UART2), both in interrupt mode, there is a overrun error happening from UART1 and we can't recover from such situation.

Some info:

- use a using the latest HAL available in Cube

- we are handling error/rx/tx callbacks as specified in hal documentation

- both serials are running at 115200bps

- uC is running at 48MHz

- we are using interrupt mode for both serial, tx and rx

- when using only serial1 or serial2 the problem does not occur

- our IRQ are following the order: systick(0)/uart1(1)/uart2(2)

- uart1 is rs232, uart2 is rs485

I did several changes, without success. The last ones:

- in error callback, we read the DRD if RXTE is enabled and we started a new interrupt programming (there is a hint about this in manual): no success

- we tried to clean several interrupt error indications like we can see searching in this forum (http://is.gd/QrGiDE)

After the first overrun, the serial1 stops to work. We think the problem is related to the way we cleanup the messy and restart the serial1.

Could you provide some light over this topic ?

Thanks a lot

Marcelo

#stm32f030r8-serial-uart-overrun
1 REPLY 1
Marcelo Barros
Associate III
Posted on April 19, 2016 at 02:28

Following instructions from reference manual, I read status register  (SR) before any usart reception. So, if overrun flag is set, it is necessary to read data register (DR). Probably the data read is the latest valid data as the next one was corrupted in shift register.

Without this action, RXEN is not set anymore, for some reason. I imagine it is not set because the uart can not receive any new byte as it is in a overrun state.

However, when calling HAL function HAL_UART_Receive for uart reception, it does not care about overrun and waits for RXEN = 1 before some timeout. This never happens, the timeout expires and the function returns.

Just sharing some results.