Download Bitstream to Cyclone V by using the FPGA manager

[Altera_Forum]

Hi, 

 I like to upload the soc_system.sof via the FPGA manager.  I use the source code of the U-Boot. I have ported it to VxWorks. I use the Altera Evaluation Board REV B. . Before I begin to download the bitstream I setup CLKOUT0 to 32 MHz (32.021605 MHz) and CLKOUT1 to 96 MHz (96.064815).  I setup SW3 on the Evaluation board as follows:  SW3 1|2 |3|4 |5|6|# | | | |#|#|  |#|#|#| | |  The U-BOOT used the procedure as described in "Cyclone V Device Handbook, Volume 3: Hard Processor System Technical Reference Manuel, A-19 / FPGA Configuration". After the last bytes of the bitstream are written to the FPGA Manager (to address 0xffb90000) it will be waited till the config is done. Therefore I poll the GPIO_EXT_PORTA of the status registers. I get always the status value 0xB01. ==>  nSTATUS : 1  CONF_DONE : 0  INIT_DONE : 0  CRC_ERROR : 0  CVP_CONF_DONE : 0  PR_READY : 0  PR_ERROR : 0  PR_DONE : 0  nCONFIG Pin : 1  nSTATUS Pin : 1  CONFIG_DONE Pin : 0  FPGA_POWER_ON : 1  To complete the configuration nSTATUS (NS) == 1 && CONFIG_DONE (CD) == 1  Has someone an idea whats going wrong?  Best regards,  Stefan.

[Altera_Forum]

I'm having similar troubles. I was able to get past the 0xB01 by setting the msel for 32-bit mode. Which is msel[4:0] = 01000. However now I get 0xB09 CRC error and other strange behavior. CONF_DONE is flashing out of control during programming and eventually settles at being off. After running my program the jtag chain is lost until a hard reset.

[Altera_Forum]

I have the same issue and have not been able to get past the 0xB01 message. Have either of you found out what the problem was since the last post?

[Altera_Forum]

As I originally posted. The 0xB01 was caused by improper MSEL. The 0xB09 turned out to be programming the wrong cdratio. I was putting a binary 1 in the register, but 0 was needed to set cdratio to 1.

[Altera_Forum]

I can read the MSEL pins back as 0x8 and am programming the cd ratio to 0:0 and the cfgwdth to 1. Any ideas as to what else could cause this?

[Altera_Forum]

Maybe your RBF file is not correct or otherwise not being written to the data port correctly. If the fpga doesn't see the sync words then it will get stuck in 0xB01 forever. The newer kernels, 3.9 i think, have an fpga manager driver. So all you need is to copy the RBF to /dev/fpga0. I haven't actually tried this though. Newer kernels also don't take the fpga bridges out of reset so you will need to do that after programming the fpga. There is some sysfs mechanism for this as well.

[Altera_Forum]

I have attempted to load the fpga from the u-boot prompt and found that it fails at exactly the same point as my code does. I'm not really sure what's going on now; unless it is my .rbf file that is the problem. Has anybody else been able to use quartus 13.0sp1 to generate .rbf files and programme the fpga? I have had no problems programming using the .sof via quartus.

[Altera_Forum]

Problem solved! 

 The problem was the fpga images being generated by Quartus. I was using the menu setting assignments->Device->Device and Pin Options to set quartus to produce .rbf files as an output. The files produced by quartus do not work.  To produce a working .rbf file I used a script called quartus_rbf to convert the .sof to .rbf. It can be found in altera/13.0sp1/quartus/bin.