AM4372: UART hardware flow control issue

Hi Puneeth,

Puneeth Bandikatla said:

We defined UART3 in dtb as below:

Please ensure these pin are not re-assigned else where in device tree. These pins are used for other functions in the EVM device tree files.

Puneeth Bandikatla said:

1. When RTS CTS are connected, communication happens without any issue

Have you checked in a scope that the RTS/CTS lines are acting correctly corresponding to RXD/RXD?

Puneeth Bandikatla said:

4. When CTS on board end is disconnected, communication happens on both side without any issue

This seems to be wrong too, the USB-serial shouldn't send data to AM437x board either, right?

Puneeth Bandikatla said:

I hope RTS CTS should be taken care by underlying drivers only, and not by high level software. Please correct me if I am wrong.

True, the kernel serial driver handles RTS/CTS when hw flow control is enabled.

Please ensure these pin are not re-assigned else where in device tree. These pins are used for other functions in the EVM device tree files.

Yes I cross-checked these RX, TX, RTS and CTS are not assigned anywhere else.

Have you checked in a scope that the RTS/CTS lines are acting correctly corresponding to RXD/RXD?

I checked on scope, but didn't got any difference on RTS and CTS.

This seems to be wrong too, the USB-serial shouldn't send data to AM437x board either, right?

I think its correct behaviour on USB-Serial, as I removed the CTS at the board-end, but USB-Serial end CTS is connected to it and is LOW. So USB-Serial will send data, as for it, it is clear to send.

Puneeth Bandikatla said:

I checked on scope, but didn't got any difference on RTS and CTS.

Do you see RTS and CTS toggle while RXD/RXD sending data in the case which has both RTS and CTS connected? I just want to check if RTS and CTS are driven properly in the normal use case.

Puneeth Bandikatla said:

I think its correct behaviour on USB-Serial, as I removed the CTS at the board-end, but USB-Serial end CTS is connected to it and is LOW. So USB-Serial will send data, as for it, it is clear to send.

Okay, yes if CTS is low, the sender will send data. Do you see CTS is high or low at the AM437 end when CTS is not connected on the USB-serial end?

Hello Mr. Liu,

Thanks for your response, let's just have some naming assumptions for this communication as below:

Let's have all board-side pins as: (b_rx, b_tx, b_rts, b_cts).

And all pins on USB-Serial converted as: (u_rx, u_tx, u_rts, u_cts).

I checked with the scope and I has below observations:

1. u_rts and u_cts are always HIGH

2. b_rts and b_cts are always LOW

3. And when I connect u_rts to b_cts and u_cts to b_rts, both becomes LOW

4. As they both become LOW, the communication happens from both ends

5. But if I disconnect u_cts, then as default state, it will be HIGH, and USB-Serial doesn't send any data to Board

6. If I disconnect b_cts, then as default state is LOW, the communication happen successfully from Board to USB-Serial

I hope this explanation will help to understand our issue.

I don't mind if RTS doesn't change at USB-Serial end, but I want to have perfect behaviour on my board.

Thanks.

Hi Puneeth,

Puneeth Bandikatla said:

5. But if I disconnect u_cts, then as default state, it will be HIGH, and USB-Serial doesn't send any data to Board

6. If I disconnect b_cts, then as default state is LOW, the communication happen successfully from Board to USB-Serial

in 6), b_cts is low, so the board sends data, is this your concern? this is expected behavior, right? the boards sends data because b_cts is low - active. If you don't want the board to send data, b_cts has to be connected to u_rts which has to be in high state.

Hello Liu,

My concern is if b_cts is not disconnected, then by default it should be HIGH and communication should not happen.

In the present scenario, the communication happen regardless the status of b_rts and b_cts, whether they are connected or disconnected or connected to HIGH or LOW.

But my expectation is that, if hardware flow control is enabled in my board, then by default b_cts should be HIGH, and should be lowered, when another device is ready to receive some data. 

Hi Puneeth,

Puneeth Bandikatla said:

AM4372_IOPAD(0x8c8, PIN_INPUT | MUX_MODE6) /* (A18) dss_data10.gpio2[16] */
AM4372_IOPAD(0x8cc, PIN_OUTPUT | MUX_MODE6) /* (B18) dss_data11.gpio2[17] */

Please change the pinmux to the following to see if it sets b_cts default to high.

AM4372_IOPAD(0x8c8, PIN_INPUT_PULLUP | MUX_MODE6) /* (A18) dss_data10.gpio2[16] */
AM4372_IOPAD(0x8cc, PIN_OUTPUT_PULLDOWN | MUX_MODE6) /* (B18) dss_data11.gpio2[17] */

Hello Liu,

Before making the RTS and CTS as PULLUP and PULLDOWN, I once cross-checked the voltage at RTS and CTS at the Board and USB-Serial.

And I got different observations than what I mentioned before.

I assume, there was a mistake in the last observation. Can you have a look on new observations:

When RTS CTS for Board and USB-Serial are disconnected

1. u_cts is HIGH and u_rts is LOW

2. b_cts is HIGH and b_rts is LOW

When u_cts is connected to b_rts and u_rts is connected to b_cts, then

1.  b_cts is HIGH and b_rts is LOW

Rest of all observations are same, i.e. 

1. There is no change in RTS and CTS pin status  when communication happen

I feel as b_cts is already HIGH and b_rts is LOW, they may not need any Pull up or Pull down.

Is there something else, which we can suspect and correct.

Thanks

Hi Puneeth,

Please do the following test only use your AM437 board UART3 and a scope.

test 1:

- connect the scope probes to UART3 TXD and CTSn

- on AM437x linux console run the following commands, which transmits a char with hw flow control disabled, you should see the char wave on the scope, and CTSn is high

# stty -F /dev/ttyS3 -crtscts 115200
# echo 'a' > /dev/ttyS3

test2:

- keep the same connection as test1

- on AM437x linux console run the following commands, which tries to transmit a char with hw flow control enabled, you should NOT see the char wave on the scope because CTSn is high

# stty -F /dev/ttyS3 crtscts 115200
# echo 'a' > /dev/ttyS3

test3:

- now connect UART3 RTSn to CTSn and keep the scope probe on it

- on AM437x linux console run the same commands as in test2, now you should see the char wave on the scope again because CTSn becomes low due to RTSn