Serial UART debug prompts undecoded characters


#1

Hello,

This is my first post, my name is Simon and I will be working on Dragonboard410c for a while.

I installed the Debian distro on my Dragonboard and now I would need to debug the system through UART connection so I am following the instructions for serial UART debug connection with 3 wire USB to UART cable.

Once I connect the cable to the low speed Db410c connector (GND to pin 1, cableRX to pin 11 and cableTX to pin 13), through putty (configured for 115200 baudrate) I can see a continuous flow of undecoded (like garbage) characters.

Is there some additional configuration, modification that need to be applied to the linux image in order to see the correct login prompt ?

Thank you in advance,
Regards,
Simon


#2

Hi @simozz

UART is, at best, tricky to get the electrical connections correct. based on your description I am going to hazard a guess at your problem. I ‘think’ you have TxD and RxD crossed. Please try swapping them.

Now I’ll get into the history of TxD and RxD. In the early days of computing there were two types of equipment, Data Terminal Equipment (DTE - typically a terminal with a screen and a keyboard) and Data Communications Equipment (DCE - typically a modem connected to a phone line). The ‘naming’ of the two data signals Transmit Data (TxD) and Receive Data (RxD) are from the point of view of the modem, i.e. TxD is the information you want the modem to send, and RxD is the data the modem received from the far end. If you think about the whole system end-to-end (local terminal, near-end modem, phone line, far-end modem, remote host computer) a character typed on the local terminal keyboard leaves the terminal in the TxD pin, and goes into the near-end modem on the TxD pin (TxD is an output on DTE and an input on DCE). At the far end the character comes out of the RxD pin on the far-end modem and into the RxD pin on the host computer. So far this should make sense.

Now we get to the tricky parts. What if you want to connect the terminal directly to the computer? The keystroke comes out of the TxD pin on the terminal, and goes into the RxD pin of the host computer. Now you need a cross-over cable (also known as a null modem) to do a direct connection, but when you had two modem in the circuit, you needed two straight through cables.

It gets worse, many of the terminal manufacturers saw this confusion with cables, so to ‘make life simpler’, they designed their terminals so that the keystroke comes out of the RxD pin (like DCE instead of DTE) and then you can use a straight through cable to the host computer. Of course some of the computer manufacturers recognized the same problem and also swapped the TxD and RxD pins.

At the end of the day nobody ever really knows if the RxD pin on a device is an input or an output. Hence your only option is to try it one way, if it doesn’t work, then try it the other way. This is why I am recommending your try swapping the TxD and RxD pins to your cable.

One other reason why I believe that you have the pins swapped. If you have the two inputs tied to each other the signal is very high impedance, and any tiny signal will get through. You also have the two outputs tied to each other hence when either end transmits, the signal gets coupled to the high impedance inputs by the parasitic capacitance in the cable. Because the signal quality is low, you see garbled characters.

One other thing to check. The signal levels on the 96Boards low-speed connector are 1.8V signals. Please ensure that the UART cable you are using is designed for 1.8V signals and not 3.3V or 5V signals.

Let me know how swapping the signals works out for you.

Full Disclosure: I am an employee of Qualcomm Canada, any opinions I may have expressed in this post or any post may not reflect the opinions of my employer.


#3

Hello @ljking

My USB to R232 TTL adapter is 3V3 and not 1V8.
However I already purchased a 1V8 adapter.

Regards,
Simon