Serial UART is one of the most commonly used interfaces in embedded applications and communication fields. Although the interface protocol is simple, there will be various small problems in communication between different devices in actual applications. The following is a list of common problems in use. The problems are summarized and sorted out, which can be used as a reference for debugging.
1. Frequently Asked Questions about Serial Communication
-
Serial communication garbled code
Garbled serial communication usually means that the data received by the receiver does not meet expectations. Factors that need to be considered when this occurs usually include the following aspects:
Whether the serial port parameters set by both parties match
Need to check the settings: serial port baud rate, serial port data format and other parameters.
Serial communication voltage does not match
Different serial port devices have different high and low level thresholds that can be decoded normally. For example, if it is the same 3.3V serial port communication, the low level threshold of device A is 1.5V, and the low level threshold of device B is 1V. When the actual low level of the serial port voltage is only 1.5V, device B cannot receive data normally. Another example: Device A has a 5V serial port and device B has a 3.3V serial port. There is also a voltage mismatch problem.
The actual working baud rate error of serial port communication is large
That is to say: the actual baud rate of serial port operation deviates greatly from the theoretical value. Because the clocks used by some MCUs and serial port devices take into account other resources and application needs, the actual serial port rate and settings will deviate. For example: when the nominal speed is 9600bps, it actually works at 10000bps (the error exceeds 4%). At this time, it may have exceeded the design standards of the receiver.
Poor serial communication signal quality
If the signal rises and falls during communication and jitters seriously, the signal overshoots or changes slowly, check whether the common ground on the hardware is good and whether there are other devices connected in series/parallel on the line.
Data format display problem
Usually hexadecimal or ASCII code format is used, and it needs to be distinguished when using it.
-
The serial port cannot send
The failure of the serial port to send usually means that the RXD channel of the peer device connected to the TXD of this serial port cannot receive any data. The summary is as follows:
Use instruments to make actual measurements of the TXD channel
Observe the hardware waveform to determine whether the signal is output and whether it is normal. (Serial port voltage, serial port signal rise and fall time)
TXD and RXD channel loopback test of short-circuited equipment
See if the self-sending and receiving can be successful. Troubleshoot whether the problem is caused by an abnormality in the own device or at the opposite end.
Determine whether the application software turns on serial port hardware flow control
For example, when RTS/CTS hardware flow control is enabled but the pin is not actually connected or is connected but does not take effect, according to the protocol, if the CTS input is invalid, the sender will suspend sending data.
MCU software coding problem or computer software working abnormally
-
The serial port cannot receive
When the serial port cannot receive any data, the reasons are usually as follows:
The peer serial port actually failed to send data successfully.
The effective voltage sent by the serial port does not meet the chip receiving and decoding requirements.
MCU software coding problem or computer software working abnormally
2. Commonly used troubleshooting tips
For the above common serial port debugging problems, there are several methods and techniques for reference:
Use hardware instruments
Be good at using hardware acquisition or analysis tools such as oscilloscopes to find problems. This method can determine the serial port voltage, serial port data format, serial port communication baud rate and other parameters of the signal on the line.
Serial port loopback detection
When there is no hardware instrument at hand, it is also a good choice to short-circuit the TXD and RXD of the device itself for self-transmitting and receiving testing. This method can simply confirm whether the hardware path and the entire logic are connected. But the disadvantage is that the positioning problem is not accurate enough.
Replace serial port debugging software
There are many types of serial port software on the computer side. It is not ruled out that some devices or driver software cannot successfully adapt to all serial port debugging software. At this time, you can try to use several different software for comparison testing.
3. Summary
Solution ideas when serial port communication encounters problems:
1. Confirm the signal type, which is TTL, RS485, RS232. Signals of different data types cannot communicate normally.
2. Confirm the software settings of the serial port, baud rate, serial port number and other signal formats.
3. Confirm that the driver has been installed correctly.
4. Confirm whether the hardware wiring is correct and connect the corresponding signal interface to the corresponding interface. For TTL and 485, if you are not sure about the signal definition, you can try to exchange the two wires with each other.
5. Confirm that the device is powered normally.
6. Use an oscilloscope or other debugging tools to check whether the communication waveform is correct. For 5V systems and 3.3V systems, pull-up resistors and diodes need to be added to the corresponding signal lines.
7. After confirming that there is no problem with the hardware, look for software problems.
How to roughly distinguish software problems from hardware problems:
Hardware problems recur almost every time, while software problems may come and go.