We have a RS-485 interface being driven by UART2 on the Orin module. The JetPack OS sees this as “/dev/ttyS0”. The UART2/RTS signal runs to the DE pin of a MAX22500 level shifter. The DE pin enables the outputs when high and High-Z the outputs when low. Unfortunately, the way JetPack/UART2/RTS is configured, the UART2/RTS sits high and is driven low only when we write data to RS-485@ttyS0. This is exactly backwards, so nothing works. Two questions:
(1) Is there a way to invert the UART2/RTS signal in User Space? If so, how?
(2) Is there a way to invert the UART2/RTS signal in the SDK Manager build process? If so, how?
Thanks,
Bob
Hi mt_developer,
Are you using the devkit or custom board for AGX Orin?
Could you share the block diagram of your connections?
It seems the expected behavior for how hardware flow control(RTS/CTS) works.
Have you tried using inverter in your case?
We are using a custom board developed by our consultant (so not an in-house design).
I have uploaded the MAX22500e part of the schematic. The MOTOR_RTS is wired directly to the UART2/RTS pin.
Also, I tripped over this article from Advantech talking about the behavior of the RTS line for RS-485 standard. It suggests that the behavior of the UART2/RTS signal is exactly opposite of the required behavior of the RTS signal from the standard (see here: RS-485 Troubleshooting Guide - Advantech). Scroll down a little and you’ll discover this text:
“When you use an RS-485 converter with RTS control, set the RTS high before data is sent. Also, set the RTS line low after the last data bit is sent.”
Thanks,
Bob
As my ubderstanding, RTS/CTS are used for HW flow control of UART communication.
RTS will be asserted (pulled low) when it is ready to send data and will be deasserted (pulled high) when it finishes the transmission.
For DE(Driver Enable), it seems HIGH to allow data transaction and LOW to disable, which is opposite as how RTS works. You can just add a inverter between RTS of UART from Jetson and DE port of MAX22500e
Please also share the full dmesg for further check.
I apologize if what follows seems confusing, I’m using analogies to Ethernet…
I haven’t had to deal with RS-485, but it has a lot in common with RS-232. On RS-232, when directly connecting one UART to another without the intermediate data device, one would connect the first TX to the second RX, and the first RX to the second TX. Similar with RTS to DTS, and the inverse DTS to RTS. The point being that you are matching something which sends to something which receives. However, if there is an actual in-between device, then the reverse is used: TX to TX of that control box; RX to RX of that control box; so on. If you need to invert something, then perhaps it is because you are using a model with some sort of intermediate controller, but wiring for direct UART connection.
Another description: Setting up as a NULL modem versus setting up for connection to a data terminal device.
Not many people wire a computer’s Ethernet directly from one computer to another; most people wire to an Ethernet switch, and the switch talks to the other computer. It is a similar possibility with UARTs: You use a NULL modem connection for computer-to-computer without intervening switch. Make sure your wiring diagram is correct as a NULL modem type case versus through intermediate hardware because the use-case inverts logic. Sorry, I just don’t know enough about RS-485 to say for sure.
If you read my quote or followed the Advantech link from my previous post, you would have seen that the story from Advantech and my quoted text (from the same story), states the exact opposite. I have requoted the story and reposted the link. Can you address the specific statement from Advantech concerning RTS?
RS-485 Troubleshooting Guide - Advantech
“When you use an RS-485 converter with RTS control, set the RTS high before data is sent. Also, set the RTS line low after the last data bit is sent.”
Thanks,
Bob
Yes, I know that you want to invert the behavior of RTS for your RS-485.
I’m asking for your dmesg to confirm which UART interface is in use and will suggest you how to do that.
PLEASE share the full dmesg for further check.
I have attached the dmesg log. This is the command I used to capture this [sudo dmesg > dmesg.log]. If this is not what you want/need please tell me exactly how to retrieve what you do want/need.
dmesg.log (55.7 KB)
Thanks,
Bob
[ 6.279043] 3140000.serial: ttyS0 at MMIO 0x3140000 (irq = 113, base_baud = 4250000) is a Tegra
Okay, it seems you are using serial@3140000 currently.
Please share the result of the following command on your board.
$ sudo busybox devmem 0x03140020
It is the register of UART_IRDA_CSR_0 of UARTE.
The bit 3 is INVERT_RTS.
Please try to enable it to check if it can help for your case.
Here you go …
fc-dev@jetsonorinotto:~$ sudo busybox devmem 0x03140020
0x00000000
fc-dev@jetsonorinotto:~$ sudo busybox devmem 0x03140020 32 4
fc-dev@jetsonorinotto:~$ sudo busybox devmem 0x03140020
0x00000004
It looks like that bit can be flipped, so that’s good. I will have to (re)setup the RTS testing hardware again - which will take some time because I had to move onto to other things while this is being resolved. I will get back to you on whether it inverted the RTS signal ASAP.
Thanks,
Bob
Okay, please let us know if it could invert the behavior of RTS.
We found that the devmem setting above did not invert the RTS signal.
Sorry, to enable bit 3 (start from 0), you should write 0x8.
$ sudo busybox devmem 0x03140020 w 0x8
$ sudo busybox devmem 0x03140020
Setting that memory location to 1, i.e. 0x00000008, did in fact invert the RTS signal. Our RS-485 still isn’t working, but we can’t blame the RTS line anymore. At a later time, we’ll apply this change in the PINMUX configuration.
Thank you for your assistance,
Bob
