I have a small MCU-based circuit which uses a Microchip MCP220 serial/USB interface to provide a USB data link. The link runs at 38.4 kbaud, and for the most part is very reliable. When connected to a host running either Debian 7 or Linux Mint 17, "/dev/ttyACM0" appears after 10 - 15 seconds. Once the device node has been created, minicom can be used to establish a connection and communications from that point forward work 100% of the time.

Our application requires the ability to connect to the MCU board regardless of the state of the serial link. In other words, the application may be re-establishing communication with the board after being restarted when the link hasn't been disturbed, a connection attempt may be the first time after both the application has launched and the board has been powered on, or the board may be disconnected then reconnected while the application is running.

I've written a simple C program with a loop which attempts to open the device once per second until either success or a termination count is reached. When the program is launched a few seconds before the USB cable is connected (or the MCU board is powered on), the call to open(2) eventually succeeds. A read operation is next attempted to purge any characters which may be in the queue, then crtl-C is transmitted to the MCU board to put it in a known state. After that, some additional commands are transmitted and the responses received are examined to ensure that all is well. O_NONBLOCK is set when the port is opened so that the program won't hang if there are no characters to purge, though I've tried several combinations of other flags which don't affect the problem described below.

I'm running into problems when the device node is opened the first time after connection. The call to open() succeeds, however subsequent read() calls fail. error(3) reports "Resource temporarily unavailable". This occurs an indefinite number of times, so in this case temporary doesn't imply that eventually read operations will succeed. If I run minicom, even if I do nothing more than launch the program then immediately exit without transferring any data, my program will work thereafter. It's evident that minicom is performing some operation that I'm missing, however I've so far not been able to determine what that might be. If anyone can provide some insights, I'd be most grateful.

-- Mike --

This error means that read() or write() would block if you hadn't set O_NONBLOCK in open().

Check if there are messages in the message buffer. They would be written to /var/log/syslog, or just run dmesg when you conduct your tests.

Perhaps the driver allows setting a debug flag to generate more messages.

Device control is usually done with ioctl() system calls. If you don't know the right sequence of actions to put your board in a workable state, perhaps you are successful by snopping what minicom is doing. You could run minicom under strace(1) and focus on ioctl() calls.

Why not use tcflush(fd, TCIFLUSH) instead of a nonblocked read to purge?

What have you tried in that regard?
Did you look at the source code for minicom?
Did you try an strace on minicom?

Regards