11-01-2018 03:51 PM
I had the same issue. A quiet 2018.2 SDK crash on start.
I went to the .sdk directory and deleted the .metadata and the .sdk directories. Then I was able to restart the SDK with no crash.
Hope this helps,
11-09-2018 01:53 AM
It doesn't make any difference. The problem is not the start, the problem is the handling with the projects. And by the way, it think SDK has a bigger problem: In my installation it is not only the silent crash, but SDK is not able to import new parts. iE: i remove an IP named "wave2" and add a new IP named wave3. Vivado compiles correct, everything works, but SDK is not able to import the new files. It keeps "wave2" and regenerating of BSP doesn't help.....So we hopefully wait for a new version....
11-25-2018 03:13 PM - edited 11-28-2018 05:12 AM
I'm a new user trying to get started with a simple Arty S7 board from digilent by following their guide on working with microblaze, and I'm also suffering from the SDK crashing on launch.
Trying to launch it from the command line gives no problems but when trying to "Launch SDK" from vivado it only worked the first time:
I was able to make it to step 7.4 in this guide https://reference.digilentinc.com/vivado/getting-started-with-ipi/start which is creating a new hello world C application, but clicking finish crashed the SDK and it no longer starts when invoked from vivado, even if I delete my .xilinx folder.
I'm going to contact digilent support about this as their product is little use to people trying to learn if the tools are flaking out.
Edit: After working more on this simple example, XSDK refuses to start even from the start menu. If I delete the .Xilinx folder after every run I can get it to start from the command line. This is frighteningly unstable software.
11-29-2018 12:22 AM
Further poking around leads me to believe that at least a part of the problem is related to improper handling of file and folder permissions by XSDK.
I tried two more approaches to following the digilent guide but varied where I put the folder that XSDK creates on its first launch for storing intermediate work. I first tried putting it under the same folder as where I was keeping my XSDK projects (no spaces or special symbols in path but it would crash on just about every action). After deleting .Xilinx, the created folders and starting again with the folder in the default selected location the number of crashes was reduced substantially though not eliminated.
From this observation I conclude that file and folder permissions aren't being handled properly as otherwise the location of the folder wouldn't have an impact. I have to imagine that some of the remaining crashes are due to file permission issues when the project folder is under the user folder in windows 10.