Getting garbage from serial port

My board boots up (off of NVMe) just fine and functions normally but I am not able to get the serial port to work. My USB/Serial adapter is set to 3.3v and works fine when connecting to RPIs. I get nothing but random garbage from the port with the exception of a proper word ever once in a while. If I keep banging on the enter key I will see “password” occasionally but rarely. So, I know I have the right pins wired up.

I have the port set for 115,200 and 8n1 with no flow control.

I’ve tried reboots and cold power ups but never receive anything other than garbage.

Any ideas as to what’s going on?

Are your grounds possibly not connected together?

It is not enough to connect each TX to the other RX. You need to connect GND with GND, too.

That’s what I can think of, currently.

Also, please state which chip your usb-ttl dongle is based on.

1 Like

Yes, I have ground connected.

The chip is supposed to be either an FTDI FT232RL or FT232RNL.

This is the unit:

1 Like

It should indeed be reliable with that chip. I don’t know what could be going on.

I would try:

  • Use different, shorter wires.
  • Linux, if you normally use Windows.
  • Different terminal tools, such as tio, minicom or pyserial’s miniterm (python -mserial).
  • A different dongle, if you have one.
  • Using your raspberry pi’s UART instead of a usb-ttl dongle.
1 Like

@llowrey, do you see proper OpenSBI messages or just garbage from the very beginning of the boot?


Which OS is it booting ?
The custom Debian image-69 transferred to NVMe (full or minimal) or the VisionFive2 Software v2.8.0 sdcard.img transferred to NVMe or something else ?

And did the serial port function correctly with that ttl-usb when you booted from an SD card with the same OS, or did it also produce garbage ?

1 Like

I hooked up my pi3 and got better results. But, I still get garbage. I found that if I dd less than 400 bytes from a text file to stdout the interface works fine, no garbage and the interface responds to keystrokes normally. Beyond that number, or thereabouts, the end of the stream past the ~300 byte mark is garbage and the interface no longer responds normally to keystrokes. After a short while and hitting enter several times the interface returns to working ‘normally’, at least until I cause a transfer > 300 bytes.

Seems like a timing thing. If the timing is off a little bit the it might take a while for the accumulated error to cause the bits to be detected incorrectly. Perhaps the position within the bit where the line is sampled is different between the pi and the dongle and the dongle is impacted by the timing before the pi is. This was a good excuse to order a cheap logic analyzer. I should have a clearer picture in a couple of days.

The OS image is the debian-69. I tried booting purely from the SD card and still got pure garbage from the dongle all the way through the boot process. Even with the pi connected I still get almost 100% garbage during the boot except there are periods when there is proper text getting through.

1 Like

Since you have the same problem with NVMe and SD, and the corruption changes when you change usb-ttl to RPi-ttl, that suggests a hardware issue rather than a software issue to me.

Did you use different shorter wires as suggested by @rvalles. Because to me it sounds the serial data is being corrupted on the wire, that could happen if there was high capacitance (big long wires) or high inductance (coiled up wire) or high resistance (extremely thin or nicrome wire) on the serial wires or if they were passing close to source of external noise (like the alternating magnetic fields from a fan).

Serial is asynchronous so any data corruption will cause a desynchronization or a misalignment. And with enough data corruption it will eventually re-synchronise (for a while).


TL;DR - the VF2 is cleared of all charges.

Logic analyzer FTW! Data showed that the VF2 was outputting perfectly timed serial data. So… started looking elsewhere for problems.

Turns out the USB serial adapter doesn’t like my AMD Epyc server but works just fine on my Ryzen 5950. Both run the same linux distro and are at the same kernel patch level. Must be something wonky about the Epyc USB ports.

I noticed my RPi3 throwing the dreaded undervoltage warning when it was hooked to the VF2. Must be something about that connection that puts an additional strain on the power supply because I’ve never seen those undervoltage warnings with that RPi board and power supply combo.


Logic analyzer was extremely helpful to me with development of dbus_ti_link_uart_verilog and early stages of pyamigadebug/amigaXfer.

No reason not to own one today if even slightly interested; I love my DSLogic but even something really cheap like the nanoDLA is extremely useful vs not having any.

Or, more likely, the Linux drivers for either the usb controller or the usb-ttl adapter.

FT232R and FT232H/2323H have been reliable for me, so have CP2102s (cheap!). There’s now a CP2104 (still cheap!) that’s a little fancier, supports 2mbps instead of 1mbps and has some GPIOs.

I have only ever had timing issues with an CH340G adapter, which seem less tolerant of timing being slightly off. Maybe they don’t super-sample enough, or maybe the clock in my adapter specifically is slightly off.