Issues with auto CTS/RTS hardware flow control feature on Vybrid platform

[bhuvanchandradv]

Hello,

I'm testing the auto RTS/CTS hardware flow control feature available on Vybrid lpuart port, with the mainline fsl_lpuart driver.

As per the reference manual RXRTSE and TXCTSE bits in UARTx_MODEM register will enable the auto RTS/CTS hardware control.

Vybrid lpuart as receiver: RXRTSE enabled:

If the receiver request-to-send functionality is enabled, the receiver automatically

deasserts RTS if the number of characters in the receiver data register is equal to or

greater than receiver data buffer's watermark, RWFIFO[RXWATER]....

Auto RTS control was working as expected, tested by sending data from CP2108-EK board to Vybrid lpuart.

Vybrid lpuart as transmitter: TXCTSE enabled:

If the clear-to-send operation is enabled, the character is transmitted when CTS

is asserted. If CTS is deasserted in the middle of a transmission with characters remaining

in the receiver data buffer, the character in the shift register is sent and TXD remains in

the mark state until CTS is reasserted...

Auto CTS control was not working as expected, data was not transferred even when CTS was asserted.

Did anyone verified the auto RTS/CTS hardware flow control feature on Vybrid lpuart ?

Best regards,

Bhuvan

[CommunityBot · Accepted solution]

This an automatic process.

We are marking this post as solved, due to the either low activity or any reply marked as correct.

If you have additional questions, please create a new post and reference to this closed post.

NXP Community!

[jiri-b36968]

Hello Bhuvan,

flow control was validated on SoC level. lpuart driver is Linux driver right? It was not validated by Freescale. Linux is hadled by Timesys. Please add some details. What is delay between de-assert and re-assert moment? What is setting of the driver? What is state of TxD pin in between?

/Jiri

[bhuvanchandradv]

Hello Jiri,

Auto RTS/CTS works fine! the issue is, serial core assumes the CTS as de-asserted and blocks transmission forever, setting the TIOCM_CTS flag explicitly fixes the issue. !

Thanks!

Best regards,

Bhuvan

[bhuvanchandradv]

>What is state of TxD pin in between?

UART2_TXD state was de-asserted.

[bhuvanchandradv]

Hello Jiri,

>flow control was validated on SoC level. lpuart driver is Linux driver right? It was not validated by Freescale. Linux is hadled by Timesys. Please add some details.

The present implementation for RTS/CTS control for Vybrid lpuart in Linux driver was broken, as RTS/CTS was automatically controlled by hardware when RXRTSE and TXCTSE bits were set. There is no need of manually controlling them from set/get mctrl, those bits are not responsible for directly controlling the RTS/CTS lines.

Now the issues i'm observing are with CTS, somehow transmitter was not able to read the state of the CTS. Even when the CTS was asserted the transmitter was not transmitting the data.

>What is delay between de-assert and re-assert moment?

I didn't observed any state change with the CTS signal. The initial state of the CTS  is asserted, expecting the data to be transmitted from transmitter.

>What is state of TxD pin in between?

I'm not very sure about the TX signal status, will check that and let you know.

>What is setting of the driver?

Using CRTSCTS the RXRTSE and TXCTSE bits were set, enabling the auto RTS/CTS hardware control.

Kindly find the attached patch.

Best regards,

Bhuvan