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.
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 ?
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.
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).
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.