I have a customized hardware which connects an Xavier and Orin SOM through an UART bus, and it is defined as ttyTHS0 in Kernel.
According to this architecture, I tried to write a program to transmit and receive raw data in C language by UART communication.
The algorithm is…
- Include termios.h to setup the serial port to 115200 8N1, blocking and raw data.
- Keep a process to try to open, read, write the serial port (ttyTHS0).
I synchronize these settings on both Xavier and Orin at the same time.
But the condition is that sometimes the communication not work, and sometimes it works at the beginning but the communication disappears a few minutes later.
Can you give me some ideas?
Do you mean that you use one carrier board for 2 modules (Xavier and Orin) at the same time?
Or the same carrier board for these 2 modules respectively?
Could you share the block diagram of your connection?
What’s your Jetpack version in use?
Please also share the full serial console log at each side for further check.
Please refer to the below diagram for the hardware architecture.
The version numbers are L4T 35.3.1 for Xavier and L4T 35.2.1 for Orin.
Also, just like I mentioned, I use it for the raw data transmission instead of console debugging so I can not provide serial console log from ttyTHS0.
I would suggest verifying with the latest JP5.1.2(R35.4.1).
Does that 2 customized boards the same?
Are you using AGX Xavier+AGX Orin? Or Xavier NX+Orin NX?
There should be the log output from
ttyTCU0 rather than
Or please help to provide the dmesg.
Regarding the L4T version, I think that should be not problem because the UART should be the basic function of Kernel unless Nvidia uses it for something special? Does it?
Regarding the customized boards, no, they are different but for the serial communication via UART, it should be no matter, right?
What I can say is that the hardware designs of both boards for UART are the same.
AGX Xavier + AGX Orin
I agree what you mentioned,
There should be the log output from ttyTCU0 rather than ttyTHS0., however, I can see the boot up log from ttyTHS0, and that’s why I post the question here.
I am afraid maybe some process or thread use ttyTHS0 for something on Xavier, and that causes this issue.
If the answer is yes, can you help to tell me to disable relative processes, services or threads for my raw data transmitting?
BTW, below are the dmesg log.
dmesg_orin_uart_debug_20230907.log (73.3 KB)
dmesg_xavier_uart_debug_20230907.log (135.7 KB)
And here is my debugging, which records Xavier boot up messages, from Orin.
COMM_UART_LOG (1.6 KB)
Sometimes, there would be several fixes in different L4T release, using the latest release to verify could help us clarify the issue with the same status.
Please make sure there’s no debug messages output from
/dev/ttyTHS0 before you use this port for custom UART communication.
I wish this port is pure for general purpose instead print system boot up messages by Nvidia, but unfortunately it isn’t.
My question is how to disable Nvidia’s feature to release /dev/ttyTHS0.
Please share your dtb in use for further check.
Is this one you need?
tegra194-soc-uart.dtsi (7.1 KB)
No, the dtb file under /boot/dtb/kernel_XXXXXX.dtb on your board.
Could you try to remove
console=tty0 in kernel command line?
How to change the kernel command line on Xavier and Orin?
I tried to remove the command line in p2972-0000.conf.common but not work.
Do you flash the whole board after this modification?
Or you could try to remove that from /boot/extlinux/extlinux.conf.
The situation is the same after remove
console=tty0 in kernel command line.
receive 43 bytes, data is Ubuntu 20.04.5 LTS tegra-ubuntu ttyTHS0
receive 20 bytes, data is tegra-ubuntu login:
From you log, it seems kernel console is not working over UART-A.
Please help to check the following:
- Enable HW Flow control.
- Check UART connections. (please share the block diagram of your connection)
- What baudrate are you using?
What do you see from:
(this is the final set of arguments the kernel actually saw)
I enable UART flow control through termios flag but the situation seems to be the same.