cancel
Showing results for 
Search instead for 
Did you mean: 

STM32 HAL UART Error managment

mgualdi9
Associate II
Posted on October 12, 2015 at 17:27

Hi All,

i have a problem with the managment of the UART Error.

Particularly when the error occurs in ''HAL_UART_ERROR_ORE'', the device is locked and I can not clear the error.

I tried using the following instructions, under callback error funcion:

void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart)

{

__HAL_UART_SEND_REQ (Huart, UART_RXDATA_FLUSH_REQUEST);

uint8_t tmp = (uint8_t) huart-> Instance-> RDR;

__HAL_UART_CLEAR_OREFLAG (Huart);

huart->ErrorCode = HAL_UART_ERROR_NONE;

}

But the error flag continues to recover, and the UART remains locked.

Thank you,

Mauro.

#stm32 #uart #hal
6 REPLIES 6
Posted on October 12, 2015 at 19:57

Does the error reoccur even if you stop the incoming data source?

JW
rbenesh
Associate II
Posted on October 12, 2015 at 23:40

An error callback usually means something is wrong with the transmission. Rather than work it in the callback; perhaps step through the transmission and receive routines and see which line is triggering the error. I havent looked this up but, I want to say the ORE is an buffer overrun event. The error might be getting cleared in the callback but being set again by the buffer still running over its banks.

mgualdi9
Associate II
Posted on October 13, 2015 at 09:00

Hi waclawek,

Yes, the error persists even when the data on the UART are stops.

The error is generated by me, by sending a string of 3 characters and stopping the debug code in the reception of the first character.

Posted on October 13, 2015 at 19:28

> The error is generated by me, by sending a string of 3 characters and stopping the debug code in the reception of the first character.

Ah, so you wanted to test what happens?

Do you display the UART registers in the debugger during this? Debugger can be intrusive; OTOH I don't understand the mechanism why this would cause stuckup.

As NStuff wrote above, the HAL ''driver'' appears to clear the error itself directly in the ISR before calling the callback. Observe the UART registers in the debugger - does the real overflow flag get cleared or not?

Jan
mgualdi9
Associate II
Posted on October 20, 2015 at 08:28

Hello,

yes, I was testing the behavior of the serial on error.

From debugger I also checked the registers of the UART, and I noticed that the bit error is not cleared, and the perifrica stuck.

Thank you,

Mauro.

anonymous.8
Senior II
Posted on October 27, 2015 at 14:51

Hello,

which STM32 series are you using?

I think HAL driver implementations differ a little bit from one family to the other