We are using the RUT955 RS232 port in modem mode with some legacy equipment. Both pieces of equipment are on the same supply. After a power outage the attached unit attempts to send some basic AT commands within1 or 2 seconds of power being restored, which is long before the '955 has completed its much lengthier restart cycle.
If handshaking is disabled on the '955 this doesn't seem to cause any problems; the commands are ignored until the '955 is ready but the attached equipment just waits and resends them until it gets the 'OK' strings it's looking for. If RTS/CTS handshaking is enabled but the legacy equipment is not powered up until the '955 has finished rebooting itself again everything works as expected. But if handshaking is enabled and both units power up together, the serial data coming into the '955 before it has completed its restart sequence appears to put it into a lock up condition where it won't respond at all even after its reboot is complete and when both hardware handshake lines are 'true'. This non responsive state appears to persist indefinitely, and is observable when the serial cable is transferred to a PC serial port and terminal emulator.
The physical RTS/CTS state is easier and less ambiguous to monitor but it appears that something similar also occurs if Xon/Xoff handshaking enabled on the '955.
The legacy equipment will respect both RTS/CTS and Xon/Xoff handshake signals and no changes are being made to its settings.
UPDATE
After more trials with different port settings it seems that this can occur intermittently whether or not handshaking is enabled.
Using stty to look at /dev/rs232 I found that the port was being set into a potentially blocking mode ( min = 1; time=0; ). I also found that when the port had gone into the locked condition, trying to use stty from the CLI tab to change the 'time' setting would hang, apparently indefinitely. So I tried adding stty -F /dev/rs232 time 20 to the user script to add a read timeout to the port from the get-go, and so far this seems to have resolved the problem.
AFAIK from my limited knowledge of Linux and its serial port details the original settings should either return a single character or return immediately with nothing at all, so if all is working correctly it should never hang up. However from experience developing hardware I have also learnt that with some chips ( eg MIcrochip PIC24F series MCUs ) a receive overrun error can freeze the UART receiver until specific code, which would not be included in a normal read, is called to clear the error state. I'm not familiar with the RUT955 hardware but perhaps something roughly similar might be happening if it receives too much incoming data before the system is ready to process it.
