DLC10 JTAG probe keeps crashing

[bhig]

Hi All,

I'm having a frustrating issue getting the Platform Cable USB II to work reliably. I currently have it plugged into a Windows 7 machine running which has Vivado and SDK 2017.2 installed.  This machine is in a lab that I connect remotely to a hw_server running on it from SDK.

Multiple times a day, sometimes as often as every couple minutes, the JTAG connection seems to completely crash and I have to walk over to the lab, unplug the cable, and plug it back in.  SDK always reports that it could not find an ARM device.

Here's the log output from the SDK:

15:20:07 DEBUG : XSCT Command: [connect -path [list tcp::1534 tcp:hostname:3122]], Thread: Worker-31
15:20:08 DEBUG : XSCT command with result: [connect -path [list tcp::1534 tcp:hostname:3122]], Result: [null, tcfchan#4]. Thread: Worker-31
15:20:08 INFO : Connected through redirection to target on host 'hostname' and port '3122'.
15:20:08 DEBUG : XSCT Command: [jtag targets -filter {level == 0}], Thread: Worker-31
15:20:08 DEBUG : XSCT command with result: [jtag targets -filter {level == 0}], Result: [null, 1 Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)]. Thread: Worker-31
15:20:08 DEBUG : XSCT Command: [version -server], Thread: Worker-31
15:20:08 DEBUG : XSCT command with result: [version -server], Result: [null, 2017.2]. Thread: Worker-31
15:20:08 DEBUG : XSCT Command: [version], Thread: Worker-31
15:20:08 DEBUG : XSCT command with result: [version], Result: [null, 2017.2]. Thread: Worker-31
15:20:08 DEBUG : XSCT Command: [jtag targets -filter {level == 0}], Thread: Worker-31
15:20:08 DEBUG : XSCT command with result: [jtag targets -filter {level == 0}], Result: [null, 1 Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)]. Thread: Worker-31
15:20:08 DEBUG : XSCT Command: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Thread: Worker-31
15:20:11 DEBUG : XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Result: [null, ]. Thread: Worker-31
15:20:11 DEBUG : Retrying again to get the devices list for cable 'Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)'.
15:20:14 DEBUG : XSCT Command: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Thread: Worker-31
15:20:17 DEBUG : XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Result: [null, ]. Thread: Worker-31
15:20:17 DEBUG : Following devices found for target "lab X1 0001": []
15:20:17 DEBUG : Could not find ARM device on the board for connection 'lab X1 0001'.
Check if the target is in:
1. Split JTAG - No operations are possible with ARM DAP.
2. Non JTAG bootmode - Bootrom may need time to enable DAP.
Please try again.


Troubleshooting hints:
1. Check whether board is connected to system properly.
1. In case of zynq board, check whether Digilent/Xilinx cable switch settings are correct.
1. If you are using Xilinx Platform Cable USB, ensure that status LED is green.
java.lang.RuntimeException: Could not find ARM device on the board for connection 'lab X1 0001'.
Check if the target is in:
1. Split JTAG - No operations are possible with ARM DAP.
2. Non JTAG bootmode - Bootrom may need time to enable DAP.
Please try again.


Troubleshooting hints:
1. Check whether board is connected to system properly.
1. In case of zynq board, check whether Digilent/Xilinx cable switch settings are correct.

I've double checked that the windrv6.sys in system32\drivers\ is identical to the copy in sdk\data\xicom\cable_drivers. Windows reports the Jungo driver is version 10.2.1.0 dated 8/31/2010 and the Xilinx USB Cable driver is v2.0.0.3 dated 10/26/2007.  I've tried rebooting, uninstalling and reinstalling the drivers.

When I unplug and replug the DLC10 it sometimes will work reliably for a couple hours or even a day or two, but sometimes it won't work immediately and I have to go reset it again.

I normally am launching the hw_server like:

C:\Xilinx\SDK\2017.2\bin\hw_server.bat -stcp::3122 -e "set jtag-port-filter "Xilinx/DLC10/000019bb711901""

although I added a -L<file> and -l0xFC000 to generate a log.

Here's the output from the hw_server logging from where the error first starts.

TCF 20:06:43.247: JTAG: error: Cannot flush JTAG server queue. libusb_bulk_transfer(0x86) resulted in error unknown error
TCF 20:07:13.249: JTAG: clear command sequence
TCF 20:07:13.249: JTAG: shift IR: 0x0a DPACC
TCF 20:07:13.249: JTAG: shift DR: wr DPR SELECT 01000000
TCF 20:07:13.249: JTAG: shift IR: 0x0b APACC
TCF 20:07:13.249: JTAG: shift DR: wr APB MEM_TAR 80090fa4
TCF 20:07:13.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:13.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:13.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:13.249: JTAG: shift DR: wr APB MEM_TAR 80090314
TCF 20:07:13.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:13.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:13.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:13.249: JTAG: shift DR: wr APB MEM_TAR 80090088
TCF 20:07:13.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:13.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:13.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:13.249: JTAG: shift DR: wr APB MEM_TAR 80090028
TCF 20:07:13.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:13.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:13.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:13.249: JTAG: shift IR: 0x0a DPACC
TCF 20:07:13.249: JTAG: shift DR: rd DPR CTRL_STAT
TCF 20:07:13.249: JTAG: shift DR: rd DPR RDBUFF
TCF 20:07:13.249: JTAG: run command sequence
TCF 20:07:15.249: JTAG: error: Cannot flush JTAG server queue. libusb_control_transfer(stream in/out) resulted in error timeout
TCF 20:07:17.249: JTAG: clear command sequence
TCF 20:07:17.249: JTAG: shift IR: 0x0a DPACC
TCF 20:07:17.249: JTAG: shift DR: wr DPR SELECT 01000000
TCF 20:07:17.249: JTAG: shift IR: 0x0b APACC
TCF 20:07:17.249: JTAG: shift DR: wr APB MEM_TAR 80092fa4
TCF 20:07:17.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:17.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:17.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:17.249: JTAG: shift DR: wr APB MEM_TAR 80092314
TCF 20:07:17.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:17.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:17.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:17.249: JTAG: shift DR: wr APB MEM_TAR 80092088
TCF 20:07:17.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:17.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:17.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:17.249: JTAG: shift DR: wr APB MEM_TAR 80092028
TCF 20:07:17.249: JTAG: add state change: IDLE, 405 clocks
TCF 20:07:17.249: JTAG: shift DR: rd APB MEM_DRW
TCF 20:07:17.249: JTAG: add state change: IDLE, 1418 clocks
TCF 20:07:17.249: JTAG: shift IR: 0x0a DPACC
TCF 20:07:17.249: JTAG: shift DR: rd DPR CTRL_STAT
TCF 20:07:17.249: JTAG: shift DR: rd DPR RDBUFF
TCF 20:07:17.249: JTAG: run command sequence
...
TCF 20:07:33.249: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:33.249: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/jtag/context-jtag.c:2375
TCF 20:07:33.249: JTAG: clear command sequence
TCF 20:07:33.249: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:33.249: JTAG-MDM:  tdi (IR): all ones
TCF 20:07:33.249: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:33.249: JTAG-MDM:  tdi (IR): 000011
TCF 20:07:33.249: JTAG-MDM: shift DR, 32 bits, end state IDLE
TCF 20:07:33.249: JTAG-MDM:  tdi (...): all zeros
TCF 20:07:33.249: JTAG: run command sequence
TCF 20:07:35.249: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:35.306: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/services/jtagpoll.c:76
TCF 20:07:35.306: jtagpoll: change node 00000000038E2CA0(jsn-DLC10-000019bb711901), active (port 1/0 node 1)
TCF 20:07:35.306: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:35.306: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/xicom/src/xsdbslave.c:588
TCF 20:07:37.306: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:37.306: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/jtag/context-jtag.c:2375
TCF 20:07:37.306: JTAG: clear command sequence
TCF 20:07:37.306: JTAG: shift IR: 0x08 ABORT
TCF 20:07:37.306: JTAG: shift DR: wr DPR 0 00000001
TCF 20:07:37.306: JTAG: shift IR: 0x0a DPACC
TCF 20:07:37.306: JTAG: shift DR: wr DPR CTRL_STAT 50000033
TCF 20:07:37.306: JTAG: run command sequence
TCF 20:07:39.306: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:39.306: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/jtag/context-jtag.c:2375
TCF 20:07:39.306: JTAG: clear command sequence
TCF 20:07:39.306: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:39.306: JTAG-MDM:  tdi (IR): all ones
TCF 20:07:39.306: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:39.306: JTAG-MDM:  tdi (IR): 000011
TCF 20:07:39.306: JTAG-MDM: shift DR, 32 bits, end state IDLE
TCF 20:07:39.306: JTAG-MDM:  tdi (...): all zeros
TCF 20:07:39.306: JTAG: run command sequence
TCF 20:07:41.307: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:41.358: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/services/jtagpoll.c:76
TCF 20:07:41.358: jtagpoll: change node 00000000038E2CA0(jsn-DLC10-000019bb711901), active (port 1/0 node 1)
TCF 20:07:41.358: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:41.358: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/xicom/src/xsdbslave.c:588
TCF 20:07:43.358: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:43.358: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/jtag/context-jtag.c:2375
TCF 20:07:43.358: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:43.358: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/jtag/context-jtag.c:2375
TCF 20:07:43.358: JTAG: clear command sequence
TCF 20:07:43.358: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:43.358: JTAG-MDM:  tdi (IR): all ones
TCF 20:07:43.358: JTAG-MDM: shift IR, 6 bits, end state IDLE
TCF 20:07:43.358: JTAG-MDM:  tdi (IR): 000011
TCF 20:07:43.358: JTAG-MDM: shift DR, 32 bits, end state IDLE
TCF 20:07:43.358: JTAG-MDM:  tdi (...): all zeros
TCF 20:07:43.358: JTAG: run command sequence
TCF 20:07:45.358: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:45.414: jtaglock: lock jsn-DLC10-000019bb711901 from r:/builds/2017.2/continuous/2017_06_13_1907801/src/ext/xicom/tcf/libs/hw_server/tcf-zynq/tcf/services/jtagpoll.c:76
TCF 20:07:45.414: jtagpoll: change node 00000000038E2CA0(jsn-DLC10-000019bb711901), active (port 1/0 node 1)
TCF 20:07:45.414: jtagpoll: change node 00000000038F1170(jsn-DLC10-000019bb711901-4ba00477-0), active (port 1/0 node 0)
TCF 20:07:45.414: jtagpoll: change node 00000000038F13C0(jsn-DLC10-000019bb711901-23731093-0), active (port 1/0 node 0)
TCF 20:07:45.414: jtagpoll: change node 00000000038E2CA0(jsn-DLC10-000019bb711901), active (port 1/0 node 0)
TCF 20:07:51.414: jtaglock: unlock jsn-DLC10-000019bb711901
TCF 20:07:55.900: jtagpoll: cannot open port Xilinx/000019bb711901: set pins failed: timeout
TCF 20:08:00.392: jtagpoll: cannot open port Xilinx/000019bb711901: set pins failed: timeout
TCF 20:08:04.890: jtagpoll: change node 000000000038AC90(jsn3), active (port 0/1 node 0)
TCF 20:08:04.890: jtagpoll: change node 00000000038E2CA0(jsn-DLC10-000019bb711901), active (port 0/0 node 0)
TCF 20:08:09.380: jtagpoll: change node 000000000038AC90(jsn3), active (port 1/0 node 0)

Does anyone have any other ideas?

Thanks!

[austin]

Does it work locally not using hw_server?

Check this is not a network issue with your IT?

[bhig]

It happens when using SDK on the same machine that the hw_server is running on when still connecting to it as if it is a remote server, ie: using the machine's hostname, even though in this case the "remote host" is the same as the machine that the SDK debugger is running on.

We haven't noticed it when changing SDK to be a "local" connection and letting it take care of launching the hw_server internally.

This morning I rebooted and reset everything on our remote server and so far it seems more stable.  But like I said in my original post, sometimes we'll not have an issue for days and sometimes it seems like every few minutes the hw_server's communication with the JTAG probe will crash and give us the timeout error.

16:42:49 DEBUG	: XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Result: [null, ]. Thread: Worker-59
16:42:49 DEBUG	: Retrying again to get the devices list for cable 'Xilinx cable Port_#0005.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)'.

Something else that I've noticed; when its not working well, it seems to die very quickly if I'm not actively stepping through the code. When the code hits a breakpoint or I leave it paused at a line for a few minutes, when I switch back to the SDK window the connection has crashed and all my targets (APU->Cortex A9 #0 and #1, and the FPGA xc7z045) have disappeared from the target list in the "Debug" view window under my active connection.

[austin]

Are all your tools the same revision?  All 2017.2, for example?

[bhig]

Yes, we're using the tools from 2017.2 on both sides, although we do have multiple versions of the tools installed on each machine. 2015.4 and 2016.4 are also installed on my machine and 2017.1 is also installed on the server.

[austin]

b,

"Well, there's your problem" ....

All tools must match.  It might be some of the older tools are being accessed.  I would remove all older versions.  Lastly, did you check with your IT people about the use of your internet/intranet?  Do they have malware/anti-virus firewalls or screens that block this traffic?

[bhig]

Thanks, I'll try uninstalling all the older versions temporarily and see if the issues go away, if for some reason even though I only am launching the tools from the 2017.2 folders other versions are being used.

They said they didn't have anything actively blocking intranet traffic.

[austin]

OK,

Good IT is saying they are not blocking anything.  Let us know if uninstalling old tools helps.

[bhig]

So I uninstalled all other versions of SDK & Vivado from both machines and the issue still occurs.  Today it crashed when I was actually in the middle of trying to execute a suspend operation and SDK popped up the attached error.

I also saw this displayed in the SDK Log which I thought was odd since I'm not running linux on either platform:

15:01:01 DEBUG	: Updating check state for linux os awareness action Id=com.xilinx.sdk.tcf.debug.ui.linuxosawarestate.

[bhig]

Today I got fed up with it and copied all my source to the remote machine to eliminate any potential network issues and it still happened when I connected to the board using a "Local" connection.  Unplugged and re-plugged in the usb cable and it works again, for a few minutes.

16:26:59 DEBUG	: Executing cmd 'jtag ta' in interactive mode.
16:26:59 DEBUG	: (XSDB Server)  4  Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)
xsct% 
16:27:10 DEBUG	: Disconnect callback received on 'jas local'
16:27:10 DEBUG	: Disconnect called on launch 'jas local'
16:27:10 DEBUG	: XSCT Command: [disconnect tcfchan#1], Thread: Thread-97
16:27:10 DEBUG	: XSCT command with result: [disconnect tcfchan#1], Result: [null, ]. Thread: Thread-97
16:27:10 DEBUG	: (XSDB Server)Info: tcfchan#1 closed

16:27:10 INFO	: Disconnected from the channel tcfchan#1.
16:27:13 DEBUG	: XSCT Command: [connect -url tcp:127.0.0.1:3121], Thread: Worker-7
16:27:13 DEBUG	: XSCT command with result: [connect -url tcp:127.0.0.1:3121], Result: [null, tcfchan#2]. Thread: Worker-7
16:27:13 INFO	: Connected to target on host '127.0.0.1' and port '3121'.
16:27:13 DEBUG	: XSCT Command: [jtag targets -filter {level == 0}], Thread: Worker-7
16:27:13 DEBUG	: XSCT command with result: [jtag targets -filter {level == 0}], Result: [null,   1  Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)]. Thread: Worker-7
16:27:13 DEBUG	: XSCT Command: [version -server], Thread: Worker-7
16:27:13 DEBUG	: XSCT command with result: [version -server], Result: [null, 2017.2]. Thread: Worker-7
16:27:13 DEBUG	: XSCT Command: [version], Thread: Worker-7
16:27:13 DEBUG	: XSCT command with result: [version], Result: [null, 2017.2]. Thread: Worker-7
16:27:13 DEBUG	: XSCT Command: [jtag targets -filter {level == 0}], Thread: Worker-7
16:27:13 DEBUG	: XSCT command with result: [jtag targets -filter {level == 0}], Result: [null,   1  Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)]. Thread: Worker-7
16:27:13 DEBUG	: XSCT Command: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Thread: Worker-7
16:27:16 DEBUG	: XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Result: [null, ]. Thread: Worker-7
16:27:16 DEBUG	: Retrying again to get the devices list for cable 'Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)'.
16:27:19 DEBUG	: XSCT Command: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Thread: Worker-7
16:27:23 DEBUG	: XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Xilinx cable Port_#0003.Hub_#0003 (error: query cable type failed: timeout: cable may be hung, try to disconnect and reconnect closed)" && level==1}], Result: [null, ]. Thread: Worker-7
16:27:23 DEBUG	: Following devices found for target "Local": []
16:27:23 INFO	: ----------------XSDB Script----------------
connect -url tcp:127.0.0.1:3121
----------------End of Script----------------

16:27:23 DEBUG	: Could not find ARM device on the board for connection 'Local'.

[bhig]

Another interesting data point I tested today with a coworker, he is testing just FPGA related work so is using C:\Xilinx\SDK\2017.2\bin\xsct.bat directly from the command line to perform his debugging. He has no issues, can leave it for hours while connected then go back to it and can still communicate with the jtag interface.

When he was using SDK to download images and perform basic mrd/mwr for his testing he would also encounter the jtag port timing out, both locally and through the network.

So it seems like the issue is focused more on how the SDK interacts with the hw_server independent of if it connects locally or remotely.

[bhig]

I sometimes see this error the first time it fails, followed by the timeout message:

16:48:47 DEBUG	: XSCT command with result: [jtag targets -filter {jtag_cable_name =~ "Platform Cable USB II 000019bb711901 (error get pins failed: timeout)" && level==1}], Result: [null, ]. Thread: Worker-9
16:48:47 DEBUG	: Retrying again to get the devices list for cable 'Platform Cable USB II 000019bb711901 (error get pins failed: timeout)'.

[bhig · Accepted solution]

Sigh, I don't know why I didn't try this first but I updated all the problem machine's BIOS, drivers, etc and so far have not had the USB connection to the programmer timeout and crash once today.