i.MX6 dte-mode doesn't transmit chars on UART

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

i.MX6 dte-mode doesn't transmit chars on UART

Jump to solution
3,473 Views
marcocavallini
Contributor V

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:

  1. Why if I set fsl,uart-has-rtscts; + fsl,dte-mode; the UART manages the RTS signal during my serial transmission but there are no chars going out from the TX pin?
  2. Is there any silicon bug in this CPU or any special CPU setting, to have RTS/CTS signals working when I transmit chars?

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.

1 Solution
2,308 Views
marcocavallini
Contributor V

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

View solution in original post

8 Replies
2,309 Views
marcocavallini
Contributor V

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

2,308 Views
marcocavallini
Contributor V

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

2,308 Views
Yuri
NXP Employee
NXP Employee

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.

0 Kudos
Reply
2,308 Views
valeriobardelli
Contributor I

I've also the same problem. I think that you don't consider this as answered....

0 Kudos
Reply
2,308 Views
Yuri
NXP Employee
NXP Employee

Hello,

is it possible to try UART tests from the i.MX Platform SDK ?

Regards,

Yuri.

0 Kudos
Reply
2,308 Views
marcocavallini
Contributor V

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

2,308 Views
Yuri
NXP Employee
NXP Employee

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!
-----------------------------------------------------------------------------------------------------------------------

2,308 Views
marcocavallini
Contributor V

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?