Description
I had an application that occasionally appeared to lock up when was receiving data on a uart. The uart had a RX interrupt handler attached so the receive interrupt was enabled.
I was able to reproduce the issue while running the application with a debugger attached and found that the device was executing the serial interrupt handler in a tight loop. Reading the uart registers revealed that the ORE bit was set in the UART->CR.
According to the reference guide, the RXNE interrupt can fire if either the RXNE flag or the ORE flag in UART->CR is set. The ORE flag can only be cleared by a software sequence: read UART->SR then read UART->DR.
My application is apparently encountering a situation where ORE is set but RXNE is not set. The uart_irq() function in targets/hal/TARGET_STM/TARGET_STM32F4/serial_api.c does not handle this situation. The result is that the ORE bit does not get cleared and the device gets stuck in a tight loop, appearing to be locked up.
I think the serial irq handler should handle the ORE case as well as the TC and RXNE cases, especially since the RXNE interrupt can also be triggered by the ORE flag. I modified the interrupt handler to handle the ORE flag and this resolved the issue.
static void uart_irq(UARTName name, int id)
{
UartHandle.Instance = (USART_TypeDef *)name;
if (serial_irq_ids[id] != 0) {
if (__HAL_UART_GET_FLAG(&UartHandle, UART_FLAG_TC) != RESET) {
irq_handler(serial_irq_ids[id], TxIrq);
__HAL_UART_CLEAR_FLAG(&UartHandle, UART_FLAG_TC);
}
if (__HAL_UART_GET_FLAG(&UartHandle, UART_FLAG_RXNE) != RESET) {
irq_handler(serial_irq_ids[id], RxIrq);
__HAL_UART_CLEAR_FLAG(&UartHandle, UART_FLAG_RXNE);
}
if (__HAL_UART_GET_FLAG(&UartHandle, UART_FLAG_ORE) != RESET) {
uint8_t c = UartHandle.Instance->DR;
}
}
}I'm looking for some community feedback. Should the API instead be expanded to allow a separate handler to be attached for overrun in addition to TX and RX?