Closed maij closed 8 months ago
There is two types of boards:
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.
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!
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:
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)
I have tried unplugging and plugging the USB cable, but this has not helped.
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.