Using more UARTs for serial communication on DevKit

Hi,
I want to use more UARTs on the DevKit. According to the Pinmux configuration, there are three.

  1. One on the GPIO 40 pin header
  2. DEBUG one on the J14 header
  3. One on the baseboard M.2

Is there a way to access the 2) DEBUG J14 UART pins to establish serial communication with devices? (I assume that the default settings is that the 2) is used as a serial console to control Xavier NX).

Thank you!

hello mmmysl,

you may access NX Product Design Guide via download center, and please check [Chapter-10.3 UART] chapter for the uart signal connections.
please also access NX Developer Kit User Guide, you may using J14, by wiring pin-3 and pin-4 for UART receive and send.
thanks

Thank you for the tips.
I managed to establish the serial communication through the 40-pin header UART at /dev/ttyTHS0, but no success with the /dev/ttyTHS1 nor /dev/ttyTHS4 (I assume that one of them has to be the J14 UART).

  • nvgetty.service is disabled
  • fuser command shows no processes on the THS1 and THS4

The J14 is officially a Debug UART, so is there anything particular I should do to establish communication through it?
Thank you

Hi mmmysl,

You can use TX/RX cable and connect from J14 pins on Xavier-NX to USB port on your host mahcine.
[J14]
Pins 3: RXD
Pins 4: TXD
Pins 7: GND

And check “ll /dev/ttyUSB*” on your host Ubuntu machine and using picocom or minicom tools to open uart log.

Yes, thank you, if I understand well, that would be the case of the serial console.

But my original question was if I could use UART on J14 to other tasks - I want it to communicate with a wireless transceiver that uses Tx and Rx pins.

On the software side, I need to open the serial port and write to it/read from it. (And that is something I have not managed to do.)
No host computer will be involved in this case.

hello mmmysl,

it’s serial port for enabling ttyUSB* for sending serial data; we haven’t validate with a wireless transceiver yet.
thanks

Ok, thank you for your answer.
Matej

Hi @carolyuu @JerryChang
How could we use two uart devices with Jetson Xavier NX devkit board?
Given we are wiring two gps units - one of them uses UART from 40 pin header, how would we connect the second UART unit? Can J14 UART [TX/RX] be used? folks reported issues using it as in Use UART Pins on Jetson Xavier NX J14 - #14 by td11

hello Andrey1984,

there’re 3 UARTs available on Xavier NX,
UART0 to M2
UART1 to 40PIN
UART2 to debug

please also access Jetson Xavier NX Product Design Guide and check [11.3 UART] for more details.
please also refer to Topic 180166, it is not suggest to change UART2 (i.e. Debug UART) to general UART, because it’s reserve for kernel debug purpose.
thanks

Yeah I’m facing the same problem. I’ve been looking for an M.2 E-Key prototype board to use to get the UART but haven’t been able to find one. I think I’m going to have to use one of the cheap M.2 E-Key adapters and just solder on to it. I do have my U-Blox M9N connected via I2C but it’s a pain because you have to create your program to interface to the I2C and create a dev tty node so other programs can use it.

One other thing I’m going to try is one of these… http://serialwombat.com
I’ve got 4 of them coming in today so we’ll see.

1 Like

I got my Wombats so hopefully I can play with them tomorrow. One other thing you could try if you really want to use the J14 uart and don’t need a console there…

First, make sure there’s no console started on ttyTCU0. If there is one started, do a pgrep -fa getty and see which port it’s actually on. It could be ttyTCU0 or ttyS0. Whichever it is, do a
systemctl mask serial-getty@ttyTCU0 or systemctl mask serial-getty@ttyS0 so systemd doesn’t try to start a console on that port on next boot.

That doesn’t prevent all the bootloader and kernel messages from dumping to that port so if your GPS has an “enable” pin tie that to a GPIO so that you can have a script that enables and disables the GPS after bootup. This way neither the GPS nor the bootloader will be confused by activity on the TCU port. Another option if don’t want to actually enable/disable the GPS is to use a simple 2 channel level shifter between the TCU port and the GPS and tie the level shifter’s enable pin to a GPIO. This will leave the GPS running but just cut off communication to the TCU port until you’re ready to use it.

1 Like