Strange characters in your Allwinner H3 terminal running OpenWRT usually indicate a baud rate mismatch or encoding error between your host computer and the device. This article outlines how to verify serial port settings, adjust terminal emulator configurations, and resolve common communication glitches to restore clean command-line output.
Understanding the Root Cause
When connecting to an embedded Linux system like one powered by the Allwinner H3 SoC via a USB-to-serial adapter, the most frequent culprit for garbled text is a mismatch in communication parameters. Serial communication relies on precise timing; if the baud rate (bits per second) configured on your host terminal does not match the rate set by the bootloader or kernel on the device, the data bits are interpreted incorrectly. This results in random symbols, boxes, or unreadable gibberish appearing on your screen.
Another common cause involves character encoding and line ending styles. While modern systems predominantly use UTF-8 with Unix-style line endings (LF), some older bootloaders or specific console configurations might expect different formats. If your terminal emulator is forced into a legacy encoding like ISO-8859-1 while the system sends UTF-8, special characters will appear corrupted. Additionally, flow control settings can interfere if the hardware handshake lines are connected but not properly negotiated, causing data loss or corruption during high-throughput operations.
Verifying Serial Port Configuration
The first step in troubleshooting is to ensure that the physical connection and the logical configuration align. You must identify the correct serial port identifier on your host machine. On Linux systems, this is typically
/dev/ttyUSB0 or
/dev/ttyACM0. On Windows, it appears under a COM port number in Device Manager. On macOS, it is often
/dev/cu.usbserial-....
Once identified, you need to confirm the baud rate. The Allwinner H3 typically boots at 115200 baud, though some manufacturers may default to 115200 or 57600. Check your board’s documentation or the U-Boot environment variables if possible. Use a terminal program like
minicom,
screen, or
picocom to test the connection. For example, using
screen:
screen /dev/ttyUSB0 115200
If the output is still garbled, try changing the baud rate to 57600 or 9600. Sometimes, lower baud rates are more stable on noisy connections or cheaper USB-to-serial chips. Ensure that the data bits are set to 8, parity to None, and stop bits to 1 (8N1). These are the standard defaults for almost all Linux-based embedded systems.
Adjusting Terminal Emulator Settings
Even with correct baud rates, your terminal emulator software can introduce display issues. Applications like PuTTY, Tera Term, or GNOME Terminal have specific settings for handling incoming data. In PuTTY, navigate to the Connection section and verify the Speed field matches your device’s baud rate. Then, go to the Window translation tab and ensure the remote character set is set to UTF-8. If you see box-drawing characters instead of proper lines, switch the translation to ISO-8859-1 temporarily to diagnose encoding conflicts.
For Linux users utilizing
minicom, press
Ctl-A Z to access the help menu, then select Setup. Verify that the Bps/Par/Bits setting is correct. Also, check if local echo is enabled appropriately. If you are seeing double characters, it might be because echo is being handled both by the terminal and the remote shell. Disable local echo in your terminal settings if the remote system is already echoing input.
Checking Hardware and Cables
Physical layer issues can mimic software configuration errors. Poor quality USB-to-serial adapters, particularly those using cheap CH340 or PL2303 clones, can suffer from driver instability or signal degradation. Try using a different USB cable, preferably one that supports data transfer rather than charging only. Connect directly to a USB 2.0 port if possible, as USB 3.0 ports sometimes have interference issues with certain serial converters.
If you are using a long cable run, signal attenuation can cause bit errors. Keep the connection short and secure. Check for loose ground connections; a shared ground between the host and the Allwinner H3 board is critical for reliable serial communication. Without a common ground, voltage levels fluctuate, leading to intermittent character corruption.
Resolving Bootloader Console Issues
Sometimes the issue arises specifically during the U-Boot phase before the Linux kernel takes over. U-Boot might be configured to output to a different serial port or at a different speed than the kernel. If you can access the U-Boot prompt, check the
baudrate variable using
printenv baudrate. If it differs from your terminal’s setting, update it with
setenv baudrate 115200 and save with
saveenv.
If the kernel also outputs to a different baud rate, you may need to modify the device tree source (DTS) for your Allwinner H3 board. Look for the serial node and ensure the
status is "okay" and the clock speeds align. Recompile the device tree and flash it to your board. This ensures consistent output throughout the boot process.
Related Troubleshooting Guides
If you encounter network-related issues after fixing the serial console, such as losing internet connectivity, refer to our guide on
Enabling Internet Access for an OpenWrt Hyper-V Virtual Machine for broader network context. For session management tips that might help if you disconnect frequently, see
Tmux Sessions Disappearing.
Frequently Asked Questions
Why do I see '’' instead of apostrophes?
This indicates an encoding mismatch where UTF-8 bytes are being interpreted as ISO-8859-1 or CP1252. Change your terminal emulator’s character set to UTF-8 to resolve the display of special characters correctly.
Can a bad USB cable cause garbled text?
Yes, poor shielding or broken wires can introduce noise into the serial signal, causing bit errors that manifest as random characters. Test with a known-good, short USB data cable to rule out physical layer issues.
What should I do if minicom shows no output?
Verify that the correct serial port device file is selected and that the baud rate matches the device. Ensure that the serial port is not locked by another process and that the hardware connections (TX, RX, GND) are secure.
Does flow control affect terminal readability?
Hardware flow control (RTS/CTS) prevents data loss but can cause issues if pins are unconnected. If you experience stalled terminals, disable hardware flow control in your terminal settings and rely on software flow control (XON/XOFF) or none.
How do I check the current baud rate in OpenWRT?
You can check the console baud rate by examining the kernel command line arguments passed to the bootloader. Use
dmesg | grep tty to see which serial devices were initialized and at what speed they are operating.