Universal Asynchronous Receiver-Transmitters (UARTs) are foundational devices in embedded systems.  As generic interfaces, UARTs carry raw digital data using standards much simpler than USB.  When a UART signal is enhanced by another physical layer protocol such as RS-485 (also called EIA-485), it can carry serial data anywhere from a few millimeters or a few kilometers.

Should your UART run into trouble with data corruption, intermittency, or total loss of signal; there are a few easy starting points that can help you get back on track. 

Notice of Non-Affiliation and Disclaimer: As of the publication date, we are not affiliated with, associated with, authorized with, endorsed by, compensated by, or in any way officially connected with Microsoft, or their owners, subsidiaries or affiliates.

The names Microsoft, .NET, Windows as well as related names, marks, emblems, and images are trademarks of their respective owners.

External Links: Links to external web pages have been provided as a convenience and for informational purposes only. Unboxing Tomorrow and Voxidyne Media bear no responsibility for the accuracy, legality or content of the external site or for that of subsequent links. Contact the external site for answers to questions regarding its content.

Diagnosing a UART Converter: Loopback Test

If you rely on a UART to USB converter, you can investigate it easily using a loopback test.  To do so, you will need a terminal program such as RealTerm.

1. Plug the converter cable into your computer.
2. Short the cable’s TX and RX pins directly together.
3. Send characters from your terminal while it is in full duplex mode.

The terminal should echo back everything you send to it.  Any error—no matter how small—indicates a serious problem with the equipment, and you should investigate further or use a different converter if possible.

If you would like to do this over a local area network, consider using RealTerm’s Echo Port feature, which will redirect the data across your network.

Diagnosing the Signal Chain

Besides loopback approach, there are a few diagnostic questions you will need to ask yourself in order to isolate the problem…

“Am I using the Right Newline Character?”

If you’re dealing with any kind of command line interface, it’s extremely easy to use the wrong end of line (EOL) character at the end of your transmissions (or no character at all) and get no response from the remote equipment.  Depending on the software involved, there may be a distinction between print and printline, where one includes the terminating characters and the other does not.

Newlines are also defined by the operating environment. In Microsoft products (including the .NET framework), applications favor a carriage return (CR) character followed by a line feed (LF). This especially true of text files. Unix-like systems favor a lone linefeed (LF).

“How can I Prove the Formats Match?”

Clearly our UARTs need their baud, start bits, stop bits, parity and data bits to match between devices.  What is not so obvious is the default setting of your equipment.

Even if we have configured these settings ourselves, they can easily revert to a default if the UART device resets unexpectedly. It may be worth verifying the baud is what you expect using an oscilloscope in single-shot mode.

“Have I Read the Device Errata Sheet?”

Microprocessors are imperfect devices and often have one or more unwanted behaviors.  Easily overlooked: the device errata sheet will provide a list of such behaviors.  This includes errors in silicon itself that cannot be removed by programming, although it will usually come with tips for mitigation.

“Is my UART Transmitter in Push-Pull Mode?”

Push pull outputs have the ability to force their voltage high and low.  This is in contrast to open-collector or open-drain pins, which can only transmit out one voltage.

Open-collectors depend on an external pull-up or pull-down resistor to generate the opposite state, which is not the best option for signal integrity and will likely fail at lower baud than a push-pull equivalent.

“Is my Baud too High?”

If you have data corruption with high consistency and low randomness, lowering the baud to something reliable will at least eliminate several possibilities.

On an oscilloscope, a strong, well-formed signal at the receiver will arrive as a very rectangular pulse train.

Conversely, a shark fin waveform (pulses with curved high/low transitions) anywhere in the signal chain is an indication that your physical layer cannot handle the baud rate without some kind of redesign.

“Do I have a Ground Loop?”

If your UART signal chain is connecting 2 or more devices that have their own connection to earth ground, you may have a noise-capturing arrangement called a ground loop.  This can include USB hubs, and USB to UART converters that are part of the chain.

While ground loop details are outside the scope of this article, an easy mitigation is to pass your signal through galvanic isolation such as a USB isolator. 

“How do I know this isn’t Aging Effect?”

If your once-working equipment has errors or intermittency, consider:

• Metal fatigue will occur on wires and connectors that flex back and forth and excess number of times.  If this describes your equipment, consider using strain reliefs to mechanically restrain any moving interconnects.  Or invest in high flex-life cabling: keeping in mind that flexibility and flex life are two different properties of cable.
• Fretting Corrosion may form on non-gold-plated connectors.  For example: tin-plated connectors can gradually build an invisible layer of tin oxide (a semiconductor) can raise the connector’s resistance by hundreds of ohms and ruin your signal integrity.  You can often tell this is the case if unplugging and re-plugging the cable fixes the problem temporarily, only for it to return later.
• Solder Joint Cracking on circuit board components is especially challenging to isolate.  Cracked solder (caused by voiding, metal fatigue or other mechanisms) can contribute all the same problems as metal fatigue and corrosion with none of the easy-to-spot evidence.  Your best defense may be discontinuity testing in your application.

Conclusions

Hopefully, this helps you with any UART-related problem you might have.  For problems directly related to your microcontroller or microprocessor, it may be best to open a support ticket with the relevant manufacturer, since every UART-capable device can vary quite a bit. 

Important Notice: This article and its contents (the “Information”) belong to Unboxing-tomorrow.com and Voxidyne Media LLC. No license is granted for the use of it other than for information purposes. No license of any intellectual property rights is granted.  The Information is subject to change without notice. The Information supplied is believed to be accurate, but Voxidyne Media LLC assumes no responsibility for its accuracy or completeness, any error in or omission from it or for any use made of it.  Liability for loss or damage resulting from any reliance on the Information or use of it (including liability resulting from negligence or where Voxidyne Media LLC was aware of the possibility of such loss or damage arising) is excluded.