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...
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 ;-(
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
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
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).