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
Solved! Go to Solution.
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
>What is state of TxD pin in between?
UART2_TXD state was de-asserted.
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