Enable second serial RS232 Astro carrier

I have been using the jetson TX2 with Astro carrier (rev. F) successfully but now, I need to connect it to another microprocessor using a serial RS232 with a 57600 baud-rate.

I have tested sending information from one laptop to the carrier (

echo -ne '

echo -ne ‘\033[2J’ > /dev/ttyS0

33[2J' > /dev/ttyS0

) and I am able to receive it successfully.
When I connect it to the microprocessor, at first I am able to verify that the carrier is receiving data (gibberish). After a couple of seconds, the system enters in a weird state (with command line errors running through the screen).
I guess that this behavior is caused by the serial console on port 0.

I have connected a USB-serial converter and everything works correctly.
I have also tried
In this case, the board shuts-down after that couple of seconds and I am not really sure if the changes were successful (when I run

setserial -g /dev/ttyS0

, I get the following output:

/dev/ttyS0, UART undefined , Port: 0x0000, IRQ: 36

I am also aware of
and performed the changes in step 1. When trying to access the files in point 2, I get an encoding problem. I can find serial@3100000 but the following symbols are just gibberish.

I also tried sending data through the other RS232 port present in the Astro carrier but I wasn’t successful.

Any pointers will be highly appreciated.

Thank you.

hello ChartersCruz,

please also check similar issue, Topic 1057789 for reference.

Hello Jerry,

Thank you very much for your answer.
I think that my problem is significantly different.

For instance, I am able to receive successfully with a laptop using ttyS0 but not using the second serial port (ttyTHS2?). Additionally, I cannot
I followed the dip switches’ settings recommended by the manufacturer to have dual RS-232 but I couldn’t communicate with ttyTHS2.

On the post you mentioned, it was a bit unclear what were the actions taken to get the port working.

Thank you once again.

I think the default on ttyTHS2 is probably speed 115200 (8 bits, no parity, 1 stop bit, no flow control). Keep in mind that two UARTs have no concept of reporting or sharing their current settings. For the commands which perform a query of a setting, know that the reply of the setting is in the driver (not the hardware), and if the driver does not know the UART cannot use that setting, then the driver will happily report or attempt to make that setting anyway. Two ports talking to each other with different settings will fail and won’t necessarily know it is because of incorrect settings.

As a test I recommend using loopback on the TX2 port and a serial console program running on the TX2. What this means is that you connect the TX to RX of that port and any send is received by itself and seen as an echo. No echo implies nothing was sent. What you are guaranteed of is that the port will always agree with its own settings and there is no possibility of a mismatch across two UART ports.

So for example, J17 of the TX2 dev kit corresponds to “/dev/ttyTHS2”. You can jumper directly between the TX and RX and traffic should echo if flow control is off. With flow control you would need to also jumper CTS to RTS (it won’t hurt to jumper these if flow control is off). To see this at 115200 8N1 try from gtkterm (“sudo apt-get install gtkterm”):

gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS2

…then typing in the terminal will echo out as you type.

To use this at 57600:

gtkterm -b 8 -t 1 -s 57600 -p /dev/ttyTHS2

Note that most serial console programs have the ability to send “IOCTL” calls for configuration of the port to different values. So if this latter example works, then you know the port was set to 57600 8N1. Without turning off the system, exit gtkterm, remove the jumpers on J17, and connect your device. See if it then works.

Also, don’t forget that the TX2 dev kit ports are not RS-232 signal levels. You need 3.6V TTL levels.

Thank you for your exhaustive answer.

The loopback has worked.
Since I am working on a carrier board, afterwards, I connected the serial port to an oscilloscope and verified that the signal was RS-232.

When connecting to a laptop, it still didn’t communicate but when I connected to my device and it has worked.

I’m guessing that either the laptop had different settings, or else the voltage levels were off (e.g., perhaps the laptop serial isn’t designed for 3.3V TTL level).