Question: I would like to know to know why UART errors occur, and when one should check for such errors. There is a post on here that asks about handling individual errors, such as overrun, parity, etc... I am clear on why data overrun happens, why parity error happens, but I would like to know what is the root cause. My question is more focused on why these errors could occur (physical reasons), and when one should do make error checking a factor for their application.

So far my program seems to work great (with no error checking), but I know that noise can mess things up. How could I simulate conditions that could cause the UART Rx/Tx ports to fail?

Answer: 
There are several potential sources for [noise](http://en.wikipedia.org/wiki/Noise_%28electronics%29) in any circuit. Some of the most common include:

* Poorly regulated power supplies;
* Switching power supplies;
* Insufficient [capacitive decoupling](http://en.wikipedia.org/wiki/Decoupling_capacitor) of the power rails near the MCU;
* [Inductive coupling](http://en.wikipedia.org/wiki/Inductive_coupling) of nearby electromagnetic sources (including 50 or 60Hz from the mains power; even if the circuit is battery powered, it will experience this interference when close enough to a mains source);
* RF sources near the resonant frequency of a trace on the circuit board, or one of its harmonics;
* Routing of high-current traces on the circuit board near signal lines;
* Etc.

In addition (as @jippie mentioned), clock skew is a very common cause of errors in any type of serial communication that uses a predetermined data rate. If you're using an external crystal and interfacing to another system that can reasonably be expected to be accurate, it's less likely to cause problems. Internal oscillators, however, can have tolerances that are several orders of magnitude worse than crystals, and tend to vary more over temperature ranges. 

There are several basic tests that can be performed on a running system to determine the basic noise (and skew) immunity of your interface, including:

* Freezing (cool the circuit to the minimum rating of its components);
* Baking (heat to the maximum rating);
* Exposure to [EMI](http://en.wikipedia.org/wiki/Electromagnetic_interference):
	+ Set the board on top of the power cord of a running space heater;
	+ Key a CB radio in the near vicinity of the board;
	+ Put the board next to your wireless router;
	+ Use long hookup wire (instead of a properly constructed serial cable) for the UART connection.

There are many others--in fact, there are large testing labs dedicated to [EMC](http://en.wikipedia.org/wiki/Electromagnetic_compatibility) qualification.

In general, unless some minimal level of data loss is acceptable, it is always prudent to include some sort of error checking in your communications code. Even a simple checksum is better than nothing.
Most errors stem from three causes: (1) the transmitter's generated signal did not represent valid data; (2) the transmitter's signal was not received as generated, or (3) the receiver was not ready to handle the data when it was received. The most common cause I've seen for problem #1 is a transmitter that gets reconfigured or shut down while it is transmitting data. Problem #2 can easily occur for signals traveling through the "outside world" as a result of things like radio interference (mobile phones can be surprisingly nasty!), but should generally not occur for signals confined to a single board. Problem #3 can either occur because too many bytes arrive faster than they can be processed, or because the receiver is reconfigured, shut down, or started up during a transmission.

In many cases, it's difficult to completely eliminate all of these problems; one's goal should be to ensure that the total "damage" done by them (probability of occurrence, times damage per occurrence) is acceptably low. This can most easily be done by choosing a pessimistic estimate of reliability, and then designing a protocol so that the impact on system performance of even the worst failures that were consistent with one's estimates would be within acceptable limits.