Hi
I have a roboclaw driver board that I want to drive via UART. I have a node written by a third party that takes ros topic /cmd_vel and converts it into signals that drive the roboclaw. This works fine for USB on port ttyACM0.
I now cannot use USB as the roboclaw port is damaged, and so I need to use UART, but I cannot figure out how to set up the TX2 UART to do anything. I attach jumper cables to pins 8 and 10 of the TX2 and attach to the corresponding TX / RX of the roboclaw.
In dmesg I was seeing some “cable state 2” error messages, which appeared to relate to ttyS0, but I have no idea if this is the port it thinks the roboclaw is talking on, or what the error message means. Google is not being my friend and I cannot see any documentation in the tx2 library that comes up with search words UART or GPIO.
Is there some set up that needs to be done on the TX2? I am something of a beginner when it comes to all this, so if you could make the replies somewhat ELI5 it would be really appreciated!
Cheers
EDIT: I read that I need to use the J17 header, pins 4 and 5, so I have switched to them. I am guessing that the port is dev/ttyTHS2, however I still do not seem to be able to fully connect to the board. Is there a way to check there is communication?
I’m restating part of this just to be thorough.
Beware that pins 8 and 10 are already dedicated to serial console. Unless you’ve disabled this function in both Linux and U-Boot it won’t do what you want and will probably prevent booting since serial console activity during boot will drop into the U-Boot command line.
J17 has 6 pins which are free to use. The TX goes to the other end RX, the RX goes to the other end TX, GND goes to GND. If you use flow control, then CTS goes to RTS on the other end and RTS goes to CTS on the other end. The default designation for this port in Linux is “/dev/ttyTHS2”.
One of the difficulties of serial port testing is that it is not plug and play hardware…you can ask the driver what settings it is using, but that doesn’t mean the hardware itself accepts those settings. One of the best ways to test is with loopback because a port will always agree with itself for settings. Loopback without flow control just means a jumper on the local connector between TX and RX. If you want to test with flow control, then you just that connector’s CTS and RTS.
I suggest using gtkterm to test with. If it works, then as you type text it will echo back. An example startup would be:
gtkterm -b 8 -t 1 -s 115200 -p /dev/ttyTHS2
In that example uses 8 bits, 1 stop bit, speed 115200, and port “/dev/ttyTHS2”. Note that if you try to go faster than 115200, then you will want to use two stop bits.
If you don’t have gtkterm:
sudo apt-get install gtkterm
To get gtkterm options:
man gtkterm
In terms of wiring shorter is better. Twister pair with grounded shielding would be the best. Ethernet cable is a good cable for this. Shorter or slower speeds are far less critical, but I would still advise twisted pair for TX/RX (and CTS/RTS if using flow control).
@linuxdev
Thank you for replying and confirming about the console too.
I am not quite sure what is meant to be happening with gtkterm - I have pins 4 and 5 of header J17 wired together and ran the command you posted. A black terminal pops up with a flashing cursor, but I am unable to type in it or do anything. Is this perhaps an indicator something is wrong?
EDIT: Ah ok I see I need to set up some configuration maybe? It looks like gtkterm can only see /dev/ttyS0 - 3 and not THS2 etc, even though I know /dev/ttyTHS2 appears when I ls /dev/
Cheers
Correct, this means the issue is at the TX2 side if you only get a prompt and typing in does not echo.
So far as serial port naming convention goes there are two possible drivers for the Tegra UARTs. One is the old style traditional driver, another is a “high speed” driver which uses DMA to make higher speeds work better. One driver will make available “/dev/ttyS2”, the other driver will make available the high speed “/dev/ttyTHS2”. Both are accessed the same way. Accessing it with both drivers at the same time would be “bad”. The only reason why the older “ttyS2” exists is because the boot loader only has drivers for the old style naming convention…and there will sometimes be a need when accessing USB in U-Boot and transitioning to the Linux kernel has to maintain the hardware as continuously running without a break (think for example of booting on a USB hard drive…if the hard drive is the file system, and USB blinks while loading the kernel files, then things don’t go well).
The serial console uses ttyS0 and not ttyTHS0 because of the need to remain in continuous operation from U-Boot to Linux (the end purpose of U-Boot is to overwrite itself with the Linux kernel).
For your case you need to use the J17 connector, not J21 (J21 will guarantee failure because it is the serial console). J17 is unused, but does have wiring to the camera port (the default camera with the dev kit won’t use this). J17, from Linux, should always be “/dev/ttyTHS2” for your purposes.
More specifically, the loopback test shows the port won’t operate at the settings gtkterm was used with. If it happens that the settings used are the same as the settings when connecting your device, then we know the port can’t function due to the TX2 side.
Can it be confirmed that J17 was used? What was the exact command line used to start gtkterm? What are the exact settings you want to use with the external device?