The OFC flag is going set and keeping the serial port from transmitting. I’m using no flow control. My understanding of an output buffer overflow would be that I am sending too much data to the serial port’s transmit buffer to quickly. I’m not, I’m using a master-slave (request-reply) protocol with very small packets (< 10 bytes) and a very generous response timeout period. This application works on a hundred gateways except for three, something is triggering the OFC flag to go set. They will work for hours or weeks and then suddenly I have to reboot them, but only with these 3 units.
Yea, I finally figured this out. The SerialOpen routine in Digi’s DIA fails to disable software flow control. It’s always on.
I think you can disable the software flow control.
With software flow control (host to host), two ASCII characters are given special meanings. The character 0x13 (ControlS or DC3 or XOFF) when sent across the serial link tells the other side to stop sending. The character 0x11 (Control-Q or DC1 or XON) tells the other side to resume sending. When oftware flow control is in use, it follows that these characters cannot be sent as part of the data stream.
When sending API packets it isn’t possible to avoid the need to include the software control characters. For instance, checksums and addresses can contain any values. Therefore the API escape mode (AP=2) exists. In this mode the
character 0x7d is defined as the escape character. When a host wants to transmit 0x11 or 0x13 it transmits the escape
character first, and then the desired character XORed with 0x20