Electrical – windows – Quartus II: USB Blaster not found, even after installing the driver

fpgaquartuswindows

I've purchased this USB blaster: https://www.amazon.com/dp/B07F5H5LPZ/

Because I have this Ep2c5/ep2c8 dev board, I've been following this video to begin my work with FPGAs: https://www.youtube.com/watch?v=le6Jo5DpLao

Here is 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".

Is there something obvious that I'm doing wrong here? Do I have a bunk USB Blaster? Do I have the wrong hardware or software altogether?

Best Answer

I found out while using Quartus Standard, the answer is to disconnect other USB devices and the blaster is seen again by Quartus

Related Solutions

Electronic – How to make Quartus II find the Altera DE2 board

Close the programmer and power cycle the board. If that doesn't work, I've also had success using the Windows Reinstall Driver function.

FPGA outputs are always high with basic and/or program

Since this is your first FPGA project with this board, there are several things that could be going wrong. (I go through this kind of thing myself with every new development system)

Maybe the board isn't powered -- the Amazon link doesn't say whether this board includes the required 5V DC power supply. If this is anything like the ones on ebay, the board should come already loaded with some code that lights up the LEDs. Normally an FPGA board vendor loads a test program onto the board to prove there are no assembly errors, before they ship the board. So when it is first powered up, I'd expect to see an LED light up.

Maybe the JTAG programmer was connected to the wrong header -- this board has two different 2x5 shrouded headers, one for JTAG loading and the other for SPI platform flash loading.

Maybe the design is actually working? How are you testing it? I know that EP2C5T144 board doesn't have much on/board switches and LEDs. The input and output pins are on dual-row headers. It's easy to mis-count or get the inner row / outer row connection swapped. I looked through your project report files and don't see anything wrong. To test this code, you'd have to connect some wires to your in_1, in_2, in_3 and connect each to either 3.3V or GND. Then go through the "truth table" combinations, and observe the output.

Your example HDL code was correctly translated, based on this part of the log file:

Info (21057): Implemented 7 device resources after synthesis - the final resource count might be different
    Info (21058): Implemented 3 input pins
    Info (21059): Implemented 2 output pins
    Info (21061): Implemented 2 logic cells

This is exactly the resource usage I'd expect for a pair of three-input gates. I also checked through the other reports to see if any of the logic got removed by later stages, but it looks to me like it got through place/route/map and should have ended up in the final configuration bitstream.

On a side note: it's good practice to use net names like "in_1", "out_1" like you used in logic.v, instead of just "1" - "5". Makes it easier to understand what's intended. The pinout report (BasicLogic.pin) would be easier to read if the toplevel net names matched up with your HDL code.

Pin Name/Usage               : Location  : Dir.   : I/O Standard      : Voltage : I/O Bank  : User Assignment
-------------------------------------------------------------------------------------------------------------
1                            : 40        : input  : 3.3-V LVTTL       :         : 4         : Y              
2                            : 41        : input  : 3.3-V LVTTL       :         : 4         : Y              
3                            : 42        : input  : 3.3-V LVTTL       :         : 4         : Y              
4                            : 71        : output : 3.3-V LVTTL       :         : 4         : Y              
5                            : 72        : output : 3.3-V LVTTL       :         : 4         : Y

Suggestion: try an LED blinker project next. Just use a 24-bit counter (clocked by the on-board 50MHz system clock) and the MSB of that counter should blink slow enough you can see it blink, but fast enough you know it's doing something. I've learned the hard way to always include an LED blinker diagnostic on my projects, so I can confirm that the FPGA actually got programmed with valid code.

Related Topic