Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
15544 Discussions

Problem with ByteBlaster under Windows10/64: "Error (213043): More than one.."

Honored Contributor II

Hi all 


We have following problem: 

We are using the "ByteBlaster" for programing our Altera devices. 

For now this worked perfectely (with WinXP/32 and Win7/64) but now we are trying to switch to Windows10/64bit and this causes problems: 


The error message from „quartus_pgm.exe“ command line tool reads as follows: 


"error (213043): More than one programming cable found in available hardware list -- use --list option to display available hardware list and specify correct programming cable" 




The reason for that is clear: 

By listing the available download tools (-> „quartus_pgm.exe -list“) we found out, that „quartus_pgm.exe" sees two "USB-Blaster"(!!!) but technicaly, just one is available in system!!:evil: :confused: 

(-> We checked that via the device manager: Just one Altera device is available within the USB category.) 


If you type „quartus_pgm.exe -list“ you realize that "quartus_pgm.exe" finds two devices which are named as "usb-blaster [usb-0]" and "usb-blaster [usb-1]"



The reason why this occures is, that we are using a second hardware with FTDI based USB connection on this PC! 


If this chip (or its COM connection) is open, than the "quartus_pgm.exe" tools recognizes this second interface as a second "USB-Blaster".:confused::rolleyes: 

If the dedicated COM interface is closed again than "quartus_pgm.exe" will just find the correct "ByteBlaster" interface! 


-> Thats the behavior with driver version "08/26/2014,2.12.00" under Windows10/64 in our system! But for driver version "04/21/2009,2.04.16" behaviour changes: 


-> If we are downgrading the ByteBlaster driver to version "04/21/2009,2.04.16" than the behavior gets better for FTDI-com-Interfaces, not perfect, but it works. 

Unfortunately it doesn't work with that driver version, if the FTDI chip is used with "bit bang" mode! 


But we need both modes, COM and BitBang. 



Does someone else has recognized that problem? Inital conditions: 


- If Win10/64 is used  

- "ByteBlaster" is connected  

...with folowing FTDI configuration: Type= "FT232/245BM"; VendorID="09FB"; VID_PID="2"; idProduct="6001" 

- second USB interface with FTDI chip (and standard VID and PID) is connection 

...with folowing FTDI configuration: Type= "FT232/245BM"; VendorID="0403"; VID_PID="0"; idProduct="6001" 



By using 

- driver version "08/26/2014,2.12.00" of "usbblstr*.*" 

-> "quartus_pgm.exe" finds other FTDI chips and declares it also as "USB-Blaster [USB-x]" 

- driver version "04/21/2009,2.04.16" of "usbblstr*.*" 

-> "quartus_pgm.exe" finds other FTDI chips and declares it also as "USB-Blaster [USB-x]" but just if FTDI is used in "bit bang" mode, in normal COM mode it works! 



..for us it seems, like the quartus tool is just searching for insufficient device parameters (e.g. like type "FT232/245BM"). 


Did you already find a solution for that issue? 


If none had this problem or no solution is available it would help enormously if the sourcecode of "quartus_pgm.exe" and "nios2-flash-programmer.exe" would be available. 



Best regards 

0 Kudos
4 Replies
Honored Contributor II

You can specify which programming cable the Quartus programmer is to use.quartus_pgm -c {cable index} 


See also 



Honored Contributor II

Hi Alex 


Thank you for your reply. I know this possibility. But for a variety of reasons, there is a big advantage for us in not having to define the programming interface: 


a) We only need one programming interface on a PC at one time, but it would be good if the interface type could vary ( we remain independent of which programming interface we use, "ByteBlaster" or "ByteBlaster_II", ...). 


b) When we use our FTDI device in BitBang mode, "quartus_pgm.exe" recognizes it as "USB-Blaster [USB-?]" as soon the COM interface is opend. The problem is, that for some reasons sometimes the real "ByteBlaster" remains at "[USB-0]" sometimes it changes to "[USB-1]". 


c) Third problem is, that the given cable name in "quartus_pgm.exe" ("[USB-0]" or "[USB-1]") depends on the order you connect your interfaces to the pc (and also on the order the COM interfaces are opened). 


For these reasons, it would be good if we could continue to use the tool in the same way as we did under previous operating systems (like WinXP/32, Win10/64).  

Does anyone know what is technically the reason for this new behavior? 


Best regards 

Honored Contributor II

You are struggling against 'progress' and the 'improvement of the tools'. Or as you are finding - changes that aren't particularly helpful. 


I'm afraid you're going to continue to struggle against this. As you say, simply plugging items in in a different order changes how they are presented by the operating system. 


Some of the problems you're encountering are not new. We wanted a number of setups, all the same, for production testing/programming some 10 years ago. We never found a flexible, satisfactory solution. Each station had to be 'assembled' according to a particular instruction, doing things in the right order. I'm unaware of any changes to the tools that changes this. 


I think you need to put this question to people who are more knowledgable about PC operating systems and how you might solve it. 



New Contributor I


we have some similar, but otherwise different Problem. We have two USB Blasters installed in the Setup, one of them connected to the "to be programmed" electronics, the other one unconnected at the programming I/F, just being connected by USB. As already mentioned, you cannot be sure which one is recognized as [USB-0] and which as [USB-1]. Therefore, the user needs to try one of them, either being lucky or - if that fails - try the other cable. Can this "try and error" be automated? The idea is to start one programm and than the connected one is either detected or if the try with one fails, the second is tested automatically…


Thanks a lot, Carlhermann