/dev/ttyTHS2 unable to transmit

Autonomous Machines Jetson & Embedded Systems Jetson Nano
,
1

We are unable to transmit UART data on pin 99 of the Jetson Nano SOM using a custom carrier board.

We have a custom carrier PCB that has exposed pins 99 and 101 as UARTx (TX & RX) respectively. I understand these are used by the M.2 key on the default carrier board.

These pins seem to be available to software at:

/dev/ttyTHS2

When these pins are connected to an external microcontroller, we reliably get data on the RX line, but the Jetson Nano does not seem to transmit data on the TX line.

We have tried with echo, gnu screen, minicom and picocom.

I was suspicious of hardware flow control as being the root cause of our problem, but it looks like this is disabled based on this call:

stty -a -F /dev/ttyTHS2
speed 9600 baud; rows 0; columns 0; line = 0;
intr = ^C; quit = ^; erase = ^?; kill = ^U; eof = ^D; eol = ; eol2 = ; swtch = ; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 hupcl -cstopb cread clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

That said, the RTS and CTS (pins 103 and 105 respectively) are currently floating (no connect) as they are not used by our microcontroller.

We have disconnected the microcontroller and shorted the TX/RX pins to each other with a logic analyzer connected.

We have not been able to see any data on the TX line from the Jetson Nano.

I have tried with nvgetty enabled and disabled, with no change in behavior.

We were trying to get Arducam cameras working some months ago, and it looks like they may have updated our device tree, but it’s not obvious to me how to (or if I should) edit these entries, as they refer to pins (and uarts) that I cannot find in any documentation.

That said, here is our decompiled device tree entry for what I’ve come to believe are the (potentially relevant) pins:

uart3_tx_pd1 {
nvidia,pins = “uart3_tx_pd1”;
nvidia,function = “uartc”;
nvidia,pull = <0x0>;
nvidia,tristate = <0x0>;
nvidia,enable-input = <0x0>;
};

uart3_rx_pd2 {
nvidia,pins = “uart3_rx_pd2”;
nvidia,function = “uartc”;
nvidia,pull = <0x0>;
nvidia,tristate = <0x0>;
nvidia,enable-input = <0x1>;
};

uart3_rts_pd3 {
nvidia,pins = “uart3_rts_pd3”;
nvidia,function = “uartc”;
nvidia,pull = <0x2>;
nvidia,tristate = <0x0>;
nvidia,enable-input = <0x0>;
};

uart3_cts_pd4 {
nvidia,pins = “uart3_cts_pd4”;
nvidia,function = “uartc”;
nvidia,pull = <0x2>;
nvidia,tristate = <0x0>;
nvidia,enable-input = <0x1>;
};

Any help, tips or pointers would be enormously appreciated!

Thanks,

Luke

3

Hi user113667,

What’s the Jetpack version in use?

Have you tried to verify UART loopback test for /dev/ttyTHS2? (short TX/RX, RTS/CTS)

Could you also provide the full serial console log for further check?

4

Thanks for the response.

Here’s what it says when I run

sudo apt-cache show nvidia-jetpack

Package: nvidia-jetpack
Version: 4.6.4-b39
Architecture: arm64
Maintainer: NVIDIA Corporation
Installed-Size: 194
Depends: nvidia-l4t-jetson-multimedia-api (>> 32.7-0), nvidia-l4t-jetson-multimedia-api (<< 32.8-0), nvidia-cuda (= 4.6.4-b39), nvidia-tensorrt (= 4.6.4-b39), nvidia-nsight-sys (= 4.6.4-b39), nvidia-cudnn8 (= 4.6.4-b39), nvidia-opencv (= 4.6.4-b39), nvidia-container (= 4.6.4-b39), nvidia-visionworks (= 4.6.4-b39), nvidia-vpi (= 4.6.4-b39)
Homepage: http://developer.nvidia.com/jetson
Priority: standard
Section: metapackages
Filename: pool/main/n/nvidia-jetpack/nvidia-jetpack_4.6.4-b39_arm64.deb
Size: 29388
SHA256: adf7a6660f73cdc4f95bc15c48d8588688e3afa5ee18bfd5b3a3caa3a458aa02
SHA1: 5abbe0df74f71579c1a0ee30ab7c2c236e1bcdbb
MD5sum: ec293a56d17f2b2793448d621811330d
Description: NVIDIA Jetpack Meta Package
Description-md5: ad1462289bdbc54909ae109d1d32c0a8

There’s not much to show with a log. Here’s an example command attempting to echo into the device:

echo "SDFSDF\r\n" > /dev/ttyTHS2

That runs without failure.

We have also run minicom like this:

minicom -b 115200 -D /dev/ttyTHS2

Then enabled “local echo” and typed and typed. This usually works to transmit on a serial connection.

As you quoted, the TX/RX pins are shorted together with a logic analyzer connected. We verified this exact same configuration working on the other side of the serial connection (on the micrcontroller).

One difference that came up with this side, is that we have some pull-up resistors on the microcontroller side that are not present here. Our reading indicates that these shouldn’t be necessary, but calling it out as it is a difference.

Any thoughts are appreciated.

5

Update:

We have connected our logic analyzer to pins 236 & 238 (of the SOM card), which I believe is part of the boot debug UART system.

We clearly see lots of data on the TX line during boot, and we’re able to transmit additional data on this line with calls like:

echo "HELLO" > /dev/ttyS0

We aren’t able to short these pins together as it’s connected to a real shell and attempts to process the inbound data which causes boot failures.

Just sharing here to clarify that our test setup does render TX data from different pins on this device.

6

Could you help to provide the serial console log?

Do you mean the loopback test work as expected? (i.e. you could receive what you send)

7

There’s nothing to show in the log because there is no activity on the TX line whatsoever.

Please visualize a single, flat line on a logic analyzer. Or the echo command above with no response.

No, the loopback does not work we have not seen any data transmitted on this TX pin under any circumstance.

We have also tried a completely new installation of the Nvidia Ubuntu image, still no data on the TX line.

I’m suspicious of the M.2 configuration from the dev board, but I don’t know how to rule that out.

Do you have any ideas about how we might troubleshoot this issue?

Thank you,

Luke

8

To clarify, when I said in an earlier post, that the command, “runs without failure” I meant that the terminal executes and exits without an error, rather than locking up or returning an error response.

The TX line for /dev/ttyTHS2 on pin 99 did not render any data at any time.

Some other posts are talking about how we’re verifying our test set up on different UART lines and those seem to work well.l, but we’re trying (and so far failing) to bring up /dev/ttyTHS2.

Any help would be greatly appreciated.

Thank you,

Luke

9

It’s hard to debug w/o any serial console log.
There should be the debug log output through UART2 as following.

image
image1432×667 122 KB

Please check your HW design of your custom board with the devkit, and use serial console cable to capture logs from UART2.

11

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