We’re trying to use AGX Orin / UART2 as a RS-485 interface. With NOTHING connected to the port, the behavior of the interface is it reads whatever is written to it as if it’s in some loop-back mode. Googling this around, I landed on a story where another user had a similar issue with UART2. The issue was closed without resolution, so I am curious if there is such a mode on the AGX Orin UART.
Could it be bound to some other function, like a debug port?
Is this based on NV devkit or custom board?
Custom carrier board. ttyS0 is UART2 on the AGX Orin/device tree.
I answered your question follow up question. Why aren’t you addressing my original issue? I already referenced a different case where some other user had the exact same problem, and the case was closed due to inactivity (maybe that user lost patience too?).
Please address the issue I raised in my original post.
Thanks,
Bob
Any update?
Any update?
Any update?
Hi mt_developer,
What’s your Jetpack version in use?
What’s your current status after referring to the topic you linked?
How did you configure these 4 pins(PY05, PY06, PY07, PZ00) in pinmux spreadsheet?
Please also share the full dmesg and the device tree for further check.
jetson_linux_r36.3.0_aarch64.tbz2
There is nothing useful in that article since it was closed without resolution due to inactivity. Current status is after disconnecting the port (ttyS0) from agetty terminal program - which apparently the SDK Manager build does by default - the port still does not operate, but no longer exhibits the “loop back” behavior.
There were no entries I could find in the pinmux spreadsheet or the resultant *.dtsi files.
dmesg.log (57.7 KB)
flat.dts.txt (322.6 KB)
So, the loopback behavior you observed may be caused from getty service.
Please run the following command to disable it.
$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
Have you confirmed that you are using AGX Orin?
If so, how do you configure the following pins here?
[ 4.242850] 3140000.serial: ttyS0 at MMIO 0x3140000 (irq = 113, base_baud = 4250000) is a Tegra
Your dmsg and device tree look good to me.
Please check if you’ve also configured the pinmux for UART-E.
The nvgetty.service was already stopped according to command: sudo systemctl status nvgetty.service. I disabled it anyway as per your instructions.
We are in fact using an AGX Orin SOM. I’m sure of it. 100% sure.
Here is what I show in the Excel spreadsheet for the UART2 section:
All I can find in the spreadsheet for UART-E is also in the same rows as UART2 (see below). Column G (normally hidden).
Any update?
Please also configure A57 UART2_CTS as UE3_CTS in pinmux spreadsheet.
UE3_* is the expected configuration for Uart-E.
You can short the UART2_TX/UART2_RX and run the following command to verify loopback test.
$ sudo su
# stty -F /dev/ttyS0 115200 raw -echo
# cat /dev/ttyS0 &
# echo "test" > /dev/ttyS0
Nothing happened. The cat /dev/ttyS0 command did not exit or receive any characters. I also tried the command: echo “test” > /dev/ttyS0, because I’m guessing the /dev/ttyTHS0 in your suggested write command was a typo and still nothing happened.
Sorry that it was a typo. echo "test" > /dev/ttyS0 should be the expected command.
Could you use a scope to check the waveform when you verify with above commands?
I’ve verified it working on my local AGX Orin devkit with R36.3.0 as following:
nvidia@Jetson:~$ sudo su
root@Jetson:/home/nvidia# stty -F /dev/ttyS0 115200 raw -echo
root@Jetson:/home/nvidia# cat /dev/ttyS0 &
[1] 3051
root@Jetson:/home/nvidia# echo "test" > /dev/ttyS0
test
The configurations in pinmux spreadsheet:
