Thanks for the suggestions. Here’s what we found after trying them:
We tried connecting using 1200 and 9600 baud, but we didn’t get any responses even after power cycling before attempting at a different baud rate. Only at 115200 baud do we get responses from your serial commands.
We also tried sending the Device Reboot command sequence you suggested, and the combination of Storage Setup, Storage Cancel, and Device Reboot commands with a one second delay between each. Neither of these two command sets had any effect.
Specifics of what we see:
The anomalous behavior we are seeing is that there are dropped bytes in the responses. After a clean boot, the board responds to a 254, 166 command (Read all inputs) with 255, 255, 255, 255, 255, 255, 255, 255 (8 bytes). This continues to work fine until we reboot the Linux USB client without cycling power to the GPIO board.
Then it starts behaving anomalously. For the same command above, get between 3 and 6 bytes in response (all of them are the expected 255 value) instead of the expected 8 bytes. After a read timeout, we try again, always with the same result – fewer bytes in the response than expected. Cycling power to the board fixes the condition, but we can find no way to clear the condition through commands. The only two ways we can clear the conditions is (a) cycling power to the board (b) connecting to a Windows machine and saving settings from the Windows client, then re-connecting to our Linux controller.
Other than the serial interface, is there any other way your Windows client alters the state of the board? We have noticed that on Linux there are several devices other than the USB serial interface that appear when we connect the board. Perhaps one of these other interfaces could be used to reset the state?