Hi,
I’m using Xavier-nx. I need to use all of supported UART interfaces for our application. I can see that uart : /dev/ttyTCU0 is used for debug. I want to change its function to normal UART, because I witness several abnormal behavior when communicating to that port:
I can’t not change the baudrate, the baud is fixed at 115200
Sending 0xFF leads to 2 bytes 0xFF appear at console terminal.
Xavier can’t not receive incoming data from other devices.
I have searched for solutions from community but none of them is useful.
How can I config /dev/ttyTCU0 to use it as normal UART?
Are you using the devkit or custom board for Xavier NX?
What’s your Jetpack version in use?
Actually, we don’t suggest disabling combined UART and use it as normal UART since the debug log comes from several firmwares and we don’t verify this use case before.
We use Jetpack 5.0.2 and it is a custom board.
I know combined UART is not recommended to disable, but in our application, we need 3 normal UART, and 2 other ports are in used.
I follow some related post like: [Jetson Xavier NX] UART Tune - #15 by JerryChang, but the device can’t be booted.
I just want to send/receive data through that port as normal UART, please give us some instructions.
Thank you for your support
This isn’t answering anything, but I want to throw out something about this situation (it might be useful to clarify what it is you are working with).
Each device special file name is generated by a driver. Those drivers must exist in the bootloader. Each ttyS# actually has a complementary ttyTHS# once it runs in Linux. That’s because there are two drivers for the same hardware UART once in Linux. One of the reasons the ttyS# exists is because this is a very old and long-lived driver that is in the bare metal boot chains since a very very long time ago.
For example, without the ttyTHS# driver in boot stages, if we wanted serial console to run continuously as we transition from boot to Linux kernel, then we’d have to have the ttyTHS# driver in both boot stages and Linux. Any change of driver might result in a moment of non-function as a different driver loads.
I don’t know which driver the ttyTCU# uses, but since it works with serial console, then it must exist in both Linux and boot stages.
Therein is a second effect: If you wish to disable a serial console driver in Linux, then you can do so easily. What isn’t always obvious is that then you must disable the driver in the boot stages, and usually via a second mechanism. If you disable console access incorrectly to that driver, then there is a strong changes that boot will think you’ve hit a keystroke and desire to halt boot for some interaction.
The ttyTCU# was a separate and newer UART that was never intended for end user use other than serial console. The other serial UARTs were intended for possible change by the end user. I have not personally seen anything on how to change this in boot stages. The driver will also differ from the ttyS# legacy (highly compatible) driver of the other serial UARTs (I say highly compatible because the legacy driver is everywhere and never an issue to get the driver for). You would not be able to actually get the ttyTHS# driver to work because I think the hardware for that UART series is not the same as the ttyTCU# hardware.