10
\$\begingroup\$

I am not concentrating on a Specific MCU as UART of most controllers has similar architecture. They have FIFOs for Both Tx and Rx.

Most common errors generated by UART are:- 1. Framing Error 2. Parity Error 3. Over-run Error (Overflow of Tx/Rx FIFOs) 4. Receive Break Error (Some Error with Stop Bits)

How one should handle these Error Conditions to maintain communication properly?

I do understand it's a vague question but most of the time people get confused about what one should do when such errors occur and end up in just clearing the error bits.

\$\endgroup\$

3 Answers 3

8
\$\begingroup\$

To actually answer your question, I usually discard anything received with error. That may include re-initializing the UART hardware, depending on what error it is and the details of the UART hardware.

The only exception is if you want to deliberately receive breaks. Those show up as framing errors. In that case you pass framing errors up to the higher levels as special conditions. However, that requires out of band information to be passed to the higher levels and therefore the UART receiver interface can't be seen as something quite as simple as getting a stream of bytes. I think I've done this exactly once in many microcontroller projects because it had to be compatible with a old system where breaks were used deliberately.

Steven has given you some good ideas what to do about this at the higher level. When you think there is a real chance of errors and data integrity is important, then you usually encapsulate chunks of data into packets with checksums. The receiver sends a ACK for every correctly received checksum.

However, the vast majority of the time UART errors are so unlikely and not absolutely critical that you can just ignore them at the high level. The kind of errors the UART hardware can catch are usually due to operator stupidity, not line noise. Most like noise will cause bad data, which the UART won't detect. So the low level UART driver throws out anything immediately associated with a UART error, but otherwise continues to pass the stream of received bytes up to the next level. In fact it does this even if you are using packets and checksums since that is done at a higher level than where individual bytes are received.

\$\endgroup\$
12
\$\begingroup\$

These errors can't be fixed, so retransmission is required. This needs some protocol at a higher level than the UART; you'll typically want to acknowledge the correct reception of a packet of data. This packet may be 1 byte, but also longer packets can be used if the communication has little errors. Acknowledge each packet by sending an ACK to the transmitter, a NACK if an error has occurred. In the latter case discard the packet and wait for retransmission.
If you use packet transfers you may want to consider CRC error checking instead of parity, which isn't very efficient (adds 1 bit per byte) and only catches single bit errors.

\$\endgroup\$
5
\$\begingroup\$

When there is a framing error in received UART data, odds are good that all succeeding bytes are going to be garbage until, depending upon the UART, there are either ten or more bit times between consecutive falling edges on the data wire, nineteen bit times of consecutive spacing, or nine bits times of consecutive marking (the last of those will work on all UARTs). If one receives a correctly-framed byte with value 0x00 or 0x80 (0x100 in 9-bit mode) and either the transmitter does not send long breaks or the receiver will stop trying to parse bytes out of any long break the transmitter sends, one can be assured that it is correct and succeeding bytes will be correct as well. If one receives a value in which there are 0-6 consecutive "zeroes" in the lower bits, and the remaining bits are all set, that byte value may or may not be correct but succeeding bytes will be (one could e.g. receive a value of 0xC0 when the transmitter was trying to send 01).

S=START P=prev byte data s=stop D=current byte  - =idle
0111111101000000011111 -- Signal on line
Ps------SDDDDDDDDs--- : As intended by transmitter (0x02)
SPPPPPPPPsSDDDDDDDDs- : As received (0xC0)

If each packet starts with 0x00 and is followed by 0xFF, a framing error on one packet will not affect the next. When the receiver notices the framing error, it can start discarding data until it sees a properly-framed 0x00, whereupon it will know that it has a legitimate start of packet.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.