Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20641 Discussions

Altera USB-Blaster II Design

Altera_Forum
Honored Contributor II
5,325 Views

Hello, 

I was given instructions on building my own USB Blaster II from altera. They gave me the required drivers, a program to program the CPLD, as well as a .pof file they created to program the CPLD. I was told to copy the schematic from page 25 of the Stratix V development board. After building the device, all seems to work until i actually run the program they gave me, and i get a warning while programming saying "Warning (210120): MAX II information is incomplete. The ISP clamp functionality will be disabled." The device then seems to program, except at the end i get an error saying something along the lines of, error: hardware not detected. I then power cycle my board, but the blaster enumeration fails, and windows says the device has malfunctioned. Any ideas? thanks
0 Kudos
20 Replies
Altera_Forum
Honored Contributor II
2,720 Views

Can you share the details provided by Altera, or does access require an NDA with Altera? 

 

Could you post the Stratix V kit schematic (to save anyone interested having to install the kit software)? (Actually, since you have not had enough postings to the forum, you cannot, so email it to me using a regular email program using my forum name as the email address, and I'll post it to this thread) 

 

As far as I recall, the USB-Blaster II is a Cypress CY7C68013A EZ-USB PHY and a MAX II CPLD. 

 

The EZ-USB can be configured directly over USB or it can be configured from an EEPROM. If the Stratix V kit has an EEPROM attached to the Cypress part, then Altera *also* need to supply you the image to download to that device too. 

 

Perhaps that is the reason the USB-Blaster II is not detected correctly ... 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

That is correct. the MAx II CPLD we used was the EPM570GM100. And all we were given was .exe program they wrote that runs through the Quartus 12.0 interface, a .pof for the CPLD programming, and the drivers for binding prior to programming. 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

Hi Ryan, 

 

 

--- Quote Start ---  

That is correct. the MAx II CPLD we used was the EPM570GM100. And all we were given was .exe program they wrote that runs through the Quartus 12.0 interface, a .pof for the CPLD programming, and the drivers for binding prior to programming. 

--- Quote End ---  

 

 

If you look at the USB-Blaster II circuit on p25 of the schematic, you can see that the Cypress FX2 device EEPROM signals FX2_SCL/SDA connect to the MAX II device. This implies that the MAX II UFM (user flash memory) is being used to emulate the I2C EEPROM. This means that the MAX II .pof contains *both* the MAX II configuration image and the Cypress FX2 EEPROM image. This is why the instructions document tells you that you have to send Altera the USB serial ID information. 

 

Here's what I recommend. 

 

1. Erase the MAX II device, power cycle your board, and use USBView to look at the USB ID of the board. 

 

According to the instructions document, the FX2 should show up as Cypress FX2 ID (VID=04B4, PID=8613). 

 

2. Use the Altera jtagmaxprog tool to program the .pof into the MAX II device, and then cycle power so that the MAX II configures using this .pof. 

 

Use USBView to look at the USB IDs of the board. 

 

The USB-Blaster II should now show up with whatever ID Altera expects for the device, which according to: 

 

http://www.altera.com/download/drivers/dri-usb_b-lnx.html 

 

is 09fb:6010 or 09fb:6810 

 

Unless of course you supplied Altera with a custom VID/PID combo. 

 

3. If (2) fails, then create a MAX II configuration that simply blinks an LED, and use jtagmaxprog to download it. 

 

jtagmaxprog is just a program that bit-bangs the MAX II JTAG interface to download a configuration. A blinky LED .pof file should download fine. Since the MAX II will not implement the EEPROM image, the FX2 will still appear on the bus after you cycle power. 

 

This last step will confirm that you do not have a hardware issue with the MAX II power. It will not confirm you don't have a short on the signals between the MAX II and the FX2 devices - do you have multiple boards that you can test? 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

hey Dave, 

I can confirm that the unprogrammed board has the correct Cypress Fx2 ID. As soon as i program it, it pops up with the 09Fb:6010 which is expected. The problem is when i power cycle it, the device manager says the device has malfunctioned, and the vid and pid both read "0000". going to attempt the .pof you recommended and will let you know how it goes. and yes i have 3 difference cards i have tested so far. 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

 

I can confirm that the unprogrammed board has the correct Cypress Fx2 ID. As soon as i program it, it pops up with the 09Fb:6010 which is expected. 

 

--- Quote End ---  

 

Ok. This implies that the FX2 was able to read the USB device info from the MAX II UFM correctly. 

 

 

--- Quote Start ---  

 

The problem is when i power cycle it, the device manager says the device has malfunctioned, and the vid and pid both read "0000". 

 

--- Quote End ---  

 

This implies that the FX2 was *not* able to read the EEPROM contents correctly. 

 

If the first time had failed, I'd have suspected that the EEPROM contents were not correctly located in the .pof image. However, given your observations, it worked once, so it should work the second time.  

 

You could try probing the I2C bus to see whether there is activity on the clock and data ... and if you have a fancy scope or logic analyzer, try decoding the traffic. The format of the traffic will be defined in the FX2 documentation. 

 

 

--- Quote Start ---  

 

going to attempt the .pof you recommended and will let you know how it goes. and yes i have 3 difference cards i have tested so far. 

 

--- Quote End ---  

 

Sounds good. 

 

Best of luck :) 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

Hey dave, 

Update on the LED pof example. While programming the LED's directly through the programmer i successfully programmed my board. The issue was when i tried using the jtagmaxprog.exe i got the following error: Unused parts of pof file ROM are not zero. This was when trying to use the jtagmaxprog to implement my new led pof file. I tried to find a setting under the quartus II to set ROM to zero, but was not successful. any ideas?
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

 

Update on the LED pof example. While programming the LED's directly through the programmer i successfully programmed my board. The issue was when i tried using the jtagmaxprog.exe i got the following error: Unused parts of pof file ROM are not zero. This was when trying to use the jtagmaxprog to implement my new led pof file. I tried to find a setting under the quartus II to set ROM to zero, but was not successful. any ideas? 

--- Quote End ---  

 

 

Sorry, this description is a little confusing. You say you "successfully programmed" the board but then you say you got an error. I suspect you mean that when you used Altera's .pof it succeeded, but when you used your .pof it failed. 

 

It sounds like Altera's tool is checking the .pof image to make sure the UFM is not blank ... I really dislike these types of tools being closed-source as you cannot 'extend' their features easily. 

 

You could add a UFM block and fill it with junk. I've attached a top-level UFM component that can be used in synthesis and simulation. You can use this, or just read it to see how to wire the component. You should be able to tie the inputs to static valid logic levels and then add a synthesis constraint (keep, preserve, or noprune ... I forget which) to stop Quartus from deleting the logic. Your .hex file could contain an incrementing count, which you can see in the .pof if you scroll down into it (after opening the file in binary format). I've attached a c-file that generates a .hex file with a count. 

 

If that does not work, try submitting a service request and ask Altera for the source to jtagmaxprog ... its unlikely to contain anything particularly proprietary (the MAX II programming sequence via JTAG is effectively documented by the JRunner source code) ... at a minimum, ask if they can supply a version with a command-line option to disable the .pof checks. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

Sorry about that. What i meant was while programming my board via a USB Blaster, i got the LED's to do what i wanted. When i try to program my board using the jtagmaxprog, i get that error. i tried creating a blank memory block using the megawizardplug in, and the IP component name "ALTUFM_NONE" but i still get the same error. Currently hae an open SR with altera, but they are very slow to answer, and even slower to give any useful advice. 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

Sorry about that. What i meant was while programming my board via a USB Blaster, i got the LED's to do what i wanted. 

 

--- Quote End ---  

 

 

Ok, great. That confirms the MAX II is fine. 

 

 

--- Quote Start ---  

 

When i try to program my board using the jtagmaxprog, i get that error. i tried creating a blank memory block using the megawizardplug in, and the IP component name "ALTUFM_NONE" but i still get the same error. 

 

--- Quote End ---  

 

I'm not sure that none will be sufficient, since the .pof locations for the UFM will still be blank. Try a UFM that is initialized to the count via the code that I sent you. If you can't figure out how to get it to work, let me know, and it shouldn't take me long to create a design. 

 

 

--- Quote Start ---  

Currently hae an open SR with altera, but they are very slow to answer, and even slower to give any useful advice. 

 

--- Quote End ---  

 

Closed-source is not good :( 

 

Do you have an development kit with a working USB-Blaster II design? You could try tracing the USB activity with wireshark (under Linux, not Windows) and seeing what a successful configuration looks like, versus what happens on your custom board. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

I know what you mean about closed source... and well actually the schematics for the other boards i was looking at had a few different pinouts between the fx2 chip and the cpld. But quick question for you: lets say i have a epm570gm100, and an epm570gf100 (two different packages). I know that some of the pins correspond to different pin numbers between the two chips, but lets say functionality wise i matched the two pinouts (ex. on one chip pin e3 is for sig1. on second chip e3 from previous chip maps to e2 on next chip. hence i route sig1 to e2 on chip 2.) Would a .pof meant for the epm570gf100 then work for the epm570gm100? 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

 

Would a .pof meant for the epm570gf100 then work for the epm570gm100? 

 

--- Quote End ---  

 

If they have different JTAG IDCODEs, then its highly unlikely.  

 

Looking at the BSDL files ... 

 

http://www.altera.com/download/board-layout-test/bsdl/max2/max2-index.jsp 

 

The MBGA vs FBGA files IDCODE_REGISTER entries are the same, so it might actually work. 

 

Try synthesizing your blink LEDs design as follows; 

 

1. Start from scratch and build for the MBGA device - copy it to test1.pof 

 

2. Start from scratch and build for the MBGA device - copy it to test2.pof 

 

If test1.pof and test2.pof are identical, it tells you that Quartus is consistent. 

 

3. Start from scratch and build for the FBGA device - copy it to test3.pof 

 

If test1.pof and test3.pof are identical, it tells you that the die must be the same, its just the package that changed. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

Interesting, 

Now one question. In steps 1 and 2 you are doing the exact same thing for the exact same device. why would quartus ever not be consistent? 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

not going to go for the cross mapping between packages and hoping it works, size is not an issue so we are going to try the circuit with the new chip and the new pinout that we believe matches the .pof file from terassic we were given for testing. I'll let you know how it goes

0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

 

Now one question. In steps 1 and 2 you are doing the exact same thing for the exact same device. why would quartus ever not be consistent? 

 

--- Quote End ---  

 

 

Experience :) 

 

Quartus should *always* give the same synthesis result given identical files and an identical start seed. However, some versions of Quartus break this consistency as shown in my PCIe timing analysis tests; 

 

http://www.alteraforum.com/forum/showthread.php?t=35678 

 

The advice to repeat step 1 as step 2 is a good sanity check :) 

 

Ideally you would synthesize your design via Tcl scripts, that way there is no ambiguity as to whether or not you repeated the synthesis steps exactly. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

hey so new issue for you, turns out that altera gave me the wrong .pof file (meant for a board based off of a different schematic) and they corrected the problem. i now have the right .pof and am able to program my byte blaster and get it recognized by the quartus programmer. yet when I try to use it to connect to another board, I hit auto detect and get the error “unable to scan device chain. On-board programming hardware is disabled. Any ideas?  

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

hey so new issue for you 

--- Quote End ---  

 

Oh yippee ... :) 

 

 

--- Quote Start ---  

turns out that altera gave me the wrong .pof file 

--- Quote End ---  

 

Oops ... another X for closed-source. 

 

 

--- Quote Start ---  

 

i now have the right .pof and am able to program my byte blaster and get it recognized by the quartus programmer. yet when I try to use it to connect to another board, I hit auto detect and get the error “unable to scan device chain. On-board programming hardware is disabled. Any ideas?  

 

--- Quote End ---  

 

 

I don't have any USB-Blaster II hardware, so I'll relay what I have done with a USB-Blaster to debug things. 

 

1. Start the Quartus JTAG debugger tool (Tools->JTAG Chain Debugger) 

2. Select the "JTAG Chain Debugging" tab 

3. Shift a 32-bit data instruction with a value of 0. 

 

When the JTAG TAP goes through reset, it loads the IDCODE into the data register. The above procedure reads it out. 

 

You can now probe the JTAG TCK and TMS signals to see if they toggle. You can probe the TDO signal to see if it toggles. If you change the value to 0x55555555, then you can probe the TDI signal to see if it toggles. 

 

Try that to start with ... 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

as soon as i try to do anything with the tool, i get the error message: can't initialize chain. error locking chain or hardware is not set. 

-ryan
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

 

--- Quote Start ---  

as soon as i try to do anything with the tool, i get the error message: can't initialize chain. error locking chain or hardware is not set. 

--- Quote End ---  

 

 

This sounds like a communications issue, i.e., the USB interface is not behaving as Quartus would like. 

 

Are you running Linux or Windows? If Linux, what does lsusb show? If Windows, what does USBView show? 

 

Is the USB-Blaster II being recognized as a USB-Blaster II? 

 

Does the USB-Blaster II have an LED that turns on when its initialized? 

 

(I forget ... do you have a known-good development kit with a USB-Blaster II on it?) 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
2,720 Views

hey dave,I'm running windows. and the byte blaster pops up with the proper name (NAI USB DEbugger is what we programmed it as). I did not see any lights while initializing though. and currently we have only more unprogrammer boards. no working usb blaster II's -ryan

0 Kudos
Altera_Forum
Honored Contributor II
2,333 Views

 

--- Quote Start ---  

I'm running windows. and the byte blaster pops up with the proper name (NAI USB DEbugger is what we programmed it as). 

--- Quote End ---  

 

 

Ok, so it sounds like it is enumerating Ok. If you download USBView (a free microsoft tool) you could read all of the descriptors and confirm they match what you expect. 

 

 

--- Quote Start ---  

 

I did not see any lights while initializing though. and currently we have only more unprogrammer boards. no working usb blaster II's 

--- Quote End ---  

 

 

I'd recommend buying the cheapest development kit you can that contains the USB-Blaster II circuit. At least then you will have a known-good board to compare transactions to. 

 

I'd also recommend buying a USB logic analyzer; Total Phase and LeCroy sell them. You could then trace the USB initialization phases and traffic. 

 

If you can only afford one of these, then go for the development kit, and use Wireshark under Linux to trace the USB traffic (Windows Wireshark does not support tracing USB traffic). 

 

You can then compare your board's traffic to the known-good development kit and see where they differ. 

 

Cheers, 

Dave
0 Kudos
Reply