Cover Image
A mushroom photographed on a rainy day in Greece by a National Geographic photographer.
Main Text
When debugging a board, what is your troubleshooting approach when the debug serial port is not functioning?
Seemingly simple serial communication actually involves an entire chain: from the serial software on the PC, USB to serial modules, to the serial terminals on the board, TX/RX pin order, and then to the hardware design and software configuration on the ARM side… With so many influencing factors, troubleshooting can easily become chaotic.Often, the more fundamental the issue, the clearer the troubleshooting logic needs to be — after all, “fundamental” does not equal “simple”.Recently, while debugging the Allwinner T527, I encountered a typical serial port fault. I organized the troubleshooting process into notes to share, hoping to provide some reference for engineers reading this article.
[Problem Description]
The debug serial port can print logs normally (indicating that the system has entered the file system), but there is no response to keyboard input, making interaction with the device impossible.
[Problem Analysis]
The normal printing of serial logs indicates that the device’s TX (transmit) link is functioning correctly.
Possible reasons for keyboard input failure, prioritized for troubleshooting:
-
Eliminate keyboard hardware or serial software faults (e.g., incorrect input mode, mismatched baud rate);
-
Focus on checking the device’s RX (receive) link — this is the most likely culprit.
[Problem Resolution]
After step-by-step troubleshooting, the issue was ultimately identified as a cold solder joint on the RX pin header, causing a break in the receive link. After re-soldering, the input function was restored to normal.
Summary
Many times, seemingly simple problems can leave one confused if the fundamental principles are not understood when issues arise.Taking the serial communication between the Allwinner T527 and the PC as an example:Device sends data (log printing): The ARM board sends data through the TX pin of the debug serial port → The RX pin of the PC serial port receives → The serial software parses and displays the log. (This step is normal, indicating that the TX→RX transmission link is smooth)PC sends data (keyboard input): The commands from keyboard input are sent through the TX pin of the PC serial port → The RX pin of the ARM board’s debug serial port receives → The device processes and echoes back to the software interface. (If the RX link is interrupted, the device cannot receive commands and thus cannot respond to input)Understanding this bidirectional communication logic allows for precise localization of issues when encountering serial port problems:
- Can receive but cannot send? Check the TX link (device sending, PC receiving);
- Can send but cannot receive? Check the RX link (PC sending, device receiving).
Mastering the underlying principles allows for resolving even the most complex serial port faults with ease.(End)
Welcome to follow “Embedded Sharing“, updated weekly! ☞