uart communication

[Altera_Forum]

I am running a 1S10 board and freestanding application to communicate over an RS232 cable to a PC. I have a GUI running on a PC sending about a 30 Hz status message that expects a NIOS response but times out in about 10 ms if nothing is received and sends again (115,200 bps and 22 bytes per message). I noticed a problem with the communication when the GUI is running and the board is powered on or reloaded (with the pushbutton); the read doesn't return any data. If the order is reversed, the NIOS powered on or reset first and then the GUI run, the comm is solid. Also, when the problem occurs due to power on order, a reset/reload does not clear the problem (probably because the GUI is there pounding it). The NIOS must be powered on without a device transmitting to it. I'm guessing there's some kind of overflow condition that doesn't get cleared and maybe somebody can easily point me to a solution before I go digging.  

 You might say, why not just have the NIOS initiate comm - and I have already taken that approach - but that doesn't help me integrate other master devices that I cannot control. I have two other masters to work with (host and GPS) that will talk when they want to without regard for the slave.   I appreciate any assistance.

[Altera_Forum]

When you do the order of GUI first then power up the Nios, are you sending right away to the Nios? If that's the case then you would not be giving the core enough time to get through the initialization code and get ready for data. (so you would be pounding the Uart with data and the Nios isn't ready to service it yet). 

 Could you describe the GUI code a little more?

[Altera_Forum]

The GUI is a Windows Dialog App (Visual C++ Net) with timers running for initiating events like getting status. It would be issuing messages to the NIOS while the NIOS is coming up, potentially. The idea is that the ports are set up in non-blocking mode (on the PC) and are read after every transmit to see if data is coming in. If data is coming in, retries allow the rest of the message to arrive before parsing the message (header and checksum). If the retries time out, the buffer is cleared and the port is flushed to remove any remaining data. Process continues. 

 Any device that comes up before the NIOS, could be transmitting to it before it is ready to receive data. Imagine a handheld unit with a GPS connected to a NIOS/CCA is powered on. The GPS initializes and begins transmitting data before the NIOS is ready - then what?

[Altera_Forum]

So will the GPS be handling Uart traffic until the Nios is ready to take over? If that's not the case then the Uart is probably overflowing. In order for the Nios to be ready to handle the Uart, it will need a few micro seconds to finish initializing. 

 <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Any device that comes up before the NIOS, could be transmitting to it before it is ready to receive data. Imagine a handheld unit with a GPS connected to a NIOS/CCA is powered on. The GPS initializes and begins transmitting data before the NIOS is ready - then what?[/b]  --- Quote End ---    Will the Nios be used just for status messenges or is it acting as a controller/error checker between the Uart and the GPS device? If you want the Nios to be up and running very fast then you have to provide code to do the initialization manually (see the small hello world sample code in the Nios install directory).

[Altera_Forum]

So, what I was hoping for was "sure, just re-initialize the UART and it will work fine". But nobody is saying that. Holding off the master is not an option - devices will be transmitting when the NIOS is coming up. I am using the freestanding approach. 

 Any other ideas?