UART misalign received data after previous receive timeout

[schperplata]

Posted on November 02, 2017 at 12:35

Hello,

I'm having a problem making my UART communication robust on error. (two STM32F07xx custom boards communicationg through UART3, HAL + CubeMx). I have custom protocol (quite simple), fixed message length + acknowledge.

During normal runtime, I can correctly receive and transmitt data. If I intentionally (or unintentionally) insert some delay in code (elsewhere, not related to communication part of the project), thereceive part of the two boards should:

- get UART receive timeout,

- log an error into error log buffer,

- flush data register and

- continue to receive/send/communicate.

In reality it does everything except that any receivedata after first timeout is misaligned. For example,

during normal communication with no errors, this is received:

0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF�?�?

On error, when data is not received and UART driver throws receive timeout (aka HAL_TIMEOUT), all the data is received corectly with additional byte at the beggining, causing data to be misaligned and therefore all wrong:

0x00 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF 0xFF

What could cause this additional byte in reading data after previous rx timeout?

I receive data in blocking mode, using:

rx_status = HAL_UART_Receive(&huart3, data, MSG_SIZE, UART_BU_TO_CU_RX_TIMEOUT);

I tried to flush data register with all functions I could find (I think HAL documentation is a little bit unclear how to properly use this macros):

__HAL_UART_FLUSH_DRREGISTER(&huart3);

__HAL_UART_SEND_REQ(&huart3, UART_RXDATA_FLUSH_REQUEST); #flush #uart #timeour

[schperplata]

Posted on November 06, 2017 at 11:58

Porting project to other library (STD or LL) is not an option, since all other code is adapted to HAL library - and more important, currently I don't have time to waste time before my communication is not established reliably. Maybe later. Anyway, I didn't have any other problems with HAL so far, in fact I am quite a fan of CubeMX. It is not ideal, but for someone who is not here from the very beginning and knows every register of ARM Cortex, CubeMX simplify development and initialization very nice. Anyway, I think this is other topic and more related to personal opinion (as far as there are things that can't be done with HAL and can be done on LL).

I already checked xmodem and zmodem, but they are more like file protocols. Modbus is close enough but maybe a bit overkill (or not. Currently I am quite confused all available options and I need to sit down and re-think what my project really needs and not what I wish my protocol must support). The search continues...

[AvaTar]

Posted on November 06, 2017 at 12:37

With porting, meant different architectures and environments.

I'm currently confronted with Cortex M4, an 80251 derivate, and a Fujitsu proprietary MCU, all running (partially) the same code. Try to see Cube/HAL in this context ...

... in fact I am quite a fan of CubeMX.

Fine for you ... ;)

... but for someone who is not here from the very beginning and knows every register of ARM Cortex, CubeMX simplify development and initialization very nice

The ability to read and understand a datasheet/ ref.manual was and is essential for an embedded developer.

The more your job gets automated, the more likely you will be replaced by an automaton.

I already checked xmodem and zmodem, but they are more like file protocols. Modbus is close enough but maybe a bit overkill (or not. Currently I am quite confused all available options and I need to sit down and re-think what my project really needs and not what I wish my protocol must support).

The features especially interesting for you are packaging, error checking, and re-transmission handling.

As I said, ignore the protocol contents (data payload).