Behaviour of HAL_UART_ErrorCallback

[Andrew Neil]

It seems that, if an error occurs on the last (or only) byte of a HAL_UART_Receive_IT transfer, the HAL_UART_ErrorCallback will not be called until after the HAL_UART_RxCpltCallback - is that right?

STM32F0 Cube package.

[STea]

Hello @Andrew Neil ,

can you give us the reason behind this conclusion was it found by testing, or this was concluded after the examination of HAL implementation?

Regards

[Andrew Neil]

Both - started by looking at the code, then tested

[STea]

Hello @Andrew Neil ,

From a Hardware point of view, I think booth events are not related:

but in the HAL implementation the enable of the UART Error Interrupt: (Frame error, noise error, overrun error) is inside the UART_Start_Receive_IT maybe try to set this bit before entering the interrupt and you should be able to detect errors once the HAL_UART_IRQHandler is called we test if error accrued if this bit set and not cleared this on the entry of the function :

if ((errorflags != 0U)
      && (((cr3its & USART_CR3_EIE) != 0U)
          || ((cr1its & (USART_CR1_RXNEIE | USART_CR1_PEIE | USART_CR1_RTOIE)) != 0U)))

Regards

[Andrew Neil]

The errors are being detected OK.

It's just that, if the error occurs on the last (or only) byte of the transfer, the 'Error' callback is not called until after the 'Complete' callback - which seems wrong to me.

On any other byte in a multi-byte transfer, the 'Error' callback is called first - which seems correct to me.

The error can be seen in the huart->ErrorCode in both callbacks, and the 'Error' callback makes that no easier to access - so it actually looks like the 'Error' callback is pointless?

[STea]

Hello @Andrew Neil ,

it is not pointless because it gets called also when a DMA error or abort is called so you can implement a routine in it to recover from DMA errors as well.

another thing worth mentioning is that Error is considered as Blocking: Transfer could not be completed properly and is aborted. so, it is blocking in the transfer context only.

the order in which they are called doesn't matter that much I assume as the error callback could not be implemented, and we could handle errors in the 'Complete' callback'.
In fact, if you could explain how you think this could affect the behavior. and why it doesn't seem right to you if it gets called in after the CPT callback.

Regards 

[Andrew Neil]

---

@STea wrote:

Hello @Andrew Neil ,

it is not pointless because it gets called also when a DMA error

---

OK, I mean it's pointless in a HAL_UART_Receive_IT  transfer - which is the case under consideration.

---

@STea wrote:

the order in which they are called doesn't matter that much

---

I disagree.

If the 'Error' callback always comes first, then I know that I will always get the 'Complete' callback after it.

But if the 'Complete' callback comes first, I don't know whether an 'Error' callback will follow or not!

[STea]

Hello @Andrew Neil ,

I agree with you on the second point you mentioned this makes the code unpredictable and not deterministic but 

---

@Andrew Neil wrote:

---

But if the 'Complete' callback comes first, I don't know whether an 'Error' callback will follow or not!

---

you can know if you will get an error callback if the error code in the complete callback is not empty, I assume the problem will be when the error occurs after the complete callback is raised, I think. 
but from the HAL implementation that I'm examining I don't see how this could be the case can please share with me the example that you are implementing to provoke such behavior.

Regards  

[Andrew Neil]

---

@STea wrote:

you can know if you will get an error callback if the error code in the complete callback is not empty,

---

I know - which is why I said the 'Error' callback seems pointless in this context:

If you can already see the error from the 'Complete' callback, then the 'Error' callback adds nothing - ie, it's pointless.

---

@STea wrote:

please share with me the example that you are implementing to provoke such behavior.

---

I'll have to make an example ...

[Pavel A.]

>I'll have to make an example ...

Sure enough. No good deed goes unpunished.