Given the feedback, I've done some more extensive testing, and encountered errors using the FIM UART where the 'normal' UART is rock solid.
1. No doubt that tcflush(channel, TCIFLUSH) on /com/4 wrecks receive.
2. I have a board with serial buffers on both /com/0 and /com/4 (FIM). So to eliminate potential problems with my own code, I compiled the TCP/IP to Serial example for each of the ports - literally the only difference being the last digit of the port name.
I then connected a piece of equipment which responds to polls to the serial port, and used a network app to generate the polls and display the responses, using TCP/IP. So the serial port is operating in half duplex, 9600,e,7.
a) Using /com/0 polling continued for the 60 minutes over which I tested. Throughput about 470 cps. (Second test of 30 minutes no problems)
b) Using /com/4 polling started OK, with a throughput of around 680cps. It ceased after about 7 minutes (repeated several times, and pretty consistent).
Happened after 8189 or 8190 transactions (suspiciously close to 8192?)
A breakpoint shortly after the select() (line 470 of tcpserial.c) demonstrated that select() was never picking up on data received from the network.
I tried increasing the stack size for the serial task, with no change.
3. Using my own code, I get a slightly different problem - it appears as if every so often the FIM fails to send a message. Again, errors using FIM, rock solid using /com/0.
So it looks as if the problem is somewhere in the FIM driver. Related to select(), maybe?
Any thoughts on how to track this down?