Why do not I have an overrun error? (UART + DMA)

[David Martins]

Posted on July 06, 2017 at 11:08

The problem is simple ...

I am using the UART with DMA to copy 10 bytes to a memory location.

Sometimes (due to some error) 11-byte packets are sent to the MCU. What happens is that the DMA will transfer the 10 bytes and stops, but one byte remains in the UART buffer.

When I send more bytes to the MCU (already after restarting the DMA) the DMA is never called by the UART.

I've easily seen that it was an overrun error, but when using the HAL_DMA_GetError() or HAL_UART_GetError() functions, no error is registered.

I started doing the following, to have this work (because the

UART_FLAG_ORE changes in fact

 ) ...

if (__HAL_UART_GET_FLAG(&huart2, UART_FLAG_ORE))

{

      __HAL_UART_CLEAR_OREFLAG(&huart2);

}

The problem is solved ... but I find no explanation for any of the functions of get error do not work.

Can you explain?

MCU: STM32F302R8T

Thank you

#overrun #uart-dma #dma #uart #stm32f302

[waclawek.jan]

Posted on July 06, 2017 at 20:46

And have you looked into Cube?

In F4 Cube v1.4 I could find only one instance where HAL_UART_ERROR_ORE is used, in HAL_UART_IRQHandler()

  tmp1 = __HAL_UART_GET_FLAG(huart, UART_FLAG_ORE);

  tmp2 = __HAL_UART_GET_IT_SOURCE(huart, UART_IT_ERR);

  /* UART Over-Run interrupt occurred ----------------------------------------*/

  if((tmp1 != RESET) && (tmp2 != RESET))

  {

    __HAL_UART_CLEAR_OREFLAG(huart);

    huart->ErrorCode |= HAL_UART_ERROR_ORE;

  }

I promised myself to try hard to avoid commenting on Cube.

JW

[waclawek.jan]

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.

[Tesla DeLorean]

Posted on July 06, 2017 at 22:03

Overrun suggests you're ignoring an RXNE. Likely losing more than one byte.

So many race, blocking, and other hazards in Cube. I see problems on even the most trivial implementations, not sure how a robust product can be built with it.

>>

I promised myself to try hard to avoid commenting on Cube.

I've regressed to register level programming, it is that bad.

[David Martins]

Posted on July 07, 2017 at 10:44

Okay, so far the situation is controlled ...

But I think that 'Cube' is a great idea, but it can not have 'simple' mistakes like this.

The problem seems to be registered since 2012 ...

How can we proceed so that the ST team solve this error? They already know it exists ... but stupidly they did not correct it.

At the moment I have several projects to use STM (me, my company and other partners), but I can not waste time fighting with bitfield (these years have passed ...). If these situations continue I will change to another MCU, something that gives me more confidence.

[waclawek.jan]

Posted on July 07, 2017 at 10:55

The problem seems to be registered since 2012 ...

As I've said above, I was not talking about your particular problem, but a different one (namely if RXNEIE is enabled - which is not your case as you use DMA - a dangling ORE may result in the system being locked up continuously repeating ISR). I believe the symptoms you are describing are more related to incorrectly set up USART interrupt. You should verify it fires when ORE occurs.

[...] I can not waste time fighting with bitfield (these years have passed ...). If these situations continue I will change to another MCU, something that gives me more confidence.

Oh, the 'libraries' and confidence... Then I wish you good luck!

JW