ttyTHS2 filling with 0x00

Every few hours of run time (3-4 hours), I see /dev/ttyTHS2 fill with 0x00 in place of the actual data coming from a GPS module. I’ve set UART traces on the GPS module itself to confirm the module is not the one sending 0x00. In user space I made some logs to output what was being read from /dev/ttyTHS2 and confirmed this behavior with a hexdump on /dev/ttyTHS2. Below is an example of the log output.

ERROR    imu - [16341588] Unexpected header 0x0
ERROR    imu - [16341591] Unexpected GPS characters 0x0 0x0
ERROR    imu - [16341594] Unexpected GPS characters 0x0 0x0
ERROR    imu - [16341597] Unexpected GPS characters 0x0 0x0
ERROR    imu - [16341600] Unexpected GPS characters 0x0 0x0
ERROR    imu - [16341602] Unexpected GPS characters 0x0 0x0
ERROR    imu - [16341604] Unexpected GPS characters 0x0 0x0

I’ve seen a number of posts (1, 2, 3, 4) but none have resolved this problem.

nvgetty is not installed in our image and serial-getty@ttyS0 was disabled at one point but it didn’t help.
We’re currently building on l4t-r32.4.2, but have also tested with the UART drivers from here: https://developer.nvidia.com/embedded/l4t/r32_release_v6.1/sources/t210/public_sources.tbz2.

Hi,
As you mentioned my post in your request (link 4) I can confirm that I got the same problem as you without finding any solution. Sometimes we received bunch of zeros on ttyTHS1.
My team and me have concluded that it is a Nvidia bug never corrected. I hope that your post will get a CORRECT reply from a Nvidia Engineer to solve this problem definitively !
(Nota : today we work with a USB-to-serial converter on /dev/ttyUSB0 ).
rgds, Bernard

hello AS409,

you’re using r32.6.1 public sources package. it may trigger some incompatible issue.
please refer to JetPack Archive | NVIDIA Developer for previous release sources.

when the issue happened, is this unexpected data 0x00 sending continuously? or, it’ll recover after a short while?

Messages come across the the UART lines at ~4Hz. This will typically happens for one message at a time. However, I have seen it send 0x00 for 4 messages in a row, meaning we have a loss of data for 1500ms.

It appears we’ve stumbled upon a “solution” to this issue. The upstream device tree from Nvidia does not completely enable the RX DMA for UARTC (possibly all of them). This forces PIO mode for receiving on that UART.

Added dma-names = "rx", "tx"; to the &uartc attribute in the device tree, in my case nvidia/platform/t210/porg/kernel-dts/tegra210.dts.

In a 15 hour test, there were no corrupted messages. Testing will continue but as of now, this is the accepted solution.

2 Likes