When debugging a project through the "debug" or "run" option eclipse frequently crashes. Find below 2 examples of the screens which appear when eclipse crashes. This is really annoying as you also manually have to kill the nios2-elf-gd.exe task as this keeps running. And makes developing really unstable. Is there any solution to this, any other users also experiencing this?
My apologize for this inconvenient tool crash. This is not common thing and few customer reported about this crash. there is no straightforward way to detect the root cause.
However, we do have some recommendations to our customers to try it out, and mostly one of those suggestions would help them:
- Change the workspace location.
- Create a new NIOS II aplciation.
- Clear the JAVA cache on your machine, simply go to control panel > Java > General > Temporary Internet files > Settings > Delete files.
- Un-install JAVA and re-install it.
- If all these things didnt work, then you might need a fresh installation of eclipse.
Also, is this crash come from any NIOS II application? or specific application?
The issues has been persistent for years now on our department with more developers experiencing this issue.It appears with:
- Quartus 10.1sp1/11.0sp1/12.1/17.1/ 18.1/19.3/19.4.
- Windows 7, Windows 10
- USB-Blaster Rev C., USB-Blaster II and Ethernet Blaster II.
- NIOS II/e or NIOS II/f
It is common knowledge on our department and what we think that it might be vague related to using too many 'printf' calls with the jtag_uart_0. It is very annoying and only occurs during debug phase with Eclipse.
I/we have worked on many PC's and different workspaces, different projects(thus different NIOS II applications but always the same crashing eclipse during debugging.
I got a bit tired/frustrated of this and thought why not ask on the forum.
I don't think your suggestions help since I have just a fresh Win10 installation for 2 months and on my old Win7 machine the same problem occurs. Do the developers of the NIOS II SBT ever try to debug under windows with using 'printf' calls? I can't imagine that they never seen this problem.
I want to add that I see this or similar error every time I debug with NIOS II Software Build tools for Eclipse.
I've generally found that the issues lies within attempting to disconnect from the target hardware. If a clean disconnect is not made (which happens often as the debugger can't make a clean break ~25% of the time) I have to perform the below steps.
When this happens I need to
- Close Eclipse
- Power off target hardware
- Unplug JTAG cable
- jtagserver.exe --stop
- jtagserver.exe --start
- Open task manager, close all instances of eclipse
- In task manager, close EXTRA instances of jtagserver.exe / nios2-gdb-server.exe (multiple will usually be spawned from failed debug attempts)
After this things will generally come back to a working state but not always.
Note that if I don't force close these applications from the task manager, my CPU and memory usage quickly go up to 100% each.
I have to go through these steps 10-15 times per day on a good day. At times I will spend 10-15 minutes attempting to get the debug environment back up and running.
If there is any information or follow up to this at all I would love to hear it. As it currently stands this is a very difficult tool to use, and especially unfortunate that it happens so often in debugging when things are already difficult.
I can confirm that the procedure described by 'TheRealNeil' is the same as I use and is indeed very annoying and would like to add after 2(!) years without any improvement in the tooling:
- the jtagserver.exe sometimes starts consuming significantly more memory (check with windows task manager/ Sysinternals Process Explorer) if this is the case it definitely has to be terminated and restarted to even have working debug session...
- The processes that might have to be terminated (depending on the crash) might be:
- Here after I start the Programmer (Quartus) which will start the jtagserver.exe
- Here after 'Nios II Software Build Tools for Eclipse ' can be started for a hopefully successful debug iteration otherwise the whole termination/startup process needs to be done again
- For remote work it is not always possible to unplug the JTAG cable, as a workaround I have added this hub https://www.yepkit.com/product/300110/YKUSH3 so I can power cycle the blaster remote
For any still dealing with this issue, I've found something that helps smooth things out a bit.
Anytime you attempt to debug, and cannot (mine typically will get stuck at 60% when it isn't working) properly launch the sessions, do the following.
Debug > Debug Configurations > Target Connection > Click 'Refresh Connections'
This has shown to be quite helpful. It won't work all of the time, but it will work some of the time!