i.MX6: how to use RTS/CTS properly using UART (DTE/DCE)

[marcocavallini]

I have read a lot of posts in this community and on the internet

and the datasheet but I'm still confused about the RTS/CTS management with i.MX6.

Looks line any board is supporting these signals properly nor anybody really cares about them,

so I wonder if someone out there has experienced and solved this problem.

https://community.freescale.com/docs/DOC-97509​

I need to reproduce the behaviour I have connecting two PCs with a

Loopback handshaking null modem cable

https://en.wikipedia.org/wiki/Null_modem#Loopback_handshaking​

If I use 2 PCs I see RTS low during the transmission of data on TX

Using an i.MX6 UART3 (/dev/ttymxc2) configured in the Device Tree as follows

I get this 2 different behaviours depending on the "fsl,dte-mode" only.

TX and RTS are normally low

If I set "fsl,dte-mode" I see RTS going high during a period of time similar to the trasmission of data

but there is no data exiting out on TX

If I comment (unset) "fsl,dte-mode" I see data exiting out on TX

but RTS is always low not moving and not handshaking data.

Would be possible to use RTS/CTS like a PC does?

I tested this with linux kernel 3.14.28 and 4.1.15 without success.

pinctrl_uart3_mh: uart3grp-mh {

    fsl,pins = <

        MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

        MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1

        MX6QDL_PAD_EIM_D23__UART3_CTS_B   0x1b0b1

        MX6QDL_PAD_EIM_D31__UART3_RTS_B   0x1b0b1

    >;

};

&uart3 {            // /dev/ttymxc2

    pinctrl-names = "default";

    pinctrl-0 = <&pinctrl_uart3_mh>;

    fsl,uart-has-rtscts;

    fsl,dte-mode;

    status = "okay";

};

Any hint would be greatly appreciated.

TIA

[piyyamperumal]

Anyone really solved this issue with the above device tree along above device tree? I see its solved but looks like there is no solution provided. 

[Kanstantsin1]

Hi there. There is no possibility to swap RX<=>TX without swapping CTS<=>RTS.

You can swap RX <=> TX if  you don't use CTS and RTS easily.

If you use  TX/RX and CTS/RTS - and want to то swap only one of them => you must do  it in hardware. 

[piyyamperumal]

Hi 

Thanks for responding. 

We had a mistake in our board, RX &TX, CTS & RTS are connected 1 to 1 directly to the device from iMX8, and below is the existing Hardware connection done on our board. It's impossible to do the hardware reworked to swap these signals. Instead, I would like to swap inside the IO Port and IOMUX. 

Existing UART Connections Between iMX8 & BT Device
UART IP port, Internal	IO Direction	iMX8 PIN OUT		Device Side Signals & Pins Connected
RTS_B	I	UART_RTS_B		UART_RTS
CTS_B	O	UART_CTS_B		UART_CTS
RXD	I	UART_RXD		UART_RXD
TXD	O	UART_TXD		UART_TXD
I have updated the device tree with the like below and I am trying to use UART3 in DTE mode.  New UART Swap within the iMX8 and BT Device connection
DTE Mode (DCEDTE=1)
UART IP port, Internal	IO Direction	iMX8 PIN OUT		Device Side Signals & Pins Connected
RTS_B	I	UART_CTS_B		UART_RTS
CTS_B	O	UART_RTS_B		UART_CTS
RXD	I	UART_TXD		UART_RXD
TXD	O	UART_RXD		UART_TXD

Can someone explain, WIll this New IOMUX swap work with the device connected?

How do we set UARTxUFCR[DTEDCE] bit? Is it the same as "fsl,dte-mode"set"?

I also followed this link to read about Swapping in the IOMUX and the possible solution I could See. but I couldn't see any transaction on the TX/RX signals?

Can someone provide me the link to this solution, As this is saying solved? 

Thanks,

Peri

[Kanstantsin1]

Hi.

1. I am not sure that IMX8 has the same problem with uart as imx6.

2. You can try next:  not use CTS/RTS from uart. Use them as GPIO and set high level  to enable transmit  from other side. Some of devices perfectly work on speeds up to 115200.

[sfatyushkin]

Thanks a lot!
I read several threads about this problem (replacing RTS/CTS in the documentation from NXP regarding the standard description of these lines) - many developers made such a mistake (I made one too). And this solution (declaring them GPIO and setting static levels) really works (tested on IMX8).
It would be nice if NXP included this solution in the documentation.

Best regards,

[Kanstantsin]

Hi there. I have digged around of the topic.

I would like to finish this topic with one clear though: There is no possibility to swap RX<=>TX without swapping CTS<=>RTS.

@igorpadykov Is it right?  

[igorpadykov]

right

Best regards
igor

[marcocavallini · Accepted solution]

At last I understood the behaviour and solved the problem.

This post explains everything perfectly: https://community.freescale.com/docs/DOC-97509

Be careful: dte-mode swaps RTS/CTS and TX/RX pins

[marcocavallini]

In addition I'm attaching the excerpt from NXP documentation

Marco Cavallini | KOAN sas | Bergamo - Italia
embedded software engineering
https://KoanSoftware.com

[madisox]

It took several iterations on both the i.MX6 side and the other, but eventually we did get CTS/RTS working on our 6Q custom board.  We're using the default DCE mode for the UART.  We set the "fsl,uart-has-rtscts" property on the uart in the device tree for the driver to make use of the pins, and use the "stty -F /dev/ttymxc<n> crtscts" command to turn it on.

[marcocavallini]

Thank you madisox,

During my tests I use minicom, so the Hardware Flow Control is activated like you did with "stty -F /dev/ttymxc<n> crtscts" command.

I can't use the default DCE mode for the UART because I need that the RTS signal operated like with PC, so normally high and gets low when I want to TX.

The huge problem here is that if I enable dte-mode in the DeviceTree I don't have any data out on the TX line (even though I connect RTS to CTS to enable transmission), and I wonder if this is a silicon bug or a lack in the imx.c driver.

Any further help would be greatly appreciated.

TIA

[adamhuang]

Thanks Macro Cavallini

[weidong_sun]

Hello Marco

    Yes, we are often confused about these 2 concepts on UART port. Let me give you my explanation to you :

DCE side: provide clock to other side(DTE). In the mode, CTS is OUTPUT, RTS is INPUT.

DTE side:  working with clock from DCT.      In the mode, CTS is INPUT, RTS is OUTPUT.

Gernerally speaking, before you connect one device to the other, you only need to confirm CTS & RTS directions of UART for 2 devices. For example, connecting UART of I.MX6 to that of PC.

PC( usually, DTE device): PC_UART_CTS ----INPUT; PC_UART_RTS---OUTPUT.

I.MX6(using DCE mode);  MX6_UART_CTS---OUTPUT; MX6_UART_RTS--INPUT.

Connect 2 devices together:

PC_UART_CTS-------MX6_UART_CTS

PC_UART_RTS-------MX6_UART_RTS

But if you set I.MX6 UART DTE mode, it means:

I.MX6(using DTE mode);  MX6_UART_CTS---INPUT; MX6_UART_RTS--OUTPUT.

conections will be changed:

PC_UART_CTS-------MX6_UART_RTS

PC_UART_RTS-------MX6_UART_CTS

You only need to ensure signal directions are correct !

Hope above explanation can help you !

Regards,

Weidong

[marcocavallini]

Hi Weidong,

thank you for answering.

I tried doing the way you told me, but I can't see any change.

I measured the signals TX,RX,RTS,CTS with a scope directly on the CPU pin (TTL) before the TTL-RS232 converter (I removed it)

The signals operate in the same manner and I didn't notice any swap on their behaviour.

The result of my test is that if I enable dte-mode in the DeviceTree I don't have any data out on the TX line

This is what I see transmitting a single char using minicom with a PC

When I use the iMX6 based board (/dev/ttymxc2) the RTS line is the same (high) but TX is always low and no data exit out.

I tried these settings

// DCE mode : standard

MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D23__UART3_CTS_B   0x1b0b1

MX6QDL_PAD_EIM_D31__UART3_RTS_B   0x1b0b1

// DTE mode : requires fsl,dte-mode; (RTS/CTS inverted)

MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D23__UART3_RTS_B   0x1b0b1

MX6QDL_PAD_EIM_D31__UART3_CTS_B   0x1b0b1

// DTE mode : requires fsl,dte-mode; (all inverted)

MX6QDL_PAD_EIM_D25__UART3_TX_DATA 0x1b0b1   

MX6QDL_PAD_EIM_D24__UART3_RX_DATA 0x1b0b1

MX6QDL_PAD_EIM_D23__UART3_RTS_B   0x1b0b1

MX6QDL_PAD_EIM_D31__UART3_CTS_B   0x1b0b1

I'm even more confused.