Nucleo F767ZI - system freeze upon UART ORE interrupt

[Nissan Aloni]

Hi,

My system (MCU) gets into a state where I can't debug it when i get a UART interrupt due to ORE.

I even tried placing breakpoints at the places where ORE is captured in the IRQ handler - but the debugger didnt stop and I lost the connection to the target.

I found couple of threads that deal with this situation and they suggested to implement HAL_UART_ErrorCallback() and clear the ORE.

I've implemented it by:

// clear ORE by reading SR and then read DR

g_uart_sr = huart->Instance->ISR;

g_uart_dr = huart->Instance->RDR;

This seems to have solved the issue and the system is now stable and able to run for long hours.

However, I'm bothered by this behavior and would like to understand it better.

Any official documentation for this issue?

Any official documentation on how to properly debug and handle ORE?

Thanks.

[Tesla DeLorean]

It's not cleared by reading the registers as I recall. The documentation says you have to write to the ICR. If you don't clear the interrupt source the handler will keep re-entering (tail-chain) indefinitely.

...
		if (USART_RS232->ISR & USART_ISR_ORE) // Overrun Error
			USART_RS232->ICR = USART_ICR_ORECF;
 
		if (USART_RS232->ISR & USART_ISR_NE) // Noise Error
			USART_RS232->ICR = USART_ICR_NCF;
 
		if (USART_RS232->ISR & USART_ISR_FE) // Framing Error
			USART_RS232->ICR = USART_ICR_FECF;
...

[Nissan Aloni]

Thanks for the reply.

I found the following threads:

1. https://github.com/ARMmbed/mbed-os/issues/1605

"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."

1. https://github.com/micropython/micropython/issues/3375

"The reason is because the UART RX ISR function does not clear the ORE flag if the receive buffer is empty and hence the irq is starting again as soon as the handler exits (ORE is also triggering the IRQ). It results in a 100% CPU utilisation."

I was looking for some official information about these issues.

In addition - it's not clear to me why my breakpoints at the UAR_IRQHandler didn't catch this situation. Instead - my Atollic debugger lost connection to the target.

Thanks.

[Tesla DeLorean]

>>I was looking for some official information about these issues.

I'm using Keil, and not using the HAL USART IRQ non-sense. Really not looking to get involved in Atollic issues, or those the library creates.

The Cortex-M3/M4 interrupt storm issue, where it tail-chains back into the IRQ Handler, with no foreground code execution, is something I've discussed for a decade. There is another issue with the pipelining and write-buffers, there you need to clear the sources early so the NVIC doesn't see them still signalling when it chooses where to go next.

I have found the STM32 Reference Manuals adequately describe the hardware, issues that result in not fully grasping the subtleties are pitfalls and hazards I cover here occasionally, but not in an official capacity.

For official opinions you should sit down with the FAE assigned to your account.

[Nissan Aloni]

Thanks Clive! Really appreciate your help and support!

Can you refer me to some of the threads in which you describe the pitfalls and how to overcome them?