Issues with the NIOS2-terminal since migration form Quartus10 to Quartus12.1

[Altera_Forum]

We here at (Nordco) use Altera Arria II GX45 and GX125 parts on multiple cards in our system rack (we also have 1 card using a Cyclone) which is used to perform Non-Destructive Testing of Rail, Cylinder, and Pipe systems in industrial applications. From April of 2011 to July of 2013 we used the Quartus 10 SP1 release for the multiple projects and in all cases we have some on-board diagnostics built into the NIOS2 code. These test can run in standalone mode or a USB Blaster can be connected to access them as well via the JTAG. Normally these tests are only applied interactively during code development or production testing. In July of 2013 we switched to Quartus 12.1 which gave us numerous benefits not the least of which was a fix to a SRIO problem we had been plagued by. However now the NIOS2-terminal drops the connection randomly. sometimes I can stay connected for 10 minutes sometimes it could last 30 minutes. This never happened before under 10 and it has caused some concern on our part especially because it seems to happen quite frequently when we are idle. 

  As part of the transition to 12 I also created a terminal program for our internal use which hooks the JTAG_atlantic DLL's but does this from the win32 console environment rather than then the shell used by nios2-terminal. This way I get the benefit of buffered commands that I can get to with the up and down arrow keys and also added a macro record capability so I can have commands in a macro that it will rec/play. It makes our testing go much faster. This is behaving the same way the NIOS2-terminal does. For that matter we noticed this behavior first in my app but then went back to the nios2-terminal to make sure it was not me.  All I get form the nios2-terminal when this happens is this 'nios2-terminal: exiting due to I/O error communicating with target'  Has anyone else seen this or have any ideas?

[Altera_Forum]

Yes, I see it with similar symptom's as you have noted, using Linux and Quartus 12.1sp1 No idea about the cause or a workaround, as up until this very moment I've always assumed it has been quirks of my environment (custom cables / flex boards, Chinese eBay USB Blaster, non-supported Linux distribution, etc. etc. etc.)

[Altera_Forum]

I have some more info on this. Just like you Ted I thought this was just in my setup at first. I have a mix of Altera USB blasters ad Terasic blasters and it occurs on both. 

Using the custom terminal app I created I was able to trap the error codes and it seems the error being produced by the jtag_atlantic.dll is a disconnect from the jtag server has occured. As I said before this does not happen in the 10.1 sp1 release so there is either a problem in the 2 dll's (jtag_atlantic.dll or jtag_client.dll) that have changed or the problem resides in the JTAG module itself. I have experienced occasional problems during debug as well so I would think this would be in of interest to Altera. Unfortunately of the 372 views I have gotten Ted you are the only one to comment, maybe no one else has seen this issue.   As far as the terminal goes I have stopped using the nios2-terminal in favor of my own. I am able to detect this condition in there, release the handle to the jtag and then reconnect which seems to work. My concern is over the other elements I do not have control of (the debug interface or programming utility). I wish Altera would just release the source to these dll's so the users here could maintain them if Altera is not inclined too.   Note: We have fixed this issue but still do not have a reasonable explanation from Altera as to why, and frankly unless I want to take the time to provide them with an FPGA build that works on one of their Dev. cards exhibiting this behavior I do not expect one.  This caused a lot of aggravation on our end but in the end while working with the FPGA designer we pushed the buffers on the FPGA JTAG module to 512 Bytes each. This made the problem go away and the debugger now can function without dropping the connection after only a couple of minutes. Why version 10 worked with the buffers at 64 bytes but we need 512 here on the exact same project may forever remain a mystery.