I have been trying to read data from a serial device using rs232 to usb converter on USB1 port of TX2.
Using minicom/cutecom/arduino serial monitor on TX2 I am getting these values:
0x1d 0x1b 0x01 0x02 0x12 …
The same setup works on a laptop running ubuntu and i get correct values.
I have checked the driver installation and /dev entry ttyUSB0 which is attached to the ko module.
I have been stuck at this issue since two days. Any help will be appreciated.
Installed and flashed using sdk manager.
Jetpack 4.5.1 is installed.
Which “/dev/tty...#...” is being used on the Jetson? What are the permissions on this device (knowing “group” might say if other software is also trying to use the device at the same time)? Is your UART using 3.3V TTL logic level (if not, then you’ll need a level shifter)?
Have you tried loopback at both ends? If you wire a port’s own TX and RX (and if some flow control is enabled, then also CTS to RTS), then the port will echo content from itself to itself. The advantage is you know the port agrees with itself on various settings, whereas across two serial UART devices it is possible that there are different settings. Use loopback on both ends and see if echo works correctly in loopback mode.
First of all, thanks for a quick reply. Appreciate it.
The dev entry is → /dev/ttyUSB0
I have connected an RS232 to USB converter to the jetson tx2 USB1 port.
I tested the loop back and received the same junk character on the minicom/cutecom on tx2
I tried sending single characters in the loopback mode, and received weirder hex character For example:
Sends → j
Received (in hex)-> 0a
Sends → qwerty
Received (in hex)-> 11 17 05 12 14 19
I must also mentions, the RS232 to USB works properly in an ubuntu pc/laptop/notebook/raspberry pi/ jetson nano
I have saturated the things to try to debug this issue.
For reference, is the USB plugged in to the non-Jetson computer? This is what I have been going by.
Next, the USB end would show up as “/dev/USB0”, but there is also a non-USB end which is wired to the other UART. The non-USB end must be a 3.3V logic level, and technically the RS-232 standard is a wide range of voltages via a DB-9 (technically, this is a “DE-9”, but DB-9 became the common terminology) connector. I need to make sure we are talking about wire pins at 3.3V and not an actual DB-9 connector since DB-9 changes the PHY voltages. Note that if the UART side is not 3.3V, then it won’t function entirely correctly on a Jetson, and if the RPi or other units are some other voltage, e.g., 1.8V or 5V, then it would still function correctly on those.
Regardless, both sides will have a TX and RX pin. Wiring a TX to a connector’s own RX (and possibly also CTS and RTS if CTS/RTS flow control is used) would create a loopback connection good for testing. If you connect two separate UARTs, then there may be subtle differences, e.g., one end using a different character set than the other, or one end wanting flow control, but not the other end, and this could result in differences in how the two sends actually work. When in loopback you are guaranteed that a device will correctly use its own same character set or flow control settings. Both ends would also be guaranteed to use the same logic level voltages. Thus it is quite useful to first validate each end can talk to itself, and only then move on to two separate devices talking to each other. If there is a problem in loopback mode, then the problem is significant. If the same loopback working UARTs are then attached to each other rather than loopback, and something then goes wrong, it can be inferred that there is a problem in either software settings or voltage of logic levels.
Is this a 3.3V logic level? Does loopback work at each end, or is any device unable to speak with itself? In the case of loopback, is it necessary at either side to wire CTS to RTS, or can both operate normally without CTS/RTS wired?
Thank you linuxdev for the help. It was very insightful.
I was able to resolve the problem.
The bad reading was happening due to an extra MAX232 chip in the hardware. Bypassing it resulted in correct values read on minicom/cutecom.
The IC MAX232 inside the hardware was distorting the UART signal which going into the RS232 to USB converter and thus the wrong readings.