Hello,
I am trying to use the UART3 on my SABRE board but can't get the hardware flow-control working correctly.
What I've done:
I use a Yocto image built from the official freescale BSP sources: meta-fsl-bsp-release.git - Freescale i.MX Yocto BSP Release Layer
I connected the UART3 via the following pins: EIM_D25 -> RX, EIM_D24 -> TX, EIM_D30 -> CTS, SD3_RST -> RTS
In the device tree, I've configured the uart3 with the following pins:
MX6QDL_PAD_EIM_D25__UART3_RX_DATA
MX6QDL_PAD_EIM_D24__UART3_TX_DATA
MX6QDL_PAD_EIM_D30__UART3_CTS_B
MX6QDL_PAD_SD3_RST__UART3_RTS_B
Now I can see the /dev/ttymxc2 device on my SABRE board and cat /sys/kernel/debug/pinctrl/pinctrl-handles shows that the pins are muxed for the serial port. Sending and receiving data works correctly if hardware flow-control is disabled. When I enable hardware flow-control, I can send data but receive data does not work.
Expected behaviour:
When trying to receive data, I expect that the i.MX6 would pull down the signal on EIM_D30 (UART3_CTS_B) to signal the other device that it is allowed to send data. But the signal is not pulled down and so the other device will not start sending data which in turn means, that the read operation on the i.MX6 will block forever.
Can anyone tell me what I am missing here? Are my expectations wrong? Did I misconfigure the UART3 (e.g. wrong device tree config)?
Solved! Go to Solution.
Hello Alejandro,
I now figured out the problem and the UART3 is working with hardware flow control. I did not realize that the 'fsl,imx6q-uart' driver has an optional flag named 'fsl,uart-has-rtscts' which must be set when the RTS and CTS lines are connected. I've updated my .dts file to include this flag and the hardware flow control is now working correctly.
I'm still not sure why the 'send' portion of the hardware flow control was working as expected even though I did not set up the 'fsl,uart-has-rtscts' flag at first.
My .dts file now contains this:
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3_2>;
status = "okay";
fsl,uart-has-rtscts;
pinctrl_uart3_2: uart3grp-2 {
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
>;
};
};
Hi Deepanraj,
I do not have a dedicated test application for UART with CTS/RTS. The tests I've done were performed with the application I was writing. I'm afraid that application is proprietary and closed source though, so I can't provide you with any source code.
Regards,
Michael
Thank you,
Deepanraj.A
Hi,
Can you share the .dts file?
Best Regards,
Alejandro
Hello Alejandro,
I now figured out the problem and the UART3 is working with hardware flow control. I did not realize that the 'fsl,imx6q-uart' driver has an optional flag named 'fsl,uart-has-rtscts' which must be set when the RTS and CTS lines are connected. I've updated my .dts file to include this flag and the hardware flow control is now working correctly.
I'm still not sure why the 'send' portion of the hardware flow control was working as expected even though I did not set up the 'fsl,uart-has-rtscts' flag at first.
My .dts file now contains this:
&uart3 {
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_uart3_2>;
status = "okay";
fsl,uart-has-rtscts;
pinctrl_uart3_2: uart3grp-2 {
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
>;
};
};
Hi,
Can i know how you tested UART H/W flow control
Any Test application to test Serial UART CTS/RTS.
Thank you,
Deepanraj.A