RTS/CTS handshake confusion

[ThomasG1z]

In the datasheet for the i.MX6 it states that the CTS is always output and RTS input regardless of DCE/DTE mode selected. Then how can it work in DTE mode then, when the RTS would be a signal going out to the connected device/modem and CTS should be a response from the connected device/modem..?

In the datasheet of the i.MX53 (assuming the UART function block would be similar) there's a table in chapter 76.1.3 that states opposite (and what I would assume correct) direction for these signals, changing direction according to DTE/DCE mode. But then later in chapter 76.2.1.2.1 it states for instance that CTS is always _output_... as in the i.MX6 documentation.

Ok, I'm confused, or missing something obvious in the documentation in what should be pretty basic...

[YS]

I was also confused the description. but apparently Freescale i.MX5 and i.MX6 defines CTS as output (de-activated when RX FIFO exceeds the threshold) and RTS as input (stop transmission if deactivated), regardless to the DTE/DCE mode configuration.

It is furthermore complicated (and make it confused) that IOMUX register has selection to configure a GPIO pin to either TXD or RXD, or RTS or CTS. For example, linux-3.0.15/arch/arm/plat-mxc/include/mach/iomux-mx6q.h defines _MX6Q_PAD_KEY_ROW1__UART5_TXD and _MX6Q_PAD_KEY_ROW1__UART5_RXD, then _MX6Q_PAD_KEY_COL4__UART5_CTS and _MX6Q_PAD_KEY_COL4__UART5_RTS.

It almost seems like KEY_ROW1 pin can be configured to either TXD or RTX, KEY_COL4 pin can be configured either CTS or RTS. IT IS NOT!!

The function of IOMUX "DAISY" register is to select a signal source to a certain input function of the SOC. If you configure KEY_ROW1 as RXD then select TXD for IOMUX, it essentially make internal TXD-RXD loopback, NEVER to make KEY_ROW1 as TXD output. So as CTS and RTS (be careful again; CTS is output, RTS is input).

It is VERY confusing indeed, and there are lots of misleading descriptions either in the dataseet or Linux source code ;-(

[rafalfabich]

Hi,

I found this thread while searching for answer to my question: "why the hardware flow-control does not work for UART3?".

I use kernel linux-3.0.35 release, where I want to use UART3 and its RTS/CTS flow-control.

So, I configured (added) the pins as follows to mx6q_common_pads structure:

static iomux_v3_cfg_t MX6NAME(common_pads)[] = {

/*.....*/

    /* UART3  */
    MX6PAD(EIM_D24__UART3_TXD),
    MX6PAD(EIM_D25__UART3_RXD),
    MX6PAD(EIM_D31__UART3_RTS),
    MX6PAD(EIM_D23__UART3_CTS),

/*....*/

}

then, in the board code, I set flag for my uart and initialized it:

static const struct imxuart_platform_data uart2_data __initconst = {
    .flags      = IMXUART_HAVE_RTSCTS,
};

imx6q_add_imx_uart(2, &uart2_data);

Unfortunately, the RTS/CTS flow-control does not seem to work.

When I set 'crtscts' option to ttymxc2 via stty command, I cannot transfer anything. On the other hand if I use '-crtscts' the transmission works fine.

Am I missing something in pin configuration?

Best regards,

Rafal

[rafalfabich]

Hi again,

sorry for answering to myself, but I found solution to my problem.

I needed to set IOMUXC_UART3_UART_RTS_B_SELECT_INPUT in the following way:

    /* we are selecting ALT4 mode of pad EIM_D31 for UART3_RTS_B.*/

    /* reference: i.MX6 Ref.Man. p. 2683: 36.4.582 Select Input Register (IOMUXC_UART3_UART_RTS_B_SELECT_INPUT) */

#define SELECT_EIM_D31_FOR_UART3_RTS 3

#define IOMUXC_UART3_UART_RTS_B_SELECT_INPUT_OFFSET 0x92c

    {

	__iomem void *base;
	int reg;

	base = ioremap(MX6Q_IOMUXC_BASE_ADDR, SZ_4K);
	reg = __raw_readl(base + IOMUXC_UART3_UART_RTS_B_SELECT_INPUT_OFFSET);
	reg |= SELECT_EIM_D31_FOR_UART3_RTS;
	__raw_writel(reg, base + IOMUXC_UART3_UART_RTS_B_SELECT_INPUT_OFFSET);
	iounmap(base);

    }

Regards,

Rafal

[Yuri]

As for i.MX53, the datasheet is referring to the UART + additional signal multiplexing

occurring between the UART peripheral and the IC pad (at the IOMUX), while the

Reference Manual describes only the peripheral boundary (internal signals).