Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18513 Discussions

Issues Downloading Cyclone V Image to EPCS Device / RBF-JIC File Discrepancies

Honored Contributor I

I'm having a difficult time with programming a portion of my EPCQ configuration device and having things behave as I expect on the subsequent power cycle. Any insight into what I'm doing wrong would be appreciated. Device and design questions are off the table (why NIOS vs ARM, why Cyclone V E vs other Altera FPGA, etc.) 


my setup and background info: 

Cyclone V E FPGA 

EPCQ128 Configuration Device 


configuration device address map: 

EPCQ128 Address 0x000000 Boot Firmware Image 

EPCQ128 Address 0x760000 Boot NIOS Image 

EPCQ128 Address 0x800000 Application Firmware Image 

EPCQ128 Address 0xf60000 Application NIOS Image 




  • The board programs via JTAG and a JIC file extremely reliably - no problems. 

  • I have the Remote Update feature working flawlessly. On power up, the boot firmware and NIOS images load, followed 10 seconds later by the application firmware and NIOS images loading. 

  • In my NIOS code, I wrote the ability to download new application firmware and application NIOS. The binary data is downloaded to an external SDRAM and CRC verified for correctness before updating the data in the configuration device. It is also read back from the configuration device and CRC verified at the end of the process to ensure the data was written in correctly. 

  • I have accounted for the bit reversal that needs to happen for the firmware image. 

  • I can successfully download the application NIOS image multiple times. Each time, the new image runs correctly when the board undergoes a power cycle. 

  • However, I am having massive difficultly and strange behavior in doing the same with the firmware image. Each time when I download this image, the firmware runs (as evidenced by a Verilog controlled blinking LED) but the nios never boots. 

  • I ran the examine option from the Quartus programmer and discovered that there are 17 bytes that are different in the beginning 300 bytes of the firmware image - that's it. The remainder of the data is bit-for-bit correct with the original data programmed by Quartus. I'm assuming this is what is keeping my NIOS from booting? 



binary file generation: 

For the firmware image, I create a RBF from the source SOF. I handle the bit reversal, download, and program this data. 

For the JIC file, I create it from Quartus using both SOFs (addressed on different SOF pages) and both NIOS memories (each showing up at their appropriate address). 


file comparison: 

When I compare the application RBF data to the application data embedded in the JIC file, these 17 bytes are already different. See attached JPG for the comparison (JIC on left, RBF on right). My question is what is going on? Why is this difference already present? How do those bits prevent the NIOS from booting? 


Am I doing something basic that is wrong? Are there other preferred ways of generating the data that I need to send? If I replace those 17 bytes with the original 17 bytes manually, will it work? 


Any insight is greatly appreciated. I'm basically out of ideas at this point. If the tool is giving me a file that's wrong, that's a problem.
0 Kudos
4 Replies
Honored Contributor I



Are you using .rpd file for Active Serial configuration scheme? 

User should not be using .rbf file for Active Serial configuration scheme. 


The .rpd file should have the same content as the .jic file.  


For more information check below links 


Best Regards, 

Anand Raj Shankar 

(This message was posted on behalf of Intel Corporation)
Honored Contributor I

Thanks for the reply Anand. 

However, your suggested remedy does not work in my case.  


I did some further searching and noticed a thread on here that mentioned the exact same issue I was having (apparently my initial search did not yield this result): The suggested fix in it (turn on automatically generating RBF during compilation) solved my issue. 


It is very interesting to me that the tool (Quartus) generates the RBF differently when it is commanded to as part of the assembler portion of the compilation versus using the Convert Programming Files utility. The convert programming files RBF output does NOT work, yet the RBF generated during the compilation works perfectly. 


Is this a Quartus bug? Or an intended design choice that I apparently don't understand the reasoning behind? Seems to me the RBF image should be the RBF image, yet that doesn't appear to be the case.
Honored Contributor I



1.The RBF is still not the correct programming file format for AS configuration scheme.  

2.RPD is the correct file format for Active Serial configuration scheme. In the EPCS datasheet has mention the usage .rpd file. 

3.AS configuration scheme only support .jic, .pof and .rpd file format. The .rpd file is a binary file for EPCQ/EPCS devices containing a binary bitstream of configuration data for FPGAs that support Active Serial configuration.  

4.You can compare the RPD contents is the same as .jic file contents. The RBF file has always been use for passive type configuration scheme such as Passive Serial and Fast Passive Parallel.  

5.Use RPD file for AS configuration scheme and not RBF file. 


Best Regards, 

Anand Raj Shankar 

(This message was posted on behalf of Intel Corporation)
Honored Contributor I



I have some similar problems. I use nios2-flash-programmer to burn the .flash file into the flash. The factory images boots well but fail to reconfig to the user image (with nStatus fail). 


I have no ideas on this issue.