Hello,
I already started a similar thread and I've read a plenty of documents saying that dte-mode switches RTS/CTS signals on the CPU pins (MUX).
Okay, let's suppose that it is true despite the evidence demonstrate the opposite, and I can explain why.
I tested this with linux kernel 3.14.28 and 4.1.15 and 4.5.2 without success.
My questions are:
Is there any NXP/Freescale engineer, FAE, specialist out there able to explain this behaviour?
P.S. If you need more details on this, please read this thread and the links inside it: https://community.freescale.com/thread/390320
I already tested it monitoring the RTS and CTS signals with a scope and connecting RTS with CTS on the port I am using (&uart3 = /dev/ttymxc2).
Thank you in advance.
Solved! Go to 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
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
I wonder why this question is assumed answered. :smileyshocked:
It isn't and I have an update for you.
Independently from the setting of fsl,dte-mode; in the DT,
so I have not enabled it and I am working in DCE mode (iMX6 default).
I see the behaviour below using Kernel linux-4.5.2.
Case #1
-----------------------------------------------------------
MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1 // new (ALT2)
MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1 // new (ALT2)
MX6QDL_PAD_EIM_D23__UART3_CTS_B 0x1b0b1 // new (ALT2)
MX6QDL_PAD_EIM_D31__UART3_RTS_B 0x1b0b1 // new (ALT4)
root@wandboard-solo:~# ./memtool 20e0908 2
Reading 0x2 count starting at address 0x020E0908
0x020E0908: 00000002 00000001
Case #2
-----------------------------------------------------------
MX6QDL_PAD_EIM_D25__UART3_RX_DATA 0x1b0b1 // new (ALT2)
MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x1b0b1 // new (ALT2)
MX6QDL_PAD_EIM_D23__UART3_RTS_B 0x1b0b1
MX6QDL_PAD_EIM_D31__UART3_CTS_B 0x1b0b1
root@wandboard-solo:~# ./memtool 20e0908 2
Reading 0x2 count starting at address 0x020E0908
0x020E0908: 00000000 00000001
Case #3
-----------------------------------------------------------
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
root@wandboard-solo:~# ./memtool 20e0908 2
Reading 0x2 count starting at address 0x020E0908
0x020E0908: 00000000 00000000
Datasheet chapters:
37.4.572 Select Input Register (IOMUXC_UART3_UART_RTS_B_SELECT_INPUT)
37.4.573 Select Input Register (IOMUXC_UART3_UART_RX_DATA_SELECT_INPUT)
If I change the IOMUXC_UART3_UART_RTS_B_SELECT_INPUT and/or IOMUXC_UART3_UART_RX_DATA_SELECT_INPUT registers settings there is no changes in the UART behavoiur, so in DCE mode I always get TX data from MX6QDL_PAD_EIM_D24 where a change IOMUXC_UART3_UART_RX_DATA_SELECT_INPUT shoud result in a different MX6QDL_PAD output for the TX (or RX) signal, but this is not true.
The conclusion seems that these registers setting are completely ignored by the CPU.
Could you please explain what is happening or what is wrong?
Thank you
Hello,
The daisy chain feature is intended for multiplexing of input signals.
The following note is provided in IOMUXC_UART3_UART_RTS_B_SELECT_INPUT register description :
“Route RTS_B signal to pad when UART is in DCE mode. Route CTS_B signal to pad when UART is in DTE
mode.”
This means, we should select the DAISY option only for input signal (it depends what mode is used : DTE or DCE).
Output signal is not involved in daisy chains.
Regards,
Yuri.
I've also the same problem. I think that you don't consider this as answered....
Hello,
is it possible to try UART tests from the i.MX Platform SDK ?
Regards,
Yuri.
I tested this with linux kernel 3.14.28 and 4.1.15 coming from NXP/Freescale BSP without success.
http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/refs/heads
Hello,
Looks like You need to use DTE mode, assuming all UART signals are inverted.
In such case also it is needed to configure IOMUXC_UART3_UART_RX_DATA_SELECT_INPUT.
Have a great day,
Yuri
-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------
Hello Yuri,
thank you for answering.
I wonder how to set that from the DeviceTree point of view.
I argue it is a matter of using
#define MX6QDL_PAD_EIM_D24__UART3_TX_DATA 0x164 0x534 0x000 0x2 0x0
#define MX6QDL_PAD_EIM_D24__UART3_RX_DATA 0x164 0x534 0x90c 0x2 0x0
Considering that I am using these settings
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
>;
};
but as you can read in my other post, I already tried these settings with the same result: no TX data
// 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
Could you please clarify?