trabucayre / openFPGALoader

Universal utility for programming FPGA
https://trabucayre.github.io/openFPGALoader/
Apache License 2.0
1.16k stars 249 forks source link

Digilent JTAG HS3 wrong interface (ft232H not supported?) #414

Closed maij closed 8 months ago

maij commented 8 months ago

Basic info

OS: Ubuntu 22.04.3 LTS SW version: v0.11.0 (compiled from latest main branch commits today) Cable: Digilent JTAG-HS3 Rev A Board: qmtechKintex7

Detailed problem

I am trying to write bitstreams to the qmtech k7325T board but it doesn't work with openFPGALoader, despite working in Vivado with the exact same setup.

If I simply try to load the bitstream, I get the following error:

$ openFPGALoader --board qmtechKintex7 --bitstream top.bit
empty
No cable or board specified: using direct ft2232 interface
unable to open ftdi device: -3 (device not found)
JTAG init failed with: unable to open ftdi device

I can find the correct cable using scan-usb but trying to then use this info explicitly reveals issues claiming the usb device (see below)

maij@Connie:~/Documents/github/OpenFPGA/demo-projects/general-qmtech$ openFPGALoader --scan-usb
empty
found 7 USB device
Bus device vid:pid       probe type      manufacturer serial               product
001 012    0x0403:0x6014 ft232H          Digilent     210299B71F97         Digilent USB Device

I have tried unplugging and plugging the USB cable, but this has not helped.

maij@Connie:~/Documents/github/OpenFPGA/demo-projects/general-qmtech$ openFPGALoader --bitstream top.bit --busdev-num 001:012 --board qmtechKintex7
empty
No cable or board specified: using direct ft2232 interface
unable to open ftdi device: -5 (unable to claim usb device. Make sure the default FTDI driver is not in use) (USB bus 1 addr 12)
JTAG init failed with: unable to open ftdi device

I have noticed that I cannot specify -c ft232H, is there meant to be support for this interface? I have looked into other issues, it seems this might be a user issues problem, although I have tried adding the udev rules as explained in the installation. Things I have tried:

Here is a dmesg dump after plugging in the device.

[Jan 3 01:16] usb 1-3: USB disconnect, device number 16
[Jan 3 01:17] usb 1-3: new high-speed USB device number 17 using xhci_hcd
[  +0.153136] usb 1-3: New USB device found, idVendor=0403, idProduct=6014, bcdDevice= 9.00
[  +0.000004] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000002] usb 1-3: Product: Digilent USB Device
[  +0.000001] usb 1-3: Manufacturer: Digilent
[  +0.000001] usb 1-3: SerialNumber: 210299B71F97
[  +0.003221] ftdi_sio 1-3:1.0: FTDI USB Serial Device converter detected
[  +0.000018] usb 1-3: Detected FT232H
[  +0.000574] usb 1-3: FTDI USB Serial Device converter now attached to ttyUSB0
[  +0.073205] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[  +0.000023] ftdi_sio 1-3:1.0: device disconnected
trabucayre commented 8 months ago

There is two types of boards:

  1. ones with onboard JTAG interface
  2. ones with an header or a connector

For the first category when you select a board with -b/--board the cable name is automatically filled, for the second category you have to explicitly provides this information by using -c/--cable if your interface is different than naked ft2232h.

qmtechKintex7 is in the second category and according to this issue's title you use a digilent_hs3 interface.

So your command must be:

openFPGALoader --board qmtechKintex7 --cable digilent_hs3 --bitstream top.bit

I'm finally not sure using a default cable, when this information is not provided by the board's description nor by user, is a good idea, it's error prone.

maij commented 8 months ago

Thank you for your response. I did try to specify --cable digilent_hs3 but it showed the same problem as when I explicitly provided the busdev-num, where it gave error -5, device in use.

I finally found that there was a Vivado hw server running in the background on my system (I connected to the server using tcl, but didn't close the server when quitting). Every time I plugged in the device, the hardware server was claiming the device. I have modified my tcl script to prevent this from happening.

I am happy to report that running the command you suggested (now without the Vivado hw server running) allows me to write bitstreams to my board!