Jetson TX2 NX RS232 Communication Not working

Hi,
I have tried thata option. did not worked for me, I will check if I miss anything.

Can I make these changes in source files? I mean in dtbs while building? I could see platform/t18x/lanai/kernel-dts/common/tegra186-p3636-0001-common.dtsi file has similar section for serial@c280000 { but not sure about how to change this in source, is this only available in bpmp-dtb form?

  • serial {
  •   port = <3>;
    
  •   has_input;
    
  • };

Hi,
I have observed 2 things,

1)I have convered dtb to dts and made changes to /Linux_for_Tegra/bootloader/tegra186-p3636-0001-p3509-0000-a01.dtb
serial@c280000 {
compatible = “nvidia,tegra186-hsuart”;
iommus = <0x11 0x20>;
reg = <0x0 0xc280000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x72 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x22 0x3 0x22 0x3>;
dma-names = “rx”, “tx”;
clocks = <0x10 0xd7 0x10 0x10d>;
clock-names = “serial”, “parent”;
resets = <0x10 0x31>;
reset-names = “serial”;
status = “disabled”;
nvidia,tolerance-low-range = <0x0>;
nvidia,tolerance-high-range = <0x4>;
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x101>;
phandle = <0x101>;
};
to
serial@c280000 {
compatible = “nvidia,tegra186-hsuart”;
iommus = <0x11 0x20>;
reg = <0x0 0xc280000 0x0 0x40>;
reg-shift = <0x2>;
interrupts = <0x0 0x72 0x4>;
nvidia,memory-clients = <0xe>;
dmas = <0x22 0x3 0x22 0x3>;
dma-names = “rx”, “tx”;
clocks = <0x10 0xd7 0x10 0x10d>;
clock-names = “serial”, “parent”;
resets = <0x10 0x31>;
reset-names = “serial”;
status = “okay”;
nvidia,tolerance-low-range = <0x0>;
nvidia,tolerance-high-range = <0x4>;
nvidia,adjust-baud-rates = <0x1c200 0x1c200 0x64>;
linux,phandle = <0x101>;
phandle = <0x101>;
};

and then converted dts to dtb and checked again by doing dtb to dts to confirm the changes. changes can be seen. but once I flash the image and again check the dtb files by converting it to dts, I see status is reverted to disabled? any idea why?

I used below commands:
for full flash - $ sudo ./flash.sh jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

any idea why its happenig like this? and if I see dmsg log after ful flash flash i get below:
nvidia@nvidia-desktop:~$ dmesg | grep THS
[ 0.935064] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 32, base_baud = 0) is a TEGRA_UART
[ 0.935994] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 33, base_baud = 0) is a TEGRA_UART
nvidia@nvidia-desktop:~$ Connection reset by 192.168.0.7 port 22

  1. if I try flashing only dtb and bpmp using below commands, I get flash successful but it does not boot to desktop, I see only nvidia logo

for dtb and dtb and bpmp:
$dtc -I dtb -O dts bootloader/t186ref/tegra186-bpmp-p3636-0001-a00-00.dtb > new.dts
$ dtc -I dts -O dtb -o new.tegra186-bpmp-p3636-0001-a00-00.dtb new.dts
$sudo mv new.tegra186-bpmp-p3636-0001-a00-00.dtb bootloader/t186ref/tegra186-bpmp-p3636-0001-a00-00.dtb > new.dts

$sudo ./flash.sh -r -k bpmp-fw-dtb jetson-xavier-nx-devkit-tx2-nx mmcblk0p1
$sudo ./flash.sh -r -k kernel-dtb jetson-xavier-nx-devkit-tx2-nx mmcblk0p1

Hi,
ttyTHS2 is now getting listed:

nvidia@nvidia-desktop:~$ dmesg | grep tty
[ 0.943369] 3100000.serial: ttyS0 at MMIO 0x3100000 (irq = 31, base_baud = 25500000) is a Tegra
[ 0.962732] console [ttyS0] enabled
[ 0.965251] 3110000.serial: ttyTHS1 at MMIO 0x3110000 (irq = 32, base_baud = 0) is a TEGRA_UART
[ 0.966101] c280000.serial: ttyTHS2 at MMIO 0xc280000 (irq = 33, base_baud = 0) is a TEGRA_UART
[ 0.966850] 3130000.serial: ttyTHS3 at MMIO 0x3130000 (irq = 34, base_baud = 0) is a TEGRA_UART

Now I am able to transmit between ttyTHS1 and ttyTHS2.

I am not sure why my dtb file was getting reset, I have copied the same dtb file to
/Linux_for_Tegra/kernel/dtb

Is there any chance that dtb file at /Linux_for_Tegra/bootloader/ gets replaced by dtb files at /Linux_for_Tegra/kernel/dtb ?

debug uart is still not working for me, any suggestion? do I need to change base baud? if so how?

hello venkatraman.bhat,

it’s the path, $OUT/Linux_for_Tegra/kernel/dtb/ for the flash script to load the device tree blob.
please check the flash.sh for the details.
for example,

LDK_DIR=$(cd `dirname $0` && pwd);
...
KERNEL_DIR="${LDK_DIR}/kernel";
DTB_DIR="${KERNEL_DIR}/dtb";

it’s the flash script to copy the dtb file to bootloader folder,
for example,

if [ "${dtbfile}" != "" ]; then
        cp2local dtbfile "${BL_DIR}/${dtbfilename}";
1 Like

hello venkatraman.bhat,

did you mean UART2_TX/RX?
it’s uartb: serial@3110000, which mapping to ttyTHS1.

[EDIT]
that’s right, it’s a 6-pin UART header on the developer kit carrier board.
form the software side it uses uarta: serial@3100000

Where can I get this mapping?

Below are not for debug console?
236 | (DEBUG) UART2_TXD
238 | (DEBUG) UART2_RXD

I thought these pins are mapped to ttyS0 serial@3100000 debug UART. What are the pins for console [ttyS0] serial@3100000 ?

please refer to Topic 153941, it shows the mappings for serial ports of ttyTHS*, and UART*

Hi I went through the post,

I see with the source/public/hardware/nvidia/soc/t18x/kernel-dts/tegra186-soc/tegra186-soc-uart.dtsi.dtsi and TX2 NX Pinmux files. Also referred product design guide. I am bit confused here.

debug serial port is serial@3100000 :ttyS0 236 UART2_TXD 238 (DEBUG),UART2_RXD (DEBUG) , is that correct? I have connected the serial to USB adaptor to these pins and it is not working for me

uarta: serial@3100000 :ttyS0 236 UART2_TXD 238 (DEBUG),UART2_RXD (DEBUG)
uartb: serial@3110000 :ttyTHS1 99 UART0_TXD 101 UART0_RXD
uartc: serial@c280000 :ttyTHS3 203 UART1_TXD 205 UART1_RXD

uarta: serial@3100000 {
compatible = “nvidia,tegra186-hsuart”;
iommus = <&smmu TEGRA_SID_GPCDMA_0>;
reg = <0x0 0x03100000 0x0 0x40>;
reg-shift = <2>;
interrupts = <0 TEGRA186_IRQ_UARTA 0x04>;
nvidia,memory-clients = <14>;
dmas = <&gpcdma 8>, <&gpcdma 8>;
dma-names = “rx”, “tx”;
clocks = <&tegra_car TEGRA186_CLK_UARTA>,
<&tegra_car TEGRA186_CLK_PLLP_OUT0>;
clock-names = “serial”, “parent”;
resets = <&tegra_car TEGRA186_RESET_UARTA>;
reset-names = “serial”;
status = “disabled”;
nvidia,tolerance-low-range = <0>;
nvidia,tolerance-high-range = <4>;
nvidia,adjust-baud-rates = <115200 115200 100>;
};

uartb: serial@3110000 {
	compatible = "nvidia,tegra186-hsuart";
	iommus = <&smmu TEGRA_SID_GPCDMA_0>;
	reg = <0x0 0x03110000 0x0 0x40>;
	reg-shift = <2>;
	interrupts = <0 TEGRA186_IRQ_UARTB 0x04>;
	nvidia,memory-clients = <14>;
	dmas = <&gpcdma 9>, <&gpcdma 9>;
	dma-names = "rx", "tx";
	clocks = <&tegra_car TEGRA186_CLK_UARTB>,
		<&tegra_car TEGRA186_CLK_PLLP_OUT0>;
	clock-names = "serial", "parent";
	resets = <&tegra_car TEGRA186_RESET_UARTB>;
	reset-names = "serial";
	status = "disabled";
	nvidia,tolerance-low-range = <0>;
	nvidia,tolerance-high-range = <4>;
	nvidia,adjust-baud-rates = <115200 115200 100>;
};

uartc: serial@c280000 {
	compatible = "nvidia,tegra186-hsuart";
	iommus = <&smmu TEGRA_SID_GPCDMA_0>;
	reg = <0x0 0xc280000 0x0 0x40>;
	reg-shift = <2>;
	interrupts = <0 TEGRA186_IRQ_UARTC 0x04>;
	nvidia,memory-clients = <14>;
	dmas = <&gpcdma 3>, <&gpcdma 3>;
	dma-names = "rx", "tx";
	clocks = <&tegra_car TEGRA186_CLK_UARTC>,
		<&tegra_car TEGRA186_CLK_PLLP_OUT0>;
	clock-names = "serial", "parent";
	resets = <&tegra_car TEGRA186_RESET_UARTC>;
	reset-names = "serial";
	/*status = "disabled";*/ /*testing*/
	status = "okay";
	nvidia,tolerance-low-range = <0>;
	nvidia,tolerance-high-range = <4>;
	nvidia,adjust-baud-rates = <115200 115200 100>;
};


UARTA_TX2NX
UARTB_TX2NX
UARTC_TX2NX
tegra186-soc-uart.dtsi (5.3 KB)

these combinations are working for me , Like if I try using minicom and connect serial cable to these pins I am able to tx/rx data.

But debug pin combination I tried to connect
236 | (DEBUG) UART2_TXD
238 | (DEBUG) UART2_RXD
to a serial to USB and used teraterm in a host machine, I get no boot console, not able to use serial console. But with same carrier board and pin config I am able to connect via serial console in Nano.

hello venkatraman.bhat,

that’s right, I’ve revise my previous comments for the UART mappings also.
could you please check Jetson TX2 NX Product Design Guide for the [Debug UART Connections].
please check the footnote, please check whether you had level shifter implemented.
thanks

1 Like

I have checked, we have a level shifter
image
image

I see some junk characters on the console for all the Baud rates (I know Console Baud should be 115200, just checked with other BRs). My connections are correct as same Debug port works for Nano and NX modules on the same carrier Board.

Are some characters correct at any given baud rate on the console? If so, then I would suspect noise. How long are your RX/TX cables? Are they shielded? You might try two things:

  • Loopback, where the cable is the full length sitting as close as possible to the route it would take, but RX and TX shorted. See if echo of content has partial correct versus partial corrupt content.
  • In the current setup, see if the corrupt characters correspond to a particular input, or if it is random (see if repeating the same input results in the same or different corruption).
  • Try with the shortest possible cable. Make sure it uses quality twisted pair and is shielded. Good ethernet cable is what I tend to use.

All the characters are corrupt. Cable length is not more than 1 meter and it is shielded cable.

I have tried the shorter cable as well. I will check the other options suggested

Since all characters are corrupt, then I’d suspect either noise/signal quality issues, or else settings related to stop bits or (in the case of terminals which interpret character sets) language settings.

Note that character sets are not an issue with loopback, so loopback testing is important. Noise and signal quality are also not generally an issue with loopback when the cable is short or the loopback jumper itself is directly on the Jetson (the ultimate of short cables). If loopback succeeds independently on both host side and client side, or if loopback fails, then you’ve completed some very important and informative testing.

If loopback works on both ends, but connection across units fails, then you know corruption is probably either noise related or stop bit settings or character set related. One way to look at incorrect stop bits is to send a constant pattern and look at the result in hex instead of looking at it as a character, thus eliminating any character encoding issues; then see if there is a pattern of a bit missing or being added that you didn’t know about…the hex would basically be a shift of some subset of the pattern.

1 Like

I am able to see characters getting echoed if TX and RX shorted. But if I connected any serial to USB cable I am getting junk characters. tried with different cables.

But with these cables It perfectly works with Nano/Nx

Does your serial USB cable also have the ability to echo characters without corruption when in loopback mode? The side you tested can be guaranteed as correct function since loopback worked. If the side with USB can be used with loopback, then the same can be said of that.

In the case where two devices which work in loopback succeed, but fail when working together, then you have one of these issues:

  • One end has different settings than the other. For example, number of bits or number of stop bits, maybe even speed.
  • There is noise or signal loss, e.g., cable too long, not twisted pair, unshielded to make it worse.
  • Each end may be operating at a different voltage. Jetsons use a 3.3V TTL level UART. Is the USB cable 3.3V?

Hey I have missed to comment on that, USB cable also fine if I loopback between TX- RX pins of the cable.

yes it is 3.3 V, Also it worked fine with Nano/NX modules on same carrier board… this is what is making me to not understand the issue

Both ends work with loopback. Assuming the cable really is ok (and probably it is), and assuming voltage levels are the same (and you confirmed they are), then the problem has to be different settings at each end, or noise. Noise can still hit via a ground loop even if the units are otherwise 100% correct. Settings are most likely differing between the two. Beware that as speed goes up past 115200 (the default speed) the clock tolerance will not be quite correct at the Jetson end (so if you are trying speeds in the half Mbit/s or up range you will need to mention this), and this is one form of mismatched settings. I’m probably overlooking it, but I don’t see the exact settings listed above. If the speed is not high enough, then I wonder about a ground loop causing noise.