Xilinx firmware download problems

I've discovered an error in my post Making Xilinx ISE iMPACT 14.7 run on Ubuntu 20.04. I've corrected the error, and added a note explaining that a previous version contained an error.

So, what was the error?

I'm setting up ISE on a new Linux installation (Kubuntu 22.04.3 LTS), and I followed the instructions in the posts in this blog. When I tried to connect to my Digilent Spartan-3E Starter board, iMPACT reported it could not connect.

Looking at my syslog file I found the following error:

systemd-udevd[434471]: 3-2.1.1.2: Process '/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D /dev/bus/usb/003/011' failed with exit code 255.

Running fxload in a terminal window produced this output:

$ /sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D /dev/bus/usb/003/011
microcontroller type: fx2
single stage: load on-chip memory
open RAM hexfile image /usr/share/xusb_emb.hex
stop CPU
can't write 31 bytes external memory at 0x222e
unable to download /usr/share/xusb_emb.hex

Okay, this used to work! What did I do wrong?

After checking permissions and such, I compared the MD5 checksum of the file I'd copied to /usr/share with the one on a system that works. They were different, so I went looking for the source of the problem.

Xilinx ISE 14.7 supports quite a few different iMPACT compatible JTAG pods. Many of these are based on commodity USB interface chips that require firmware to be downloaded from the host. The ISE installation for Linux provides firmware files for seven of these chips.

Searching the ISE installation directory, I found nine directories containing files named "xusb_emb.hex". 

Each of these nine directories contains seven firmware files, one for each of the seven devices. Rather than there being one set of seven firmware files replicated nine times, there are three distinct sets of files: one set in four directories, a second set in another four directories, and a third set in one directory.

For the Digilent Spartan-3E Starter board, which uses the xusb_emb.hex file, the firmware from the first or second sets seem to work fine; the firmware from the remaining set fails to load.  

Not realizing this, it appears I referenced the wrong source directory when specifying the source of the firmware files. Copying the firmware files from one of the other directories results in a successful load and (as best I can tell) proper operation of the JTAG interface.

I hope this didn't cause too many people trouble. Mea culpa!