Posted on July 06, 2017 at 23:29 So, for further enlightenment, I downloaded the current v1.16 CubeF4, and with the whopping 400meg packed/1.3gig unpacked I was indeed rewarded by a higher level of sophistication.
The ISR reads the SR into an
isrflags
variable, then masks it
errorflags = (isrflags & (uint32_t)(USART_SR_PE | USART_SR_FE | USART_SR_ORE | USART_SR_NE));
and it won't test for RXNE if errorflags is nonzero (or, in Cube parlance, not RESET).
A further if has a promising condition
/* If some errors occur */
if((errorflags != RESET) && (((cr3its & USART_CR3_EIE) != RESET) || ((cr1its & (USART_CR1_RXNEIE | USART_CR1_PEIE)) != RESET)))
but it then ends up testing the individual flags, and for ORE it has to do the following:
/* USART Over-Run interrupt occurred -----------------------------------*/
if(((isrflags & USART_SR_ORE) != RESET) && ((cr3its & USART_CR3_EIE) != RESET))
{
husart->ErrorCode |= HAL_USART_ERROR_ORE;
}
Humm.
Just for fun,
https://community.st.com/thread/25821
is one of the several dozens of threads dealing with the same or similar issue during the past years - note the SPL changelog snippet at the end.
And for the record: I don't pretend I know how to deal with the U(S)ART-overrun in STM32 correctly, neither in a polled nor interrupt nor DMA-driven case. Yes I've bitten by it recently (and yes I repeatedly wandered how comes ORE set once RXNE is clear); but had no time nor energy to drill down to the roots, just threw in the patch.
JW
PS. I understand that this still does not answer the original question. My reading of Cube is that the DMA-driven Rx does enable the EIE interrupt; but I am not sure whether it guarantees that the respective ISR is properly enabled and linked to; or whether there are any other circumstances which would prevent husart->ErrorCode being set when ORE occurs.
