Altera Quartus Programmer

[Walda Caesar]

Hereis my problem. After connecting the USB Blaster to my Win7 computer for the first time and installing the driver from altera\11.1sp2\quartus\drivers, the USB Blaster shows up in the control panel as "USB-Blaster(Altera)" but Quartus II doesn't show it in the Programmer's Hardware Setup page.

In troubleshooting, I also tried installing the same version of Quartus II and the USB blaster on my Win10 laptop, but the driver isn't signed for win10 so I dropped that approach. Back on the Win7 computer I tried using the command prompt to open altera\11.2sp2\quartus\bin\jtagconfig.exe and saw it read out the message "No JTAG hardware available".

On Quartus Pro 20.4, the chip programmer GUI would not see this device. I solved this by running the chip programmer GUI as administrator. Once the program launched, I could hear the typical USB connect/disconnect ding-dong sound effects from Windows. Then the device showed up in the programmer and it worked fine. In device manager, its new name was "Altera USB-Blaster II (JTAG interface)". After that, I didn't have to run the programmer as administrator to connect.

I just encountered this problem on Windows 11 64-bit. I ran the command "C:\intelFPGA_lite\22.1std\quartus\bin64>quartus_pgm.exe -l", which should list available programmers, and it said "No JTAG hardware available". I tried solutions listed here. None worked. The registry key suggested isn't there on W11 either.

Select the Hardware tab and select Properties. A new window should pop up with the General tab already selected. Select Change Settings. Again a new window should pop up with the General tab already selected. Select Update. Select

Find \quartus\drivers\ (Note 1: Your altera file is located at the location you selected when you first installed quartus. The location listed in this document is the default location) (Note 2: Stop at the drivers folder, i.e., do NOT go deeper by opening a folder within the drivers folder. This is important.) Select OK.

I don't think I had to restart, but you might have to. Try running C:\intelFPGA_lite\22.1std\quartus\bin64>quartus_pgm.exe -l again, and see if the device is listed. It was for me "1) USB-Blaster [USB-0]".

I have an FTDI based UARTUSB cable which I use to communicate with the board I am working on, I found that if I have the associated COM port open in my terminal application (SecureCRT, in my case) the USB-Blaster does NOT show up in Quartus.If I simply close the COM port the Blaster is once again available in Quartus.

In the quartus programmer window you have the option to create an SVF file (File -> Create SVF), this is essentially a recording of JTAG commands which OpenOCD can replay. So I connect using telnet doing exactly this:

I have essentially 3 test systems: A physical box running Arch, and on that box: a VM running Arch and a VM running Fedora 28 with kernel 4.18.4 (also tested with Fedora 4.17.11 kernel). VMs are hosted with VirtualBox. All systems are fully up to date as of this post.

I thought this might have been due to ohci_pci vs xhci_pci drivers, but using a 2.0 controller with the physical machine, arch will use ohci_pci drivers as seen in dmesg and still fail (whereas if plugged into a 3.0 port, xhci will handle it and also fail).

I have used wireshark to capture both a successful and a failed usage of the device. I don't speak USB, but it looks like in the failed mode it will go into an infinite loop of USB_BULK_IN messages between the host and enpoint (both directions alternating) and eventually time out.

I'm not sure where to go from here in terms of troubleshooting this, but any suggestions are appreciated. I'm guessing it is something specific to Arch, given that with all other things equal, the Fedora VM does not fail where the Arch VM does.

Nothing is too wonderful to be true, if it be consistent with the laws of nature -- Michael Faraday

Sometimes it is the people no one can imagine anything of who do the things no one can imagine. -- Alan Turing

---

How to Ask Questions the Smart Way

Yeah, it is not showing up as a mass storage device. That is good. Some devices do that to provide a mechanism to ship Window drivers on the device and have them auto install. There is a tool available to change the mode of devices that behave this way --but it is not relevant here.

Next, I would compare the outputs of lsmod for Arch (with the programmer attached) and for Fedora in the VM (with the programmer 'attached'). There are several Altera items in my arch kernel configuration that are flagged as modules; perhaps they need to be loaded. You can see these with gzcat /proc/config.gz grep ALTERA. There may be other modules that are disabled that won't show up and could need to be built. See what relevant kernel modules might exist in Fedora (where it works) vs Arch.

Edit: For example, I am thinking the module altera_jtaguart since, I believe, that part uses a FTDI like USB to asynchronous serial converter, and it uses JTAG to talk to the FPGA.

Edit 2: Okay, it really looks like something that appears to be a USB to serial interface, but actually has parallel outputs that drive a second chip that drives the JTAG. My suspicion remains, you are going to need to load a module -- and that module may, or may not already exist in the standard Arch kernel.

Hmm, I don't see any relevant-looking modules loaded in the Fedora system. None get loaded when the programmer is attached to the VM - and looking through the Fedora kernel config I see some of the config options that match altera are disabled. Those that are enabled in Fedora are also enabled in Arch, and Arch even has some that Fedora doesn't. Between the two VMs, it seems Arch's lsmod is a superset of Fedora's. Fedora has a lot more built-in options than Arch does though, so the lsmod output may not tell all.

I also checked through the actual journalctl log (not dmesg) and found altera's jtagd left a few messages. Nothing noteworthy, but I wasn't really aware of any of the command-line tools available in the quartus install directory - specifically jtagd and jtagconfigure. I don't have physical access to the hardware (the target board needs a power switch flipped) until tomorrow. I may try looking through strace output of jtagconfigure from both sides and seeing if anything pops out.

I'm running out of ideas here. I have one at work, but it is on a Windows box; I could drag my Linux Laptop into the lab and see what it does. First chance to try that is about 12 hours in the future..

I'm leaning towards 'subtle USB handling difference' because I have a similar issue with another proprietary hardware programmer, also USB driven - it works in the Fedora VM but not Arch. Both devices seem to work initially - the devices are present and will communicate basic descriptor info, but fail when USB bulk transfers are attempted. In the case of the other device, it will actually partially program things and report a USB disconnect after a few seconds.

Edit2: Reread the wiki and installing libudev0-shim fixed the issue, so I can run with the unmodified script. I didn't think it was relevant before because the wiki only mentions the lib32 version of the package. This also seems to have fixed the issue with the other proprietary programmer I've been having difficulties with (for GoPro compatible firmware).

3a8082e126