OpenOCD flashing failing with "Haven't made progress in mpsse_flush"

[Gbps]

Hey there,

I don't know if you've experienced this yet, but I had no problems flashing the board over JTAG prior to the issue happening now. I have the same setup, same programmer, same cord, etc. and the only thing that's changed is that I upgraded my motherboard/cpu on my main desktop which is doing the programming.

It appears that the device is resetting mid-programming. After a series of reboots and power cycles I did get it to program a few times, although now it's back to doing this and I haven't been able to get a successful reprogram.

Openocd is running in an ubuntu server 22.04 VM under VMWare workstation with the USB being passed through to the guest.

There's a lot of things that could be going wrong here, but hoping maybe someone has seen this before and figured out what was going on. It could just be I need to replace the cable or something to that effect.

Output from openocd:

Tue Feb 21 05:35:15 PM UTC 2023
Open On-Chip Debugger 0.12.0-rc1
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "jtag". To override use 'transport select <transport>'.
Info : clock speed 1000 kHz
Info : JTAG tap: xc7.tap tap/device found: 0x13636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x1)
Writing BSCAN_SPI bitstream...
Info : JTAG tap: xc7.tap tap/device found: 0x13636093 (mfg: 0x049 (Xilinx), part: 0x3636, ver: 0x1)
Info : Found flash device 'sp s25fl256s' (ID 0x190201)
Warn : 4-byte addresses needed, might need extra command to enable
Programming PCIe Chainloader bitstream to SPI...
Info : sector 0 took 1770 ms
Info : sector 1 took 1722 ms
Info : sector 2 took 112 ms
Info : sector 3 took 106 ms
Info : sector 4 took 108 ms
Info : sector 5 took 112 ms
Info : sector 6 took 106 ms
Info : sector 7 took 117 ms
Info : sector 8 took 107 ms
Info : sector 9 took 102 ms
Info : sector 10 took 111 ms
Info : sector 11 took 104 ms
Info : sector 12 took 105 ms
Info : sector 13 took 106 ms
Info : sector 14 took 107 ms
Info : sector 15 took 117 ms
Info : sector 16 took 116 ms
Info : sector 17 took 108 ms
Info : sector 18 took 110 ms
Info : sector 19 took 109 ms
Info : sector 20 took 107 ms
Info : sector 21 took 115 ms
Info : sector 22 took 106 ms
Info : sector 23 took 113 ms
Info : sector 24 took 110 ms
Info : sector 25 took 103 ms
Info : sector 26 took 111 ms
Info : sector 27 took 104 ms
Info : sector 28 took 113 ms
Info : sector 29 took 120 ms
Info : sector 30 took 105 ms
Info : sector 31 took 111 ms
Info : sector 32 took 111 ms
Info : sector 33 took 111 ms
Info : sector 34 took 107 ms
Info : sector 35 took 117 ms
Info : sector 36 took 117 ms
Info : sector 37 took 113 ms
Info : sector 38 took 110 ms
Info : sector 39 took 111 ms
Info : sector 40 took 106 ms
Info : sector 41 took 109 ms
Info : sector 42 took 111 ms
Info : sector 43 took 106 ms
Info : sector 44 took 104 ms
Info : sector 45 took 102 ms
Info : sector 46 took 104 ms
Info : sector 47 took 130 ms
Info : sector 48 took 114 ms
Info : sector 49 took 117 ms
Warn : Haven't made progress in mpsse_flush() for 2003ms.
Warn : Haven't made progress in mpsse_flush() for 4005ms.
Warn : Haven't made progress in mpsse_flush() for 8006ms.
Warn : Haven't made progress in mpsse_flush() for 16011ms.
Warn : Haven't made progress in mpsse_flush() for 32022ms.
Warn : Haven't made progress in mpsse_flush() for 64042ms.
Warn : Haven't made progress in mpsse_flush() for 128085ms.

The configuration file:

reset_config none

source [find interface/ftdi/digilent_jtag_hs3.cfg]
source [find cpld/xilinx-xc7.cfg]
source [find cpld/jtagspi.cfg]

adapter speed 1000

proc fpga_program {} {
        global _CHIPNAME
        xc7_program $_CHIPNAME.tap
}

init
echo "Writing BSCAN_SPI bitstream..."
jtagspi_init 0 bscan_spi_xc7a200t.bit
echo "Programming PCIe Chainloader bitstream to SPI..."
jtagspi_program pcie-chainloader-project0.bin 0x0
echo "Resetting device..."
fpga_program
echo "Done."
shutdown

And openocd version:

Open On-Chip Debugger 0.12.0-rc1
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html

[RHSResearchLLC]

Hello Gbps, I have never seen this issue. How do you know the Litefury is rebooting? Does the power or 'done' LED flicker? That error message implies the libusb function call isn't returning- which could be a lot of things, especially when using USB through a VM. That said I use a VM with USB all the time and don't usually have trouble.

[Gbps]

Hey thanks for the quick reply. I didn't note in the previous post, but this is a Nitefury 2 board. I don't actually know that it is resetting, to be honest, so that might be bad information and just an assumption. The power or done LEDs do not flicker.

As a last ditch effort, I just dug out a new microusb cable for my programmer and gave that a shot. So far, it has not failed programming yet. I did some scientific method and confirmed that the usb port, clock speed, power state, pcie slot, all of those things remained consistent but just swapping out the cord to the old cord caused this issue and the new cord did not have the issue.

I think it's safe enough to say that something happened to this microusb cord resulting in this. I doubt the tolerances on these Amazon cords are particularly good so I can imagine over time something has resulted in the cord causing libusb to disconnect.

Thank you for taking a look!