ColdFire MCF5474, mcfserial.c, and RTS / CTS flow control.

We are using the ColdFire MCF5474 with the second internal UART connected to the second internal UART of a ColdFire MCF5232. Both UARTs are setup for RTS / CTS flow control. We are using Linux BSP (linux-2.6.10) on the MCF5474 side and no OS on the MCF5232 side.

The code in mcfserial.c enables RXRTS in Mode Register 1 and enables TXCTS in Mode Register 2 when CRTSCTS is set. This is correct for allowing the UART to handle RTS / CTS flow control. However, the code in mcfserial.c also includes the routines mcfrs_throttle and mcfrs_unthrottle, which directly disable and enable RTS. I modified mcfserial.c slightly to configure the /PSC1CTS and /PSC1RTS pins for /PSC1CTS and /PSC1RTS functions instead of being generial I/O pins.

During normal operation I never see the MCF5474 RTS signal go inactive. During a configuration change of the system, the thread that handles reading the data from the MCF5232 is placed in a "paused" state until after the configuration change has completed. The problem we are having is that occasionally the MCF5232 has sent a lot of data to the MCF5474 and the RTS signal from the MCF5474 is going inactive (disabled) and never going active (enabled) again.

It appears that both the middle layer of Linux BSP and the UART can control the RTS signal. I did not see how the RTS signal is tracked by the code when controlled both manually and automatically. I did see where the RTS signal is tracked when controlled manually.

Has anyone had trouble with using RTS/CTS flow control with ColdFires (and Linux BSP)? I there suppose to be a way to correctly handle both manual and automatic control of the RTS signal?

Thanks for any help on this problem. Bill

Reply to
Bill
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.