UART TX2 - receive, teency 4.0 mcu

Hello,

I have a bit of a problem with UART communication, it works without problems to send commands to teency but from teency the tx2 sometimes gets the wrong data, what could this be due to? All help is welcome!

Components:

  • TX2 dev board
  • Tenncy 4.0 from (pjrc)

Teency sending code (simple sending)

--115200 serial speed--
byte buffer[3] = { 0x7e, 0x6e, 0x00 };
   
void loop()
{
	serial_jetson.write(buffer, sizeof(buffer)+1);
	delay(50);
}

Jetson TX2 code

The process runs in a separate thread so as not to lock the main thread that handles image processing, the problem is that sometimes received is right sometimes and wrong sometimes a little random, what can the cause be for that?

SerialCommunication serial;
serial.open_connection("/dev/ttyS0");
std::thread serialThread(&SerialCommunication::process, &serial);
#define VMINX 1
#define BAUDRATE B115200

void SerialCommunication::open_connection(const char* device)
{
	struct termios port_options;   // Create the structure                          

	tcgetattr(serial_, &port_options);	// Get the current attributes of the Serial port 

	/* open serial port */
	serial_ = open(device, O_RDWR | O_NOCTTY);
	tcflush(serial_, TCIFLUSH);
	tcflush(serial_, TCIOFLUSH);

	usleep(1000000);  // 1 sec delay

	if (serial_ == -1)
	{
		printf("Error - Unable to open UART.  Ensure it is not in use by another application\n");
	}

	port_options.c_cflag &= ~PARENB;            // Disables the Parity Enable bit(PARENB),So No Parity   
	port_options.c_cflag &= ~CSTOPB;            // CSTOPB = 2 Stop bits,here it is cleared so 1 Stop bit 
	port_options.c_cflag &= ~CSIZE;	            // Clears the mask for setting the data size             
	port_options.c_cflag |=  CS8;               // Set the data bits = 8                                 	 
	port_options.c_cflag &= ~CRTSCTS;           // No Hardware flow Control                         
	port_options.c_cflag |=  CREAD | CLOCAL;                  // Enable receiver,Ignore Modem Control lines       				
	port_options.c_iflag &= ~(IXON | IXOFF | IXANY);          // Disable XON/XOFF flow control both input & output
	port_options.c_iflag &= ~(ICANON | ECHO | ECHOE | ISIG);  // Non Cannonical mode                            
	port_options.c_oflag &= ~OPOST;                           // No Output Processing

	port_options.c_lflag = 0;               //  enable raw input instead of canonical,

	port_options.c_cc[VMIN]  = VMINX;       // Read at least 1 character
	port_options.c_cc[VTIME] = 0;           // Wait indefinetly 

	cfsetispeed(&port_options,BAUDRATE);    // Set Read  Speed 
	cfsetospeed(&port_options,BAUDRATE);    // Set Write Speed 

	// Set the attributes to the termios structure
	int att = tcsetattr(serial_, TCSANOW, &port_options);

	if (att != 0 )
	{
		printf("\nERROR in Setting port attributes");
	}
	else
	{
		printf("\nSERIAL Port Good to Go.\n");
	}

	// Flush Buffers
	tcflush(serial_, TCIFLUSH);
	tcflush(serial_, TCIOFLUSH);

	usleep(500000);   // 0.5 sec delay
}

void SerialCommunication::process()
{
	while(true)
	{
		unsigned char buffer[VMINX];
		int size = read(serial_, (void*)buffer, VMINX);
		if (size > 0)
 		{
			if (buffer[0] == 0x7e)
			{
				std::lock_guard<std::mutex> lockguard(mutex_);
				cameras_.swap();
			}
		}		
		std::this_thread::sleep_for(std::chrono::milliseconds(1));
	}
}

Best regards!

Assuming the answer is right sometimes, but not others, there is a chance that the issue is from signal quality. How long is the cable? Are TX and RX twisted pair? Is there shielding? For very short cables it shouldn’t matter in most cases, but for anything in a noisy environment or for longer cables this can be quite an issue. I like using ethernet cable for serial UART cable if it is more than a few inches.

Hey,

the length is short around 100mm, it is pure copper cables that are also used for gyro sensors. Send from tx2 to teency card always works, only receiving data sometimes fails. So it is a bit unclear what it may be due to. Maybe it’s the way I receive data on or interference on ttyS0? I’m fairly new to this and has discovered this error after a while of longer tests, I noticed that buttons sometimes stop working and turn out that the data received on the tx2 sometimes fails.

Best regards

hello rndbit,

could you please stop the nvgetty service for verification,
for example,

$ systemctl stop nvgetty
$ systemctl disable nvgetty

please refer to Jetson Nano how to use UART on /ttyTHS1 - #2 by gtj as see-also,
thanks

Put your teensy code.

Hi,

nvgetty is already disabled.

You can find it in first topic, just a basic send.

Feels like that’s the way I receive data. Is it possible to read continuously and add all data to a buffer and when the checksum is correct you read out the command, but it is as if not all data arrives or completely wrong order so this never works so this does not work either. I have also tried reading in the main thread and there is no difference… I’m a bit out of ideas now.

Take a close look at @JerryChang’s answer. Normally ttyS0 is used as a serial console. You probably have a login prompt or bash shell on the same UART at the same time with output to the Jetson being reacted to as if it were a command line. The nvgetty service stops or starts use of serial console. Make very sure two things are not running on serial at the same time.