12-11-2015 03:30 AM
I am experiencing a problem with Vivado when trying to use the platform cables.
The error I am getting is
ERROR: [Labtoolstcl 44-494] There is no active target available for server at localhost. Targets(s) ", jsn-DLC10-000013e2227b01jsn-DLC9-Port_#0002.Hub_#0003" may be locked by another hw_server.
I did not have this problem with Vivado until a few days ago when it happened the first time.
I get this error on all my Vivado installations (2015.2 through 2015.4), I installed 2015.4 today to see if that would help but it did not.
I can use the adapters in Chipscope for ISE without any problems on the same computer.
I have tried reinstalling Jungo.
I have tried running cleancablelock under impact in ISE.
I have tried manually terminating the hw_server process.
Before you say it, yes I have turned it off and on again, the computer that is.
I am at a loss trying to get the Platform Cables to work and I need them to do some actual work.
12-11-2015 06:00 AM
@xpress Is Impact open on your machine? chipscope analyzer? If yes please close it and give a try.
12-11-2015 06:24 AM
After restarting, the first thing I do is to go in to the hardware manager and click "Open Target"->"Auto Connect".
I have restarted my computer several times and it still does it, there are no other applications open when I do this.
There is some Xilinx firmware loader that does something when I plug the Platform Cables in, but I assume that is still needed?
I have no way of turning the firmware loader off if it's not needed, I can't find a relevant process to kill.
12-11-2015 08:34 AM
@xpress What is the status of led on platform cable? It should be green If drivers are rightly installed.
12-11-2015 08:51 AM
That is an untrue statement.
The LED goes orange when drivers are installed.
The LED only goes green if a target voltage is applied.
This problem is not with the hardware, Vivado clearly states that it can find the Platform Cables but they are locked.
If I open Chipscope in ISE I can use the cables without problems so it would appear that they are not really locked.
On my cables the LEDs go orange if I leave them not plugged in to the target board.
If I plug them in to the target board and power it on, the LEDs go green.
12-12-2015 09:22 PM - edited 12-12-2015 09:24 PM
@xpress Intention was to make sure drivers are installed, Its not entirely incorrect, Without drivers you wouldnt have seen green led even if you are connected to machine.
Did you installed any other program recently? i have seen issue where other applications were blocking the drivers
Can you try with ISE impact? Chipscope analyzer is working so i expect impact should also work but can you give a try?
12-14-2015 01:33 AM
I have done some more investigating and I think I have found the problem.
I believe you get this error if there is no target voltage applied to the Platform Cable when doing an "Auto Connect" in Vivado.
The board I am using is quite complex and is turned on by software and I was trying to set Vivado up before turning the power supplies for the FPGA on. Apparantly this is not a valid thing to do with Vivado as it would seem to give you the locked error.
Also Vivado does not seem to play nicely when using Chipscope at the same time using a separate Platform Cable connected to a separate FPGA on the same computer, it crashes.
12-14-2015 04:47 AM
@xpress Glad to know.You have said in your previous post that status led on platfrom usb cable is green which indicates
• The cable is connected to a target system • The target system is powered • The voltage on the VREF pin is ≥ +1.5V
How long you have to wait once led is green to be able to detect by vivado? in case of FPGA power i have seen clear message from vivado, havent seen drivers are locked kind of message when fpga isnt power up.
12-14-2015 04:57 AM
I said "_If_ I plug them in to the target board and power it on, the LEDs go green."
I don't have the FPGA powered up when I try to open the Platform Cables in Vivado, I expect Vivado to open the Platform Cables anyway. Impact and Chipscope will correctly open the Platform Cables without the FPGA being powered up, Vivado does not.
What wasted a day of my time was the error message which to me looks more like a software or USB problem, if Vivado were to simply state that the target is not powered up I would have solved this straight away.
12-18-2017 12:05 PM - edited 12-18-2017 12:10 PM
I'm also getting this often with 2017.3. Didn't seem to happen with 2017.2. I'm running Windows 10 if that matters.
I say often because it doesn't happen every day or every hour. Sometimes it will find my hardware just fine, and then I'll do a build and try to download 3 minutes later and get this error. Very odd.
It is asking me to disconnect_hw_server and connect_hw_server, but this is new behavior and why should I have to do it anyway? Why can't the tool attempt it for me at least once?
01-18-2018 06:27 PM
i also often have this problems . version 2017.3 .every time i need reinstall the driver can solve this problem
03-02-2018 06:26 AM
Just installed Vivado 2017.4 on my Win 10 machine and I'm running into this exact same problem. Seeing as how this problem has been around since 2015, is there anything that can be improved here?
I'm completely dead in the water now.... :(
03-02-2018 09:15 AM
I get this too.
[Labtoolstcl 44-494] There is no active target available for server at localhost.
Targets(s) ", jsn-DLC10-00001631b65601jsn1" may be locked by another hw_server.
Even though this thread is years old, there is still no adequate answer. In my case, restarting the PC unlocks the server. But that is NOT AN ACCEPTABLE SOLUTION.
How can I unlock the target so I can use it? There is no other process open at this time. Is there a TCL command to delete all servers? Please give us a decent solution, Xilinx.
03-02-2018 08:05 PM - edited 03-02-2018 08:16 PM
Can someone tell me what the correct driver is for y DLC9G programmer on Windows 10? I executed the following script as administrator:
and saw that my drivers installed correctly:
windrvr6 is not installed.
INFO: Installing Windows 10 pcusb driver...
Microsoft PnP Utility
Processing inf : xpcwinusb.inf
Driver package added successfully.
Published name : oem13.inf
Total attempted: 1
Number successfully imported: 1
INFO: INF file c:\Xilinx\Vivado\2017.4\data\xicom\cable_drivers\nt64\dlc10_win10\xpcwinusb.inf was successfully installed for driver.
INFO: Running digilent installer...
<<<<< Digilent Adept Runtime Setup >>>>>
Installer version: 1.4.6 release: 2015/12/08
Digilent Software Path: C:\Program Files (x86)\Digilent
Your system is up-to-date with the components of this installer.
INFO: Running SmartLynq installer...
INFO: SmartLynq installed successfully
But when I go into the device manager and look at the driver being used it seems like some generic microsoft USB driver:
Is this correct?
Also I notice the directories are named dlc10_*. Does it matter that I have a DLC9G?
03-03-2018 10:32 AM - edited 03-03-2018 10:58 AM
Finally got my Win10 system to work again with the cable. I had to uninstall all versions of Xilinx software as well as the winusb.sys driver and revert back to Vivado 2017.2. Vivado 2017.2 is using the Jungo driver for Win10 (windrvr6.sys) which seems to work fine with my cable.
Looking through the Vivado 2017.4 driver install script it does look like it tries to determine just what verision of windows 10 you have. In my case though, it made a bad call and tries to use the winusb driver which didn't work. In hind sight I prob could have hacked the script becausr 2017.4 does come with the Jungo driver as well but I didn't have that information at the time.
I'm seriously considering switching over to a Digilent cable instead of using the Xilinx one. Something tells me it's prob a more stable solution...
07-11-2018 08:09 PM
12-11-2018 02:14 PM
My nightmare at every update. I find there is no need to go back to 2017.2 (that would be reason enough to move to Altera/ Intel and let them die and disappear in peace...), release 2018.2 has the windrv6.sys driver installer in:
Just open a command prompt with admin rights, then run install_drivers. One can previously run check_windrv6 to see if it's there or not.