UART ttyS2 on RockPro64 for custom communication

[meier]

I am looking to attach a custom PCB to the RockPro64 board, a simple extension board with custom firmware that communicates over UART.

Up until now I have no luck getting even a basic two-way communication over UART2 working.

Steps taken:
* The RockPro64 runs on Armbian Ubuntu 18.04
* The RP64 is connected to a Ubuntu Laptop with the Pine64 UART-USB adapter. Due to voltage issues, we regulated the TXD and RTX pins to exactly 3.3V (see schematic attached). Bidirectional communication works fine for the serial login prompt.
* Serial console on ttyS2 is now disabled. We get some Uboot messages on boot, after that the port is silent
* picocom is running both on the RP64 (over SSH) and on the Ubuntu laptop

Expected result:
* Both machines should be able to communicate usint picocom, if started e.g. like `picocom -b 1500000 /dev/ttyS2`

Actual result:
* The RP64 is able to output some characters unreliably to the laptop
* The laptop cannot send any characaters to the RP64, instead mirroring some <?> characters despite local echo off

Some status logs:

Code:

$ dmesg | grep tty
[    0.000000] Kernel command line: earlycon=uart8250,mmio32,0xff1a0000 swiotlb=1 no_console_suspend=1 usbcore.autosuspend=-1 root=UUID=4e0c7993-7cbb-46f7-acd0-2e3acdfa20ef rootwait rootfstype=ext4 console=tty1 panic=10 consoleblank=0 loglevel=1 ubootpart=350ce75a-01 usb-storage.quirks=0x2537:0x1066:u,0x2537:0x1068:u   cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1
[    0.001397] console [tty1] enabled
[    0.328959] Registered FIQ tty driver
[    1.945780] ff180000.serial: ttyS0 at MMIO 0xff180000 (irq = 36, base_baud = 1500000) is a 16550A
[    1.946282] ff1a0000.serial: ttyS2 at MMIO 0xff1a0000 (irq = 37, base_baud = 1500000) is a 16550A
[    4.946846] systemd[1]: Created slice system-serial\x2dgetty.slice.
[   15.681434] ttyS2 - failed to request DMA, use interrupt mode

$ sudo setserial -g /dev/ttyS[0123]
/dev/ttyS0, UART: 16550A, Port: 0x0000, IRQ: 36
/dev/ttyS2, UART: 16550A, Port: 0x0000, IRQ: 37

Does anyone have an idea what I am doing wrong?

Best,
Meier

[t4_4t]

1) > We get some Uboot messages on boot, after that the port is silent.

There may be a bug.
You should try to another image from the location shown in the following url.
If it works as expected, the problem you pointed out is a kernel bug.

For example,
https://dl.armbian.com/rockpro64/archive/
Armbian_5.67_Rockpro64_Ubuntu_bionic_default_4.4.166.7z
or
https://github.com/ayufan-rock64/linux-b...oad/0.8.3/
bionic-minimal-rockpro64-0.8.3-1141-arm64.img.xz
or etc.

2) > Due to voltage issues, we regulated the TXD and RTX pins to exactly 3.3V (see schematic attached).

Is the product that you pointed out the problem listed below ?
https://store.pine64.org/?product=padi-serial-console

If it is not a defective product and the output signal of a good product is 3.8v, it is a terrible product.

In the presented schematic, you can use resistor splitting to solve the problem,
but if you choose a resistor value that is higher than necessary, the problem arises.
The presence or absence of harmful effects depends on the parasitic capacitance due to the wiring length.
I think it is better to choose a value (220Ω / 1KΩ) that is about 1/100 of the resistance value of the circuit diagram that you presented.

[meier]

1) > We get some Uboot messages on boot, after that the port is silent.

There may be a bug.
You should try to another image from the location shown in the following url.
If it works as expected, the problem you pointed out is a kernel bug.

Thanks for the quick answer. Seems like it works as expected after all, I just forgot to stop "agetty" from launching and creating a login-prompt on ttyS2, eating up all the packets... We did "systemctl stop serial-getty@ttyS2" to disable it temporarily and then picocom worked as expected.

Do you think there's more to it than that?

2) > Due to voltage issues, we regulated the TXD and RTX pins to exactly 3.3V (see schematic attached).

Is the product that you pointed out the problem listed below ?

Yes, that is the product and judging by the problems people describe in forums, with the board crashing on boot when connected (exactly what we experienced), this does not seem to be an exception. See picture attached.

Thanks again, will take a closer look at your electronics details as well with some colleagues.