Fast & Large block data transfer over USB - DE1/DE2 ?

Ah I see. I will try again tomorrow.

cheers for that,

Beau

At last, progress with my Morohic II code.

As I thought, it was configuration/set-up that needed sorting.

Went back to old fpgas where things worked, realised that at the end of the program up-load I was doing various reset and config things.

Now with the Morphic II, I am using their program upload .dll, but still need to do the reset and config.

Will try this with the USB Blaster tomorrow.

But no progress with the USB Baster.

I have added relevant bits of reset and config for the FTDI USB port, and I have tried both the bit and byte variants of the JTAG TAP machine reset.

But still get toggling on TDI Pin 9, TMS Pin 5, with TCK and TDO low.

I have confirmed that I can use the Quartus and the USB Blaster to load the Morphic II program - TCK toggles fine, showing a clock type signal, Quartus reports success, the green Init_Done light comes on, indicating programming is completed. However the program does not actually run, I assume something is holding it reset.

--- Quote Start ---

However the program does not actually run, I assume something is holding it reset.

--- Quote End ---

The first thing you want to do, is create a design file that you know 'does something'. My usual preference is for 'blinky LEDs'. The Morph-IC board also uses an LED on the INIT_DONE line. However, rather than generating a design file that uses INIT_DONE, I use it as a general purpose I/O, and then blink the LED. Copy the body of the attached .vhd file into an entity that describes the Morphic-II pinout, and connect the INIT_DONE as shown in this design. Then go make the pin assignments, and download with the USB-Blaster.

What does the Morphic-II use for the configuration interface from the FTDI2232? Is it using passive serial configuration like the Morph-IC, or is it using the JTAG pins? If its passive serial, then I can give you my Morph-IC programming code.

Cheers,

Dave

Sorry, I was not clear.

Yes I do use a LED, but had not thought of borrowing the Init_Done LED.

I just have a connector on Con_1, with a couple of LEDS. One is fed from, as you say, a 1 sec toggle driven from counters, and is a nice clear indicator that the fpga is loaded and running.

It loads and runs fine when loaded from the built-in Morphic USB connector via DS2232H pin B, using the FTDI DX call from AplX :

FTStatus ← FT_ProgramMorphICDevice Hndl FileName

I then wanted to test the USB Blaster was working, so tried loading the program that way.

I used JTAG mode - would that be correct for this method ?

It appears to load (Quartus reports OK, Init_Done LED goes on), but blinky LED stays off.

Any thoughts ?

--- Quote Start ---

It loads and runs fine when loaded from the built-in Morphic USB connector via DS2232H pin B, using the FTDI DX call from AplX :

FTStatus ← FT_ProgramMorphICDevice Hndl FileName

--- Quote End ---

You mean 'port B'. Ok, so we know the FPGA works.

--- Quote Start ---

I then wanted to test the USB Blaster was working, so tried loading the program that way.

I used JTAG mode - would that be correct for this method ?

It appears to load (Quartus reports OK, Init_Done LED goes on), but blinky LED stays off.

Any thoughts ?

--- Quote End ---

So you've got a USB-Blaster connected to the JTAG header on the Morph-IC-II board? And you know the USB-Blaster works?

Do you have the Morph-IC-II schematic? Can you probe the CONF_DONE, nSTATUS, CONFIGn, etc pins? Actually, if the FT2232 is using passive serial mode, then you can read the state of those pins via the Morph-IC-II Port B interface (since the programming interface needs to access these signals). If CONF_DONE is not high after you load the FPGA via the USB-Blaster, then it indicates a problem with the JTAG interface.

Cheers,

Dave

--- Quote Start ---

I assume something is holding it reset.

--- Quote End ---

You can test this theory by *not* using a reset signal in your design, eg., if there is a port called ext_rstN that you are using like rstN <= ext_rstN, just change it to

rstN <= '1';

And if your design works, then you know the external reset is staying asserted.

If you look at the Morph-IC-II schematic, the reset signal is likely coming from a FT2232 GPIO, and when you load via USB-Blaster, you do not deassert that pin, so you'll need to write a program to assert/deassert the reset GPIO.

Cheers,

Dave

Well, opening the FT2232H B port seems to start the program running :

(LED dim)

Program the fpga via the

,HandleB &#8592; ft_OpenSpecifiedMorphICDevice Name1 Sn1

40974824

HandleB ft_ProgramMorphICDevice File

(LED toggling, INIT_DONE lit)

, Tmp_Prg &#8592; ftgetbitmode HandleB

0 0 0 1 1 1 1 0

ft_CloseMorphICDevice HandleB

(unplug USB lead from FT2232H to remove power and ensure program is wiped, re-plug)

(LED dim)

(program fpga via USB Blaster - reports success)

(LED off, INIT_DONE lit)

,HandleB &#8592; ft_OpenSpecifiedMorphICDevice Name1 Sn1

40974824

(LED toggling, INIT_DONE lit)

, Tmp_UB &#8592; ftgetbitmode HandleB

0 0 0 1 1 1 1 0

So I guess the USB Blaster is working fine.

--- Quote Start ---

Well, opening the FT2232H B port seems to start the program running

--- Quote End ---

Are you using a reset signal in your design? Does the reset come from the FT2232? Do the bit values you show correspond to the deassertion of the reset signal - hence explaining why your configuration starts to work?

Cheers,

Dave

Reset :

Yes, the design uses a reset : HW_RESET, but the connection takes some tracing :

HW_RESET, fpga pin B3 - this is labled Data3

There is an external reset :

Resetin#, connector J1-14 - this goes to the FT2232H pin 14, with a pull up resistor.

The crucial commection for the reset is from the FT2232H pin 46 : BDBUS7, again labled Data3.

I have tried setting and clearing the top bit of the FT2232H B bus, to see if I can halt the operation but not sure I am doing it right yet. Will go read the data sheet again.