Does any one have a good idea on the behavior of RTS line on uarts u 1nd 1 (The one in J21 and the one on J17) on eval board ?
Below is he observation we have -
uart0 on J21 - device name in linux is ttyS0, also used as debug console for uboot and kernel RTS line is idle. NO change in voltage while transmitting.
uart1 on J17 - device name in linux is ttyTHS2 RTS line gets toggled while transmission. But active low, ie going low when transmitting.
We need both ports to be configured in RS485 mode.
FYI, “/dev/ttyTHS2” would be the J17 connector. Serial console (ttyS0) is the one on J21.
I have observed that the serial console only works with one direction of communications when CTS/RTS flow control is enabled. @DonMichael013 observed that the cause might be due to RTS being inverted, which would account for the behavior. I do not know if this would be the same on other UARTs or not. It is worth investigating.
Update : I did a try on ttyTHS1, (I guess this is routed to debug connector on eval board). Behavious is same as ttyTHS2.
Any one else has tried this ?
Any Idea on how to invert this RTS behavior in driver / device tree when using RS485 mode ?
Does NVIDIA support rts / rs485 mode in tx2 ?
Anyone from NVIDIA here ? Can someone bring some clarity here. RTS on uart0 is not changing its state at all even if we forcefully make rts go low or high. Is this pin connected to module pins at all ?
In devkit schematics, we see that these pins are used as gpios in debug connector, so we doubt that these are probably configured as gpios in pinmux. But we could not see any supporting observations for this in device tree.
has anyone used these signals here ? Please comment ?
We are bringing up our own carrier card for jetson TX2. we have two serial ports, routed to uart0 and uart1. On devkit, these are routed to J17 and J10. We need to support multi serial protocol (RS232, RS485, and RS422) on these. For that we need to toggle RTS when ports are configured in RS485 mode.
However, on testing in devkit, we found that RTS on uart0 doesnt change its state ne matter whatever we do. RTS on uart1 is acting up when transmitting data.(going low when transmitting and going high after transmission.) We need to toggle RTS on uart0 as in uart1.
We tried disabling console on uart0 (bringing both uart1 and uart0 to tegra serial driver), but that didnt help in togging RTS. RTS is almost like disconnected from soc. We had few more observations, please read above posts.
If you need any more details/observations, please let us know.
Please follow document “TX2 Configuring Pinmux GPIO and PAD” chapter steps to generate cfg file, and copy the configuration file to the default location: /bootloader/t186ref/BCT/
Hi linuxdev, carolyuu and WayneWWW, here is the update.
After generating pinmux and updating as WayneWWW suggested, we are able to control RTS on uart0.
on jetson default pinmux, uart0 rts and cts are marked reserve.
Hi, DonMichael013
I have the same problem : RTS line of ttyTHS2 is always low when transmitting and receiving in RS485 mode.
Do you have modified the spreadsheet ?
“3. Copy the configuration file to the default location:
/bootloader/t186ref/BCT/”
what you do after this step
Many thanks linuxdev
I have generated 2 “.cfg” in “/bootloader/t186ref/BCT/” step by step,then flash whole filesystem by using flash.sh.
It has nothing changed.
Could you offer me the “.cfg” files ?
Furthermore，I used 16.04
Different board revisions may use a different cfg file, and I couldn’t personally say which one is which. Someone else should have a way to verify if the right cfg file was used, and if the content change was correct for your goals.
Do note that files needing update go beyond the rootfs, so if you just updated the root filesystem, then this would cause an update failure (I mention this because you phrased it as “whole filesystem”, which to me implies the ext4 filesystem…binary partitions are separate from this and although data are not a filesystem).
FYI, if you flash on command line, then it won’t matter if the host PC is Ubuntu 16.04 or 18.04. I even use Fedora with command line (the GUI is where the restrictions come into play).