Debug console showing garbled output

#1

I am new to SBCs and I’ve got my Rock 5B up and running booting Radxa’s Debian release from the SD card. The SBC is working and I’ve used it both by connecting a USB keyboard + mouse and using the Debian GUI and by logging into it using SSH over my LAN, so I know its booting and operating properly.

Now that I’ve got it working I want to start trying to experiment with it so I plugged in a serial debug cable that I bought from China for a few bucks (so I’ll be able to access the u-boot console during booting The device I got is identified as a PL2023TA device I connected the black cable to pin 6, white to pin 8, and green to pin 10 of the gpio. When I plugged this device into my Windows 11 PC it turns out that Windows 11 doesn’t support it by default but I found an older driver that is supposed to work if I install it then I manually select the older driver version in Windows. I did that and now instead of saying the device is not supported it shows that the device is installed on COM4.

I installed Putty on Windows 11 to talk to the device. I followed the instructions on the wiki that indicated that the baud rate should be set to 1500000 baud, 8-N-1 settings. When I set those settings, start the Putty terminal, then plug in my Rock5b I get some garbled text in the window. After awhile I get some more garbled text. It appears to me that the Rock5b serial debug port is talking, but the baud rate setting must not be correct so the interpretation of the output is wrong. I tried setting other baud rates like 115200, 38400, 9600 and starting the Rock5b and I coudln’t find one that would result in output that was not scrambled. I logged in as root on the rock5b over SSH via ethernet and I when I send output to the /dev/ttyFIQ0 each time I see more garbled output on my Windows PC, reaffirming to me that it is definitely trying to talk to my device.

Is the PL2023TA device one that could work to talk to the Rock5b?

Am I doing something wrong in this process?

Do I have the wrong baud rate?

Any help that might enable me to get the problem resolved so that I can use the debug console in u-boot would be appreciated.

#2

While usually it’s wrong baud rate there are some other possible issues like serial port IO levels (5V/3.3V/2.5V/1.8V). I also tested PL2303TA cable with no luck (it does work on lower baud rates on everything that is not rockchip). I guess that those consoles are just not suitable for high baudrates, even if according to docs it should support up to 6M.
Just buy any cheap CH340G console or CH343G which is even better and more accurate. I never had any problems with those on RK, such console cost $2

#3

Ok, thanks for sharing your experience with me. I was trying to test my PL2303TA using loopback earlier as a troubleshooting step and it didn’t seem to echo what I was sending it when i connecting its own TX and RX together so I decided that it might be defective. I ordered two other debug cables, a cheap CH340G one and a more expensive one with a genuine FTDI FT232RL chip that said specifically that it works with Windows 11. Hopefully one of these will do the trick for me.

#4

FTDI requires additional drivers from their site.
As far as I remember I could get to work one of my two based on this chip.

For CH340G I never had any problem and that one work out of box without any additional drivers.

Good luck :slight_smile:

#5

I received my new debug cables and both types resolved my issue with the debug console output being garbled.

If anyone wonders these are the devices I purchased and both work fine with the Rock5b:

The CH340G package came with two of the serial debug device which have pin headers on them to connect Dupont jumper cables but only included one very short cable (only around 1 ft) so it might need some longer cables to use easily and would need a second cable if you wanted to actually use both of them separately. It did have the ability to actually power some types of devices with 5V or 3.3V if you wanted to, but those power lines aren’t used for debugging the rock5b.

This one has a much higher quality cable that is 6 ft long with thick insulation that is permanently attached to the device, not just some pins for jumper wires to attach. There’s no 3.3V, 5V, or VCC line like the other one, but those aren’t used for debugging the rock5b. Its not as versatile as the other but its way more convenient to use due to the much longer cable. The cable is 6 ft long and it has just the three wires you need for serial debug (TX, RX, and GND). It has a genuine FTDI FT232RL chip with a programmable EEPROM in it which was recognized by FTDI’s FT_PROG utility. Apparently there much cheaper chinese fakes that don’t have this, but this appears to be the real thing.

Overall both devices seem to work fine for serial debug of the rock5b on Windows 11. Both of them had drivers built into the latest version of Windows 11, so I didn’t need to locate a driver for either one. The CH340G was quite a bit cheaper at $4.99 for two vs $15.98 for just one FT232RL, but the FT232RL was more convenient to use mainly because it has a lengthy cable and because there’s less danger of accidentally shorting the chip to something on accident because its contained inside the USB connector and its permanently affixed cable contacts are not exposed the way the CH340G’s chip and IO pins are. Out of the two I personally prefer the FT232RL device for debugging on the rock5b, but the CH340G is absolutely usable for people looking to save some money or people that might use the debug cable with other types of devices like small microcontrollers that are low power enough that they could be powered directly via the debug cable.

#6

Good to hear :slight_smile:

For now the best option is CH343G like this one: https://www.waveshare.com/wiki/CH343_USB_UART_Board

image
image.jpg845×698 148 KB

and it’s still reasonably priced.