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

Using FTDI FT2232H to load Cyclone 3

Altera_Forum
Honored Contributor II
2,148 Views

Hi 

 

I have a hard time finding supporting documentation on the FTDI site regarding using a FTDI FT2232H device, one port is used for Data transfer ( 40 M) and the other is only used to program the FPGA (Active Serial) (and monitoring nConfig, nStatus, Config_Done). 

 

I am going to load the "name.rbf" file (raw binary file), which include .sof and compiled c-code. 

 

Some article suggest using the ftcspi.dll, while others suggest using the libMPSSE.dll 

 

I purchased the Morph-IC-II, however, it includes a canned program used to load the FPGA, the critical lines of code are not shown. Schematics show what pins to use, it all makes sense. 

 

Any suggestions would be greately appreciated 

 

Thanks
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
630 Views

Read through the following thread: 

 

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

 

It starts out discussing the DE1 but it goes on to discuss the Morphic and Morphic-II. 

 

I posted some code during the thread, eg., page 4. I used the FTDI FTD2XX.DLL for device access (under both Windows and Linux). 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
631 Views

Hi Dave 

 

First of all, let me thank you for your reply.  

 

I have been working on this for the last few days making incremental progress. After some head-scratching I think I am 95% done, only one final issue to resolve (I hope).  

 

So far I have been able to: 

1. Controlling the nConfig, so it can be asserted (and deasserted) to start the configuration. 

2. Load the file.rbf file and send it to the FPGA, (256K in 1-2 seconds), Config_Done goes high. 

3. I included logic in the FPGA-Hardware image which drives a pin out at 1 KHz (I can see it on Oscilloscope) so I know the image is loaded. 

4. C-code toggles another pin. I do see it working when JTAG is used to load FPGA, however, I do not see it when FT2232H is loading the FPGA (JTAG removed) 

5. Being able to observe the Init_done pin would be great. However, it is used for LVDS so I do not think it can be used (not sure). 

 

So I am wondering: Do I need to assert (and deassert) the reset line to the FPGA after it has been loaded?  

 

Or, is there some other setting (Board BSP???) 

 

Thanks  

Hans 

 

 

0 Kudos
Altera_Forum
Honored Contributor II
631 Views

Hi Hans, 

 

--- Quote Start ---  

 

First of all, let me thank you for your reply.  

 

--- Quote End ---  

You're welcome. 

 

 

--- Quote Start ---  

 

I have been working on this for the last few days making incremental progress. After some head-scratching I think I am 95% done, only one final issue to resolve (I hope). 

 

So far I have been able to: 

1. Controlling the nConfig, so it can be asserted (and deasserted) to start the configuration. 

2. Load the file.rbf file and send it to the FPGA, (256K in 1-2 seconds), Config_Done goes high. 

3. I included logic in the FPGA-Hardware image which drives a pin out at 1 KHz (I can see it on Oscilloscope) so I know the image is loaded. 

 

--- Quote End ---  

Ok, so up until here we are talking about FPGA *hardware*. 

 

 

--- Quote Start ---  

 

4. C-code toggles another pin. I do see it working when JTAG is used to load FPGA, however, I do not see it when FT2232H is loading the FPGA (JTAG removed) 

 

--- Quote End ---  

Just to be clear: for JTAG you're using a USB-Blaster, and the FTDI is being used for Passive Serial? 

 

They are identical as far as downloading hardware is concerned. 

 

There can be a subtle difference when dealing with software. I believe (and may be wrong) that if you include a JTAG UART in the design, and you are *not* using JTAG, then you might be able to break your design. 

 

So, what other software components are in your system? Anything JTAG related could be removed to test this theory, and then added back in later. 

 

 

--- Quote Start ---  

 

5. Being able to observe the Init_done pin would be great. However, it is used for LVDS so I do not think it can be used (not sure). 

 

--- Quote End ---  

You don't need INIT_DONE. You've confirmed with your 1kHz pin toggling that the FPGA is configured. Now you are onto software debugging. 

 

 

--- Quote Start ---  

 

So I am wondering: Do I need to assert (and deassert) the reset line to the FPGA after it has been loaded?  

 

--- Quote End ---  

It totally depends on where that reset line is. The answer could be as simple as "press the reset button". But if it was that simple, you would not be asking :)  

 

What reset line are you referring to? 

 

Note that technically you do not have to have a reset - when the FPGA configures all of the registers are in a well-defined state (I personally prefer having a reset source though). Depending on whether any of the programming pins you have access to (via FTDI) can be reconfigured as an I/O pin after programming, you could use it as a reset to your design, eg., assert it to see the 1kHz signal stop and then deassert it to see the signal toggling again. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
631 Views

Hi Dave 

 

I have changed my focus again, I am now thinking that my "file.rbf" only contains the hardware (.sof) and not both .sof and firmware (.elf). 

 

In looking at other Threads, some seems to indicate that, all of the above (.sof and .elf) will come together into the "file.rbf". Others indicate a manual conversion process is needed (to concatenate two files).  

 

In support of my observation, I noticed that the "file.rbf" only updates when I build in Quartus II (version 11). If i compile c project or BSP, "file.rbf" is not updated. 

 

Forgot to mention that I only use on-chip memory (no external memory) 

 

Any thoughts? 

 

Thanks Again
0 Kudos
Altera_Forum
Honored Contributor II
631 Views

 

--- Quote Start ---  

 

I have changed my focus again, I am now thinking that my "file.rbf" only contains the hardware (.sof) and not both .sof and firmware (.elf). 

 

--- Quote End ---  

That sounds like a reasonable hypothesis. 

 

 

--- Quote Start ---  

 

Forgot to mention that I only use on-chip memory (no external memory) 

 

--- Quote End ---  

Do you have a .mif file (memory initialization file) or a hex file?  

 

Quartus will use the .mif file to initialize the memory, and that should be included in the .rbf file. 

 

If however you have been using JTAG to download the software image, the RAM might be blank from the hardware perspective, and then the NIOS IDE downloads the firmware (software binary into the on-chip RAM). 

 

You can test that hypothesis by downloading the .rbf and then using the NIOS IDE to access your processor. If that works identically to JTAG downloading of the hardware, then you have narrowed down your problem. 

 

I don't use NIOS in my designs, so can't offer any experience with that particular flow. However, I have used .hex files to initialize MAX II UFM memory. When I was debugging that design, I looked in the .pof file (using TextPad to view the binary bytes) to see that the UFM memory initialization file was being included directly (I could see the byte pattern I was testing with in the .pof). 

 

Cheers, 

Dave
0 Kudos
Reply