UART1: CTS RTS: flow control is not the same as UART0

Hi,

L4T: r35.3.1

I want to use flow control of UART1 on Orin Nano.
I change the same pinmux as UART0:

120 (uart2_tx_px4): 
        pull=0
        tristate=0
        enable-input=0
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uartb
        pad-power=0
121 (uart2_rx_px5): 
        pull=0
        tristate=1
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uartb
        pad-power=0
122 (uart2_rts_px6): 
        pull=0
        tristate=0
        enable-input=0
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uartb
        pad-power=0
123 (uart2_cts_px7): 
        pull=0
        tristate=1
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uartb
        pad-power=0
...
152 (uart1_cts_pr5): 
        pull=0
        tristate=1
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uarta
        pad-power=0
153 (uart1_rts_pr4): 
        pull=0
        tristate=0
        enable-input=0
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uarta
        pad-power=0
154 (uart1_rx_pr3): 
        pull=1
        tristate=1
        enable-input=1
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uarta
        pad-power=0
155 (uart1_tx_pr2): 
        pull=0
        tristate=0
        enable-input=0
        open-drain=0
        io-reset=0
        rcv-sel=0
        io-hv=0
        loopback=0
        schmitt=0
        pull-down-strength=0
        pull-up-strength=0
        drive-type=0
        func=uarta
        pad-power=0

kernel add the patch from this page


test command:
Orin Nano=>
sudo picocom -b 115200 /dev/ttyTHSx -f h
PC=>
sudo picocom -b 115200 /dev/ttyUSBx -f h

UART1(/dev/ttyTHS1) didn’t transmit/ receive and data.
But UART0 is working well.

THANKS~~

Hi joe.zhang,

Are you using the devkit or custom board for Orin Nano?

Please refer to the following mapping for UART interface in Orin NX/Nano.
OrinNX : How to check UART is working? - #3 by KevinFFF

For UART1, it seems you should use /dev/ttyTHS0.

Hi Kevin,

Sorry, I misunderstand the naming rule, let me correct that.
UART0 => /dev/ttyTHS1 => serial@3110000
UART1 => /dev/ttyTHS0 => serial@3100000


But I struggle at the flow control test
we using picocom -f h to enable hardware flow control.
/dev/ttyTHS1/dev/ttyTHS0 ===> pass
/dev/ttyUSB0/dev/ttyTHS0 ===> pass
/dev/ttyUSB0/dev/ttyTHS1 ===> pass

All port can transmit/ receive data as normal.
But we don’t think picocom can test flow control function.
So we use another test tool linux-serial-test has problem.
(This tool send ASCII to another port, check is the input port’s pattern is correct or not.
If flow control is on, you can set delay( -l) to cause buffer to fill up and start using flow control)

we also use picocom to see what’s the result of data.

Flow control UART1 (/dev/ttyTHS0) TX UART0 (/dev/ttyTHS1) TX USB tty (/dev/ttyUSB0) TX
UART1 (/dev/ttyTHS0) RX - some of the byte is wrong pass
UART0 (/dev/ttyTHS1) RX some of the byte is wrong - pass
USB tty (/dev/ttyUSB0) RX completely wrong completely wrong -

I wonder if the patch mentioned before (force RTS remain low) cause this issue?
We had verified this test tool on x86 PC, i.MX8M series.
We consider this is the issue targets to Nvidia serial driver( serial-tegra.c).

If you don’t trust this flow control test tool, please tell us which tool should use for.

THANKS~~
Joe

Any thought or update?

That seems the old patch for previous release.
Do you apply that for Orin Nano with R35.3.1?

How do you know the byte is wrong?

Could you also try using minicom?

Yes

We run picocom on receiving side, check the data sending from transmitter.
It should be the ASCII code with the same pattern.

picocom and minicom share the same result, since the RTS is remain low, transmitting/ receiving data is okay.

But both of them can’t trigger the buffer fill up condition that can toggle the RTS to pause receiving data.

We verified the linux-serial-test can trigger this condition on i.MX8MP and USB tty.

So we think the UART flow control is non-working for serial-tegra.c.

There’s a known UART issue on JP5, please wait for the next JP6 GA release for the fix.

OK

I’ll wait til that fix.