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

[joe.zhang]

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~~

[KevinFFF]

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

@joe.zhang

UART1(/dev/ttyTHS1) didn’t transmit/ receive and data.

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

[joe.zhang]

Hi Kevin,

@KevinFFF

Module UART# => SOC UART#(used pins): <uart*>@\<address> - \<node> => Usage

• UART0 => UART2(PX04, PX05, PX06, PX07): uartb@3110000 (serial1) - Unused => To M.2 Key E
• UART1 => UART1(PR02, PR03, PR04, PR05): uarta@3100000 (serial0) - /dev/ttyTHS0 => General UART
• UART2 => UART3(PCC05, PCC06): uartc@c280000 (serial2) - /dev/ttyTCU0 => Debug

For uartb, it connect to M.2 Key E port, you need soldering by yourself to use.
For uarta, it could be simply used at /dev/ttyTHS0 node
For uartc, it is debug usage currently as you could output the serial console log. If you want to use it, you should disable the combined-uart and you would not get the debug messages.

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)

GitHub - cbrake/linux-serial-test: Linux Serial Test Application

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

[joe.zhang]

Any thought or update?

[KevinFFF]

@joe.zhang

I wonder if the patch mentioned before (force RTS remain low) cause this issue?

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

@joe.zhang

some of the byte is wrong

How do you know the byte is wrong?

Could you also try using minicom?

[joe.zhang]

@KevinFFF

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

Yes

@KevinFFF

How do you know the byte is wrong?

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

@KevinFFF

Could you also try using minicom?

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.

[KevinFFF]

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

[joe.zhang]

OK

I’ll wait til that fix.

[alex247]

@KevinFFF can a patch to fix UART be made available for JP 5.1.1? We have two customers with a total of 23 systems that were expecting to use RS-485 half duplex via ttyTHS0 and now we find that the UART is not fit for purpose. We would have to recall the units and JP6 is still not even available yet. Forcing us to make this Jetpack update right now will also have knock-on effects on other development work we have ongoing.

[alex247]

@KevinFFF

[KevinFFF]

Hi @alex247,
Please file another topic and share the details for your issue.

[alex247]

I believe its the same issue? Need UART 0 or 1 to allow flow control so that we can send and receive half duplex serial commands

[KevinFFF]

I’m not clear about if you are using the devkit or other custom carrier board.
What’s the customization in your UART design?
Could you verify UART loopback test w/o enabling HW flow control?
Which UART interface would you like to use?

[mehmetdeniz]

Hi @KevinFFF,

Will this fix contain minor changes or not? Can we intergate it on JetPack-5.x versions after this release published?

Thanks,
Mehmet

[alex247]

Its a custom carrier board from Forecr (commented above). We also had the same issue with another custom carrier board.

We want to communicate back and forth via /dev/ttyTHS0

Currently it seems that we have to manually change the hardware configuration of the GPIO pins to be either send or receive. Want to just send RS485 serial messages to ttyTHS0 and for it to recognise if we are transmitting or receiving.

[KevinFFF]

For UART related fixes, they should be included in the next Jetpack 5.X release.

@alex247

Currently it seems that we have to manually change the hardware configuration of the GPIO pins to be either send or receive.

How did you perform this?
Could you help to state again about your issue with ttyTHS0?

[alex247]

Updating to Jetpack5.X is still not great because we’ll need to recall systems and re flash them and also I’m guessing this jetpack is still not available?

Is there not a patch we can run to specifically fix this on Jetpack 5.1.1?

At the moment we would have to do the following:

Command for RS485’s direction in RX (receiving) mode:
echo 0 > /sys/class/gpio/PCC.00/value

Command for RS485’s direction in TX (sending) mode:
echo 1 > /sys/class/gpio/PCC.00/value

But we just want to send OR receive to ttyTHS0 without switching the mode.

When we use ttyUSB* serial convertors we can just send and receive serial commands with a software-defined minimal interval to avoid clashes. We want to do the same with ttyTHS0 and not worry about changing the hardware configuration of the pins.

[KevinFFF]

I’m not sure if the UART related fix would help for your case.
Could you provide the detailed reproduce steps on the devkit so that I can verify it locally?

@alex247

But we just want to send OR receive to ttyTHS0 without switching the mode.

If you would just need one mode in your use case, could you just configure the default pin state for PCC.00 in pinmux spreadsheet?