Cannot Detect XUP-USB-JTAG Programmer from Vitis 2022.1 on Linux

[gschmott]

I recently purchased a Digilent XUP-USB-JTAG (Rev G) programmer to use with Xilinx Vitis Rel 2022.1 so I can single-step and debug a Zynq-7000 custom board. My installation is on Linux (Ubuntu 18.04) and I ran the cable driver installer that comes with Vitis that installs the necessary udev rules for this device. I reloaded the udev rules via:

$ sudo udevadm control --reload-rules
$ sudo udevadm trigger

The 'lsusb' program detects the device:

$ lsusb
Bus 005 Device 070: ID 03fd:000d Xilinx, Inc.

So the rules defined in '52-xilinx-pcusb.rules' run when the device is inserted.

The following link indicates that there is an "extra" command that needs to be run when the device is inserted to load the USB device with firmware:

https://forum.digilent.com/topic/13275-xup-usb-jtag-programmer/#comment-40008

Specifically 'xusb_emb.hex' for my product ID:

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $TEMPNODE"

The program that loads the device is 'fxload' which is a Cypress Semiconductor utility used with their EZUSB FX/FX2 chips. The hex file 'usb_emb.hex' is provided with the Vitis release in the following installation directory

Vitis/2022.1/data/xicom/xusb_emb.hex

Unfortunately, the Rev. G of the XUP-USB-JTAG programmer uses the FX3 chipset which is incompatible with the FX2 firmware (my version of fxload won't even load it). As I understand it, the FX3 binaries are in a proprietary format that differs from the older "hex" files. When I run Vitis and try to attach to my target the XUP is not detected.

So my questions become:

* How do I get my XUP-USB-JTAG programmer to work in Vitis under Linux?
* Where do I get the updated FX3 compatible firmware which (apparently) Vitis needs in order to recognize the programmer?
* Has anyone managed to get this device working with Linux?
* If it's not supported with Vitis on Linux, which low-cost Diligent device would and allow me to use it in Vitis for JTAG application development?

Edited May 19, 2022 by JColvin
made the post visible rather than a in a file

[JColvin]

Hi @gschmott,

The XUP USB JTAG programmers in the thread you referenced would have also been the Rev G since as far as I understand this module has not been updated in many years, so it should still be using FX2 as far as I know. The specific instructions you linked were from my post, but did you also get a chance to try the more Linux specific instructions later on in the thread (specifically this post, https://forum.digilent.com/topic/13275-xup-usb-jtag-programmer/#comment-43305)?

It does look there was a comment later on that the .hex files that Xilinx provided with Vivado were not working properly and that they had to use a .hex file from their old ISE installation, though that file didn't get posted for easy reference (and I don't know how far back you would have to go in Xilinx installations to get a working file).

If the above instructions are not helping you resolve the issue, I would recommend using the JTAG HS3 (https://digilent.com/reference/programmers/jtag-hs3/start) which includes the PS_SRST_B pin so that the Zynq core can be reset as needed during debug operations. It also uses the 2x7 Xilinx header much like other Xilinx programmers.

Let me know if you have any questions.

Thanks,
JColvin

 

[gschmott]

Hi @JColvin -

Followed your specific post and have tried to *manually* program the XUP firmware directly using 'fxload'. Here is the device as it appears on my Ubuntu 18.04 system:

$ lsusb
Bus 005 Device 063: ID 03fd:000d Xilinx, Inc.

So it appears on Bus 005 as Device 063. This device maps to the following path on my machine:

/dev/bus/usb/005/063

The vendor ID is 03fd and the product ID is 000d. According to the previous posting there was a recommendation to add additional rules to '52-xilinx-pcusb.rules' such as

BUS=="usb", ACTION=="add", SYSFS{idVendor}=="03fd", SYSFS{idProduct}=="000d", RUN+="/sbin/fxload -v -t fx2 -I /usr/share/xusb_emb.hex -D $TEMPNODE"

The XUP Rev. G debugger matches product ID = 000d. So I should be able to load the xusb_emb.hex file directly using 'fxload'. Attempting this gives:

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

This lead me to believe the EZUSB chip was not an FX2 compatible controller. I then tried the 'fx2lp' type

$ fxload -v  -t fx2lp -I /opt/xilinx/share/xicom/data/xusb_emb.hex -D /dev/bus/usb/005/063
microcontroller type: fx2lp
single stage:  load on-chip memory
open RAM hexfile image /opt/xilinx/share/xicom/data/xusb_emb.hex
stop CPU
write on-chip, addr 0x222e len   31 (0x001f)
write on-chip, addr 0x0b93 len    3 (0x0003)
write on-chip, addr 0x1dd0 len   70 (0x0046)
write on-chip, addr 0x2309 len   20 (0x0014)
write on-chip, addr 0x2389 len   13 (0x000d)
write on-chip, addr 0x231d len   20 (0x0014)
write on-chip, addr 0x23d0 len    5 (0x0005)
write on-chip, addr 0x0178 len 1008 (0x03f0)
write on-chip, addr 0x0568 len  418 (0x01a2)
write on-chip, addr 0x23a1 len   10 (0x000a)
write on-chip, addr 0x0b96 len    8 (0x0008)
write on-chip, addr 0x1928 len  133 (0x0085)
write on-chip, addr 0x21ec len   33 (0x0021)
write on-chip, addr 0x2159 len   40 (0x0028)
write on-chip, addr 0x1000 len  536 (0x0218)
write on-chip, addr 0x0b9e len   15 (0x000f)
write on-chip, addr 0x1800 len  156 (0x009c)
write on-chip, addr 0x1b7e len   97 (0x0061)
write on-chip, addr 0x1c3c len   90 (0x005a)
write on-chip, addr 0x229c len   22 (0x0016)
write on-chip, addr 0x1f3f len   52 (0x0034)
write on-chip, addr 0x1aa8 len  108 (0x006c)
write on-chip, addr 0x15fc len    4 (0x0004)
write on-chip, addr 0x23ab len    9 (0x0009)
write on-chip, addr 0x1f73 len   48 (0x0030)
write on-chip, addr 0x16b8 len  326 (0x0146)
write on-chip, addr 0x22b2 len   22 (0x0016)
write on-chip, addr 0x0e88 len  308 (0x0134)
write on-chip, addr 0x20b2 len   43 (0x002b)
write on-chip, addr 0x220d len   33 (0x0021)
write on-chip, addr 0x2107 len   41 (0x0029)
write on-chip, addr 0x0bad len   23 (0x0017)
write on-chip, addr 0x1b14 len  106 (0x006a)
write on-chip, addr 0x23c4 len    6 (0x0006)
write on-chip, addr 0x22f4 len   21 (0x0015)
write on-chip, addr 0x1d3e len   73 (0x0049)
write on-chip, addr 0x2331 len   20 (0x0014)
write on-chip, addr 0x202e len   44 (0x002c)
write on-chip, addr 0x2000 len   46 (0x002e)
write on-chip, addr 0x14ba len  224 (0x00e0)
write on-chip, addr 0x13d4 len  230 (0x00e6)
write on-chip, addr 0x23d9 len    3 (0x0003)
write on-chip, addr 0x0bc4 len    4 (0x0004)
write on-chip, addr 0x1c96 len   87 (0x0057)
write on-chip, addr 0x2130 len   41 (0x0029)
write on-chip, addr 0x236d len   14 (0x000e)
write on-chip, addr 0x20dd len   42 (0x002a)
write on-chip, addr 0x1d87 len   73 (0x0049)
write on-chip, addr 0x1e99 len   56 (0x0038)
write on-chip, addr 0x23b4 len    8 (0x0008)
write on-chip, addr 0x23ca len    6 (0x0006)
write on-chip, addr 0x0080 len   16 (0x0010)
write on-chip, addr 0x19ad len   12 (0x000c)
write on-chip, addr 0x2396 len   11 (0x000b)
write on-chip, addr 0x23bc len    8 (0x0008)
write on-chip, addr 0x1fd3 len   45 (0x002d)
write on-chip, addr 0x21a6 len   36 (0x0024)
write on-chip, addr 0x2284 len   24 (0x0018)
write on-chip, addr 0x22c8 len   44 (0x002c)
write on-chip, addr 0x1ed1 len  110 (0x006e)
write on-chip, addr 0x17fe len    2 (0x0002)
write on-chip, addr 0x23dc len   33 (0x0021)
write on-chip, addr 0x1fa3 len   48 (0x0030)
write on-chip, addr 0x0bc8 len    5 (0x0005)
write on-chip, addr 0x000b len    3 (0x0003)
write on-chip, addr 0x1a34 len  116 (0x0074)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x23d5 len    4 (0x0004)
write on-chip, addr 0x1bdf len   93 (0x005d)
write on-chip, addr 0x2345 len   20 (0x0014)
write on-chip, addr 0x237b len   14 (0x000e)
write on-chip, addr 0x224d len   55 (0x0037)
write on-chip, addr 0x159a len   98 (0x0062)
write on-chip, addr 0x1e5c len   61 (0x003d)
write on-chip, addr 0x1218 len  444 (0x01bc)
write on-chip, addr 0x19bb len  121 (0x0079)
write on-chip, addr 0x1ced len   81 (0x0051)
write on-chip, addr 0x0bcd len  698 (0x02ba)
write on-chip, addr 0x2359 len   20 (0x0014)
write on-chip, addr 0x21ca len   34 (0x0022)
write on-chip, addr 0x0090 len  232 (0x00e8)
write on-chip, addr 0x205a len   44 (0x002c)
write on-chip, addr 0x2181 len   20 (0x0014)
write on-chip, addr 0x1e16 len   70 (0x0046)
write on-chip, addr 0x2086 len   44 (0x002c)
write on-chip, addr 0x2195 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x1600 len  184 (0x00b8)
write on-chip, addr 0x19b9 len    2 (0x0002)
write on-chip, addr 0x070a len  453 (0x01c5)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x189c len   12 (0x000c)
write on-chip, addr 0x08cf len  337 (0x0151)
write on-chip, addr 0x0fbc len   68 (0x0044)
write on-chip, addr 0x0a20 len  292 (0x0124)
write on-chip, addr 0x18a8 len  128 (0x0080)
write on-chip, addr 0x0e87 len    1 (0x0001)
write on-chip, addr 0x0b44 len   79 (0x004f)
... WROTE: 9100 bytes, 99 segments, avg 91
reset CPU

This appears it might work. Unfortunately, after running Vivado's Hardware Manager or Vitis (Rel. 2022.1) it still does *NOT* detect the target. This lead me to think that perhaps the hex file is not the correct one. I then tried the 'xusb_xup.hex' file since 'xup' might indicate Xilinx Univerity Programmer??? With this hex file, I can use the 'fx2' mode of 'fxload'.

$ fxload -v  -t fx2 -I /opt/xilinx/share/xicom/data/xusb_xup.hex -D /dev/bus/usb/005/063
microcontroller type: fx2
single stage:  load on-chip memory
open RAM hexfile image /opt/xilinx/share/xicom/data/xusb_xup.hex
stop CPU
write on-chip, addr 0x10e0 len   31 (0x001f)
write on-chip, addr 0x067c len    3 (0x0003)
write on-chip, addr 0x1712 len   70 (0x0046)
write on-chip, addr 0x1b4e len   20 (0x0014)
write on-chip, addr 0x1bac len   13 (0x000d)
write on-chip, addr 0x1b62 len   20 (0x0014)
write on-chip, addr 0x1bed len    5 (0x0005)
write on-chip, addr 0x0178 len 1008 (0x03f0)
write on-chip, addr 0x0568 len  276 (0x0114)
write on-chip, addr 0x19af len   10 (0x000a)
write on-chip, addr 0x067f len    8 (0x0008)
write on-chip, addr 0x137d len  133 (0x0085)
write on-chip, addr 0x1a9d len   33 (0x0021)
write on-chip, addr 0x19e4 len   40 (0x0028)
write on-chip, addr 0x0971 len  536 (0x0218)
write on-chip, addr 0x0687 len   15 (0x000f)
write on-chip, addr 0x1255 len  156 (0x009c)
write on-chip, addr 0x1a0c len   38 (0x0026)
write on-chip, addr 0x153d len   90 (0x005a)
write on-chip, addr 0x1af7 len   22 (0x0016)
write on-chip, addr 0x186e len   52 (0x0034)
write on-chip, addr 0x14e0 len   93 (0x005d)
write on-chip, addr 0x1bf2 len    4 (0x0004)
write on-chip, addr 0x1bd0 len    9 (0x0009)
write on-chip, addr 0x16cb len   71 (0x0047)
write on-chip, addr 0x0f4f len  169 (0x00a9)
write on-chip, addr 0x11b8 len  157 (0x009d)
write on-chip, addr 0x15ee len   75 (0x004b)
write on-chip, addr 0x0d35 len  308 (0x0134)
write on-chip, addr 0x1984 len   43 (0x002b)
write on-chip, addr 0x1abe len   33 (0x0021)
write on-chip, addr 0x0696 len   23 (0x0017)
write on-chip, addr 0x1476 len  106 (0x006a)
write on-chip, addr 0x1be1 len    6 (0x0006)
write on-chip, addr 0x1b39 len   21 (0x0015)
write on-chip, addr 0x1639 len   73 (0x0049)
write on-chip, addr 0x1b76 len   20 (0x0014)
write on-chip, addr 0x1900 len   44 (0x002c)
write on-chip, addr 0x18d2 len   46 (0x002e)
write on-chip, addr 0x1000 len  224 (0x00e0)
write on-chip, addr 0x0e69 len  230 (0x00e6)
write on-chip, addr 0x1bfa len    3 (0x0003)
write on-chip, addr 0x06ad len    4 (0x0004)
write on-chip, addr 0x1597 len   87 (0x0057)
write on-chip, addr 0x19bb len   41 (0x0029)
write on-chip, addr 0x1b9e len   14 (0x000e)
write on-chip, addr 0x17d6 len   42 (0x002a)
write on-chip, addr 0x1682 len   73 (0x0049)
write on-chip, addr 0x179e len   56 (0x0038)
write on-chip, addr 0x0ff8 len    8 (0x0008)
write on-chip, addr 0x1be7 len    6 (0x0006)
write on-chip, addr 0x0080 len   16 (0x0010)
write on-chip, addr 0x1bb9 len   23 (0x0017)
write on-chip, addr 0x1bd9 len    8 (0x0008)
write on-chip, addr 0x1a57 len   36 (0x0024)
write on-chip, addr 0x1adf len   24 (0x0018)
write on-chip, addr 0x1b0d len   44 (0x002c)
write on-chip, addr 0x1800 len  110 (0x006e)
write on-chip, addr 0x10ff len    1 (0x0001)
write on-chip, addr 0x1bfd len   34 (0x0022)
write on-chip, addr 0x18a2 len   48 (0x0030)
write on-chip, addr 0x06b1 len    5 (0x0005)
write on-chip, addr 0x000b len    3 (0x0003)
write on-chip, addr 0x1402 len  116 (0x0074)
write on-chip, addr 0x0033 len    3 (0x0003)
write on-chip, addr 0x1bf6 len    4 (0x0004)
write on-chip, addr 0x06b6 len  698 (0x02ba)
write on-chip, addr 0x1b8a len   20 (0x0014)
write on-chip, addr 0x1a7b len   34 (0x0022)
write on-chip, addr 0x0090 len  232 (0x00e8)
write on-chip, addr 0x192c len   44 (0x002c)
write on-chip, addr 0x1a32 len   20 (0x0014)
write on-chip, addr 0x1758 len   70 (0x0046)
write on-chip, addr 0x1958 len   44 (0x002c)
write on-chip, addr 0x1a46 len   17 (0x0011)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0053 len    3 (0x0003)
write on-chip, addr 0x1100 len  184 (0x00b8)
write on-chip, addr 0x19b9 len    2 (0x0002)
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x12f1 len   12 (0x000c)
write on-chip, addr 0x0b89 len  349 (0x015d)
write on-chip, addr 0x12fd len  128 (0x0080)
write on-chip, addr 0x0970 len    1 (0x0001)
write on-chip, addr 0x0ce6 len   79 (0x004f)
... WROTE: 7086 bytes, 85 segments, avg 83
reset CPU

Again, I fired up Vivado's Hardware Manager and it still does *NOT* detect the target.

So, Digilent, as the manufacturer and disributor of the XUP-USB JTAG programmer, I have these questions:

1) What EZ-USB chip is inside the Rev. G module (FX2, FX2lp, FX3)? What '-t' option should I be using with fxload?

2) Who developed these hex files? Who truly knows which hex file goes with which product ID?

3) Why aren't these hex files mentioned in either the Xilinx Vitis/Vivado Linux cable driver installation documentation or by Digilent? The standard udev rules do not include the action to run 'fxload'.

4) Digilent advertises this product works with Linux yet it does not appear from the forum posts that Digilent has actually tested this product on a *native* x86-64 Linux platform, is this correct?

5) Is Digilent willing to try (and verify) that this product works with Linux (not inside a Linux VM running on Windows)? Can your developers recreate my situation or does it work fine for them?

I am willing to help trouble-shoot this issue but I don't know the next step I should take. I am open to recommendations since I don't want to necessarily write-off the XUP-USB JTAG programmer as broken under Linux (my primary development environment).

Thanks for your help,

Glenn

Edited May 25, 2022 by gschmott
Converted reply in text file to in-line post.

[gschmott]

I found a work-around and have described the solution here. Linux support for the XUP is definitely broken and a work-around requires capturing the USB control messages sent to the XUP from Windows to cause it to drop off the bus and be re-enumerated as a "Xilinx Platform Cable USB II" device. I hope Digilent and Xilinx working together can come up with a better solution than my hack.

[JColvin]

Hi @gschmott,

I will let the engineer who made (and maintains) Adept (since my understanding is that Xilinx gets the cable drivers from our Adept software) know about what you ended up having to do as a work around. It will just be some time before they have bandwidth to look into this due to the usual suspect of higher priority task set forth by their boss, though I hope it won't be an indefinite amount of time.

Thanks,
JColvin

[gschmott]

Hi @JColvin -

Thanks for the follow-up and at least relaying my findings to the responsible engineer(s). I'm surprised this issue wasn't reported earlier. Perhaps it was and just ignored since it's Linux specific and not the primary OS used by many users. Still, even under Windows I had to roll-back to the Windows 7 (Jungo-based) USB driver before the XUP adapter worked as a "Xilinx Platform Cable USB II" device. I wish I could directly get the firmware being loaded into the XUP via the Windows 7 driver which re-configures the device as a Cable USB II adapter. When it's re-programmed the XUP USB product ID literally disappears from the USB bus and then re-appears as a new Cable USB II device. Do you think the Adept team could share this firmware so we Linux users could load it ourselves with something like 'fxload'?

 

Thanks . . .