UART(M.2 interface & /dev/ttyTHS2) data corruption on Nano

hello gaurangkumar.khodifad,

I am sorry, uarttest isn’t a public release binary file.
is it possible wire the pin to short the Tx/Rx for the self-loopback test?

Hi,

I think it will be possible. How can we test UART functionality after shorting Tx/Rx pins of M.2 connector.

Keep in mind that UARTs have settings for stop bytes. The default is 115200 8N1, so that is one stop byte. If one end is setup to use a different number of stop bytes, then receiving an extra byte or two is what you told it to do. UARTs are not plug-n-play and do not have any means of asking each other what the settings are. Quite possibly the issue is just one side being set differently than the other.

Loopback is nice because a UART will always (mostly) agree with itself on settings when talking to itself. This is where TX and RX are wired together (and possibly CTS/RTS). You’d simply open a terminal program with the chosen setting using that port. If what you type in echoes correctly then you know the UART is working as expected.

We have performed loopback test by shorting Tx & Rx pins and performed data transfer for long duration and captured logs. We are seeing some random bytes received issue in loopback test as well. We are attaching test python script and log file for the reference. Please refer to line 2748, 3475 and 3679 in “loopback_logs.txt” for data corruption
loopback_logs.txt (32.0 KB)
serial_test.py (315 Bytes)

This sounds like a noise issue, which in turn would be more problematic as the speed goes up.

  • In terms of wiring contributing to noise, is the jumper from TX to RX short and straight, or does it contain a segment of wiring which might be a bit longer and perhaps curved?
  • What speeds have you test with when there were data corruption issues?
  • If you loopback test with two stop bytes, does the corruption reduce?
  • If you loopback test at slower speeds, does corruption reduce?
  • If you jumper CTS and RTS and enable flow control, does corruption decrease?

Hi,

Please find response inline.

In terms of wiring contributing to noise, is the jumper from TX to RX short and straight, or does it contain a segment of wiring which might be a bit longer and perhaps curved?
→ Wiring is short.
What speeds have you test with when there were data corruption issues?
→ We have tested it with 9600, 115200 & 3000000 speed.
If you loopback test with two stop bytes, does the corruption reduce?
→ Nope. We are observing same corruption.
If you loopback test at slower speeds, does corruption reduce?
→ Yes. At lower speed corruption reduces but it is there.
If you jumper CTS and RTS and enable flow control, does corruption decrease?
→ After shorting tx/rx and rts/cts, we were not able to send/receive any data but we were able to send/receive data when only rx/tx was shorted

The CTS/RTS should have no effect at all unless CTS/RTS flow control is enabled. Can you check this again at speed 115200 8N1, with CTS/RTS jumpered, and see if it works with flow control off (corruption is ok, I just want to see if the hardware jumper itself is causing an effect when software is told to not use it, in which case data should flow)? With hardware flow control on there should be data transfer if and only if CTS/RTS is jumpered. Any different behavior is suspicious of hardware or driver failure.

I will recommend something like gtkterm for testing.

Hi,

We are using attached python script for loopback testing. We are setting “rtscts” to “True” to enable hardware flow control and setting it to “False” to disable hardware flow control.
Here is the result of the suggested experiments.

  1. Speed 115200 8N1 with CTS/RTS jumpered but flow control disabled
    → We are able to observe data loss in long run. We have performed experiment for 10 minutes. Attaching logs for reference.
  2. Speed 115200 8N1 with CTS/RTS jumpered but flow control enabled
    → We have performed experiment for 10 minutes but we stopped receiving data after few seconds. Attaching logs for reference.

Note: We are using image downloaded from https://developer.nvidia.com/embedded/l4t/r32_release_v7.1/jp_4.6.1_b110_sd_card/jeston_nano/jetson-nano-jp461-sd-card-image.zip for the testing.
RTSCTS_Jumpered_115200_8IN1_FlowControl_Disabled.txt (267.6 KB)
RTSCTS_Jumpered_115200_8IN1_FlowControl_Enabled.txt (1.0 KB)
serial_test.py (342 Bytes)

This is becoming a bit more peculiar. One variable I cannot predict is if program-based setup of the UART (in the Python script) might have an issue. I say this because although a legacy driver would have standardized IOCTL calls to make settings changes, I don’t know if the same is true for the Tegra High Speed driver.

I do know that when using gtkterm to simply type in values in loopback and look for echo, that this has functioned correctly. I am interested in knowing if the CTS/RTS testing (with and without the jumper, with and without gtkterm setting CTS/RTS) also behaves badly (I suspect gtkterm will behave badly and the Python method of making those settings won’t have anything to do with the issue, but if both have the same behavior, then we know for sure the issue has nothing to do with the method of setup).

There is one other possible influence on this: Device tree might have passed something unexpected. Beyond this it seems more likely to be hardware or driver failure. I’m not sure if there is a device tree setting which might cause this, perhaps someone from NVIDIA might know what influences enable or disable of CTS/RTS with the THS driver via device tree? If it isn’t related to device tree, then I don’t know of any other possible software causes and it starts looking more like hardware issues.

Hi gaurangkumar,

From HW side, have you capture the waveform of that? What’s waveform of “two extra random bytes”?

Hi,
Please also try this and check if it helps:
Jetson Nano how to use UART on /ttyTHS1 - #2 by gtj

Hi,

We have captured waveform during one of our application testing and observed extra bytes between packets. We had observed two 0x00 between two packets on waveform.

Hi,

We are using UART from /dev/ttyTHS2. Is it relevant for THS2 as well?

Hi,
Please check this:
Jetson Nano - Disable Serial Console to use all 3 UARTS - #6 by Bibek

So in your use-case, you use UART0 on the M2 key and see additional two bytes(two 0x00 0x00) in each transmission. Is this correct? And please share which Jetpack version you use.

Hi,

How does Jetson Nano - Disable Serial Console to use all 3 UARTS - #6 by Bibek useful in this issue?

Please find Jetson Nano Development kit information below.
L4T 32.6.1 [ JetPack 4.6 ]
Ubuntu 18.04.5 LTS
Kernel Version: 4.9.253-tegra

We are using
https://developer.nvidia.com/embedded/l4t/r32_release_v7.1/jp_4.6.1_b110_sd_card/jeston_nano/jetson-nano-jp461-sd-card-image.zip for the testing.

I think the point with the “Disable Serial Console” is that you have to be absolutely certain that a second program (in this case a serial console) is not interacting.

Had this test not been loopback the stray NULL bytes could have been from one side having more stop bytes. If in loopback there are stray bytes due to stop bytes, then this would probably be due to something going wrong in the driver. If serial console is still active, then it isn’t truly loopback.

Hi,
Thanks for sharing the release version. Please confirm which UART you use to communicate with another device and see the corruption:

UART2 for debug. Only TX and RX available
UART0 on the M2 Key
UART1 @ 40 pin connector

Hi,

We are using UART0 on the M2 key which is accessible through /dev/ttyTHS2.

Hi,
So far the issue is not seen on Jetson Nano developer kit and looks specific to connecting to the custom controller.

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