The jetson xavier serial port cannot receive very small negative data

Hi everyone, I use a jetson Xavier NX

I need to use two serial ports. I use cutecom to test the data reception and sending of the serial port. The serial port /dev/ttyTHS0 can be used normally.

But there is a problem with /dev/ttyTCU0 and it cannot receive small negative numbers

I send data to /dev/ttyTCU0 through the USB to serial port settings. What is sent is -2, which corresponds to hexadecimal FF FE. /dev/ttyTCU0 cannot receive it.

Hi weiquan.x,

Are you using the devkit or custom board for Xavier NX?
What’s your Jetpack version in use?

/dev/ttyTCU0 is used for combined UART which allows you to access the serial console and get the logs from the device.
How would you like to use this UART interface?

hi Kevin. I am using the devkit and the jetpack version is 5.1-b147

I want to use TCU0 as the serial port to communicate with ESP32.

During the communication process between TCU0 and ESP32, I found that TCU0 cannot receive data like FF EC.

Therefore, I removed ESP32 and used a USB to TTL device to test TCU0. I found that the results were the same, but still unable to receive data like FF EC.

Therefore, I determined that it was a problem with Jetson Xavier, not ESP32

Since you are using the devkit, I would suggest using the latest JP5.1.2(R35.4.1). You could simply update it through SDKM.

If you want to use debug UART interface as the normal UART to communicate with your UART device, you should disable the combined UART first, which we don’t verify this use case locally and can’t guarantee the performance/stability.

You could try run the following commands to check if it could help for your case.

$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service
$ sudo systemctl stop nvgetty.service
$ sudo systemctl disable nvgetty.service

After executing these two instructions, they remained the same and did not solve the problem; As you said, how do I disable combination UART?

I want to emphasize that all results prior to disabling nvgetty.service were invalid within a running Linux system. However, what you might not realize is that the boot chain itself is a kind of tiny operating system on bare metal. This too has serial console activity up until the time when Linux takes over (and then serial console goes away if nvgetty.service is not running). So I suggest that nothing connect to ttyTCU0 until boot to Linux has completed.

Once you are there, then you can test. I suggest a hexadecimal pattern to start with of combinations of 0xAA and 0x55, which alternates bits. Example:
0xAA 0x55 0x55 0xAA
(or strings of this, which happens to be the old style BIOS master boot record “end of record”…a 0x55 and a 0xAA)

Unless you’ve disabled serial console in the boot chain, do not connect anything to the serial port until you reach the Linux kernel running.

I’m not positive, but I think if you disable combined UART you are also removing ttyTCU0.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.