Serial device information loss with Jetson Xavier NX

Overview

We are communicating with a serial device (the DJI Matrice drone) using one of the four Xavier NX USB-A ports and a TTL cable. The serial device is connecting successfully, and we are able to communicate over the connection, but it appears that serial information is being lost.

Problem Description

  • We are using our Xavier NX to communicate over UART with the DJI Matrice drone using the DJI OSDK.
  • Both the DJI OSDK and our program are written in C++17.
  • We are connecting the Matrice drone through its UART extension ports to the Xavier NX’s USB-A port using a TTL cable
  • The DJI OSDK handles the configuration of the serial port, but we are able to set the device baud rate
  • When calling one of the DJI OSDK methods, we found that it was reporting false-negative-errors when we were using the Xavier NX, but not with any other compute device we had access to (see devices below).
  • We have tried baud rates of 230400, 921600 & 1M, with the higher baud rates resulting in less false-negative-errors.

Here is our setup:

Problem Identification

During our debugging process, we identified the Xavier NX as the most likely issue as follows:

We tested with the serial device on…

  1. Mac OS X
  2. the DJI Manifold device (built with an Nvidia Jetson TX2 processor - Aarch64)*
  3. an Ubuntu 20.04 PC (x86_64)
  4. Ubuntu 16.04 (vmware)*
    … and all platforms had no issues.

*Tests conducted by DJI in trying to reproduce the error.

We tested on our second Xavier NX and the same problems were occurring. All tests were conducted with the same TTL cables - the only thing that we changed was the connected computer.

Based on the above tests, we concluded that this is not an Aarch64 issue, or a GCC build issue, but something else which is unique to the Xavier NX.

Conclusion

We have reached the point where we are not sure what the error could be, but we are confident it is coming from the Xavier NX.

We are looking for support to help us debug this problem further, and ultimately help us solve the issue.

1 Like

I would expect higher speeds to require two stop bits.

I would expect higher speeds to require two stop bits.

Thanks for the response @linuxdev, but using two stop bits did not solve the issue. Also, one stop bit seems to work fine on the other systems we tested on.

The two stop bit requirement is due to the integrated UARTs of Jetson using clocks which are not quite exact matches for the requested speeds. I would expect external UARTs to be ok without two stop bits, but any UART integrated to the Jetson will tend to require two stop bits above 115200. This isn’t to say there are not other issues, but under higher speeds you would still need two stop bits with the integrated UARTs. I am not familiar with all DJI hardware, but in the past I think people have said (on at least some models) that there is no option for two stop bits.

If you have a serial UART protocol analyzer you could probably go straight to the answer without as much debugging, although a protocol analyzer can be somewhat expensive.

Found this deep in some documentation (a datasheet) to confirm the above answer:

1 Like