RS232 Communication fails with Hardware Flow control option

cancel
Showing results for 
Search instead for 
Did you mean: 

RS232 Communication fails with Hardware Flow control option

724 Views
koilarulraj
Contributor II

Hi,

In my custom iMX7 board, I am using UART5 module (ttymxc4) for RS232 communication.

Below is my device tree configurations corresponding to uart5.

&uart5 {
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&pinctrl_uart5 &pinctrl_uart5_rts_cts>;
    pinctrl-1 = <&pinctrl_uart5 &pinctrl_uart5_rts_cts>;
    assigned-clocks = <&clks IMX7D_UART5_ROOT_SRC>;
    assigned-clock-parents = <&clks IMX7D_OSC_24M_CLK>;
    status = "okay";
};

pinctrl_uart5: uart5grp {
    fsl,pins = <
        MX7D_PAD_I2C4_SDA__UART5_DCE_TX        0x79 /* TX */
        MX7D_PAD_I2C4_SCL__UART5_DCE_RX        0x79 /* RX */
    >;
};

pinctrl_uart5_rts_cts: uart5_rts_cts_grp {
    fsl,pins = <
        MX7D_PAD_SAI1_TX_SYNC__UART5_DCE_CTS    0x79 /* CTS */
        MX7D_PAD_SAI1_TX_DATA__UART5_DCE_RTS    0x79 /* RTS */
    >;
};

Without Hardware Flow control, the data transmission occurs correctly on both sides. [Board to PC and PC to board]

But When I enabled Hardware Flow Control option on both host PC and my imx7 board,

1. The data can be transmitted from board to PC without any issue.

2. From PC to board we cannot do any data transfer.

After few days of debug, we found that the RTS line from board is always maintained at 3.3v from boot.

We can able to transfer data from both sides with hardware flow control, if we configure RTS line as GPIO and manually drive it to zero.

But I think it is not a proper solution. Kindly help me to find that, whether the serial driver forces the RTS line to be in HIGH state. Because we checked our hardware design and it seems everything is fine.

Tried all the PAD settings given in the Reference manual.

Kindly help me to solve this issue.

Thanks

Koil Arul Raj S

Labels (2)
0 Kudos
4 Replies

239 Views
koilarulraj
Contributor II

Hi Diego,

Yes, the input/output direction of the RTS/CTS lines plays very important role in the RS232 communication with hardware flow control option.

We used DCE mode UART operation. In this mode RTS is input and CTS is output. But as per our hardware design it was just opposite. So we just swapped the RTS/CTS line and solved the issue. Also it is very important to have the "uart-has-rtscts" property in device tree entry corresponding to our UART module to indicate serial driver about hardware flow control option.

Thanks,

Koil Arul Raj S

239 Views
koilarulraj
Contributor II

Hi Diego,

Thanks for your response.

Unfortunately I cant try the above pinmux settings on the final board, since they are used to mux other signals.

We used the pin mux signals given in my question above based on our final board design. Do you think the pin mux configuration which we use must be the problem for RS232 communication failure. Is there any valid reason to support that fact?

Thanks,

Koil Arul Raj S

0 Kudos

239 Views
diegoadrian
NXP Employee
NXP Employee

Hello,

Can you please see the below document

https://community.nxp.com/docs/DOC-97509 

Probably, this answer to your question.

Best Regards,

Diego.

0 Kudos

239 Views
diegoadrian
NXP Employee
NXP Employee

Hello,

Your pin muxing is way different as the one the pinmux tool show me.

Can you please try with the below configuration?

fsl,pins = <
MX7D_PAD_GPIO1_IO04__UART5_DCE_CTS 0x00000014
MX7D_PAD_GPIO1_IO05__UART5_DCE_RTS 0x00000014
MX7D_PAD_GPIO1_IO06__UART5_DCE_RX 0x00000014
MX7D_PAD_GPIO1_IO07__UART5_DCE_TX 0x00000014
>;

Best Regards,

Diego.

0 Kudos