Remote update EPCS file format?

[Altera_Forum]

I have a Cyclone III EP3C5 design that uses an EPCS16 device in AS mode for configuration. I have successfully implemented the ALTREMOTE_UPDATE function as well as a function to load a new application configuration in the EPCS16 at address 0x80000. This function simply receives the new configuration file one page at a time over a custom communication port and programs it to the ECPS16 device (after erasing the appropriate sectors, of course). 

 I tried loading an application config raw binary file (.rbf) at that address and when I attempt to reconfigure at 0x80000 and use the new configuration, the device reverts back to the factory configuration and reports a reconfiguration trigger of 5'b00100 (nSTATUS asserted by an external device as the result of an error). Funny, because I don't have anything tied to nSTATUS pin... it is pulled high with a 10K resistor. This isn't the first issue I have found with ALTREMOTE_UPDATE, so I don't trust this info.   If I create a .jic file with the factory config at 0x00000 and the application config at 0x80000, everything works just fine. With this .jic file in the EPCS16 I can trigger a reconfiguration when in factory mode and the device successfully loads the application configuration.   Using a binary editor, I took a look at the application config .rbf file and compared it to the data embedded in the .jic file. The only difference is in the very beginning of the .rbf file. A handful of bytes are different. I editted those bytes in the .rbf file to match what was in the .jic file. I then used my update function in the device to download the new .rbf file into the EPCS16 (again at 0x80000) and reconfigured. Everything worked beautifully.   So here's my question: what file format am I supposed to use when downloading a new application configuration into the EPCS16? Or, if the format is .rbf, how do I create one that is correct? Any idea what settings I might have overlooked that created an incorrect .rbf file?

[Altera_Forum]

The bits need to be reversed in every byte in the RBF file before being programmed into the EPCS flash. 

 Jake

[Altera_Forum]

Here you go: 

http://www.alteraforum.com/forum/showthread.php?t=5991&referrerid=2226  Has a bit more information.  Jake

[Altera_Forum]

Thanks for the quick reply. The bits are reversed. The EPCS is programmed correctly, which I verified by reading the contents of it using the Examine feature of the Quartus-II programming tool. 

 The only difference in the data programmed into the EPCS between the working application config and the non-working application config is the first handful of bytes in the .rbf file. I used the same .rbf data (except for those first handful of bytes), the same programming function in my Cyclone part, the same factory config, etc.   So what would cause the .rbf file generation to produce a file with only a few bytes different from what it should be? I suspect I might have some option in the file conversion tool set improperly, but I'll be darned if I can figure out what.

[Altera_Forum]

One thing I did notice: when creating the .rbf file from the .sof file the File Conversion tool does not give me the option of selecting Active Serial mode. The options are Passive Parallel Asynchronous, Passive Parallel Synchronous, Fast Passive Parallel, 1-bit Passive Serial, and Active Parallel. I used 1-bit Passive Serial to create the .rbf file that seems to be in error. 

 Any idea if this is the cause of the problem, and if so how do I get Active Serial to show up as an option? I am running Quartus-II 9.0 SP2.

[Altera_Forum]

What I would do is just set up Quartus to generate the RBF file automatically during compilation: 

1 - Assignments->Device->Device and Pin Options 2 - Select the "Configuration" tab and make sure the Configuration Scheme is set to active serial. 3 - Select the "Programming Files" tab and check the "Raw Binary File (.rbf)" checkbox. Now the RBF file will be automatically created with the SOF file.  This should produce a correct RBF file. You'll just have to perform the bit-reversal manually (which you must already be doing anyway).  Jake

[Altera_Forum]

Thanks Jake, that worked!

[Altera_Forum]

Another way to do it is use the sof2flash utility which is part of NIOS II EDS. When you do it this way, the bits are already in the correct order so you can use the output of sof2flash directly.

[Altera_Forum]

The file type you should be useing rpd. Please also take a look at srunner http://www.altera.com/literature/an/an418.pdf  

 To program the EPCS device in your application you use quartus to first generate the POF files and to convert the files from POF to RPD. RPD is a subset of POF, with the ASCII header removed. The srunner software, that we do provide the source code for, can then write to the EPCS device. Srunner is designed to be ported to many processors, and an 418 gives sufficent detail to produce equivlent functionality in VHDL or Verilog. You may be able to do some pre processing before the transmission of the file.  To do a remote update system it is important to remember that the remote update is based on pages, and the pages are are assigned when the POF file is initally generated. The use of fixed start addresses is strongly suggested.   Inital POF + RPD 1. Generate the factory image sof and all user sofs, that you may want to use in the image.  2. Decide on memory boundarys for the EPCSdevice, I would suggest for EPCS64 and if two images are used that Page_1 starts at 0x00200000  3. Useing convert programing files set Programing file type to POF, select EPCS64 and mode active serial, select Memory Map file. Using add Sof Data and add File, add the required sofs to the POF, and setting the required addresses. Generate the pof, and check the .map file. Save the conversion set up.  4. Set Programing file type to Raw Programing Data file, select the POF and add the pof you have just generated.  Remote update POF + RPD  1. Generate the new user sof. 2. Using convert programing files, set Output programming file type to Programmer Object file to Programmer Object File for Remote Update.  3. Set the POF file to the inital POF 4. Set the SOF file to the new sof, check that the assigned page and start address are correct. 5. Ensure Memory Map File is checked. 6. Set Remote/Local update difference file to Programmer Object File 6. Generate the pof. 7. Check the map file to ensure the correct page has been updated. 8. Set Programing file type to Raw Programing Data file, select the POF and add the pof you have just generated.  You may wish to examine the POF and the RPD files in a hex editor, the programing data should start at the adressess indicated, the stream of FF is required. If you are doing a remote update rather than an inital programing of the POF you only need to transmit the data from the required page start address.

[Altera_Forum]

Hi jdfenley, 

i am new to remote upgradation in FPGA. i tried to get ideas how to do that. but i didn't get. i have seen ur post related to remote upgradation of Cyclone III device. could u please help me in this problem. i hav to upgrade my cyclone III device through ethernet. i m using CYclone III, epcs4 as my flash memory.   thanks in advance

[Altera_Forum]

--- Quote Start ---  The bits need to be reversed in every byte in the RBF file before being programmed into the EPCS flash.  Jake  --- Quote End ---    hi jake！ i read out all the EPCS4 data and compare with those RBF file showing ，i found that the difference was not only reversed in every byte ，but also same address with different data！ could you please teach me why ？ BTW ，I used QII 11.1 WINXP

[Altera_Forum]

--- Quote Start ---  The file type you should be useing rpd. Please also take a look at srunner http://www.altera.com/literature/an/an418.pdf   To program the EPCS device in your application you use quartus to first generate the POF files and to convert the files from POF to RPD. RPD is a subset of POF, with the ASCII header removed. The srunner software, that we do provide the source code for, can then write to the EPCS device. Srunner is designed to be ported to many processors, and an 418 gives sufficent detail to produce equivlent functionality in VHDL or Verilog. You may be able to do some pre processing before the transmission of the file.  To do a remote update system it is important to remember that the remote update is based on pages, and the pages are are assigned when the POF file is initally generated. The use of fixed start addresses is strongly suggested.   Inital POF + RPD 1. Generate the factory image sof and all user sofs, that you may want to use in the image.  2. Decide on memory boundarys for the EPCSdevice, I would suggest for EPCS64 and if two images are used that Page_1 starts at 0x00200000  3. Useing convert programing files set Programing file type to POF, select EPCS64 and mode active serial, select Memory Map file. Using add Sof Data and add File, add the required sofs to the POF, and setting the required addresses. Generate the pof, and check the .map file. Save the conversion set up.  4. Set Programing file type to Raw Programing Data file, select the POF and add the pof you have just generated.  Remote update POF + RPD  1. Generate the new user sof. 2. Using convert programing files, set Output programming file type to Programmer Object file to Programmer Object File for Remote Update.  3. Set the POF file to the inital POF 4. Set the SOF file to the new sof, check that the assigned page and start address are correct. 5. Ensure Memory Map File is checked. 6. Set Remote/Local update difference file to Programmer Object File 6. Generate the pof. 7. Check the map file to ensure the correct page has been updated. 8. Set Programing file type to Raw Programing Data file, select the POF and add the pof you have just generated.  You may wish to examine the POF and the RPD files in a hex editor, the programing data should start at the adressess indicated, the stream of FF is required. If you are doing a remote update rather than an inital programing of the POF you only need to transmit the data from the required page start address.  --- Quote End ---    sorry i make a mistake！ there are some different bettwen .rbf file data with EPCS4 stored data,(not only reversal)  rpd file data are same with EPCS4 stored data after be reversed.  i am curious why .rpd file was different with .rbf file

[Altera_Forum]

--- Quote Start ---   The EPCS is programmed correctly, which I verified by reading the contents of it using the Examine feature of the Quartus-II programming tool.  --- Quote End ---    How did you read the contents of EPCS? I couldn't find the Examine feature, you have mentioned, in Quartus II programmer.

[Altera_Forum]

--- Quote Start ---  How did you read the contents of EPCS? I couldn't find the Examine feature, you have mentioned, in Quartus II programmer.  --- Quote End ---    what is the Examine feature？ what do you mean ？

[Altera_Forum]

--- Quote Start ---  How did you read the contents of EPCS? I couldn't find the Examine feature, you have mentioned, in Quartus II programmer.  --- Quote End ---    Hi Ashish,   I just came to know regarding that feature.Here how you can use it.It reads the content of configuration flash memory and then you can examine that data.  (1) Open the quartus programmer. (2) From the edit menu select add device. (3) Select appropriate Device.Have a look at image_1(Available in Examine.zip).In my case, I chose EP3C25. (4) Follow the step as shown in image_2. (5) Again from edit menu, select attach flash device. (6) Select appropriate device.I have been using EPCS16 device.Hence I chose it.See image_3. (7) Now check mark against examine option as shown in image 4. (8) After configuring hardware setup(I mean selecting USB Blaster or other such device from Hardware setup menu), select start. (9) It will read content of your flash memory and will store in untitled.jic file. (10) After Progress status shows 100%, you can save untitled.jic file using save file option from edit menu at the desired location.  Thanks, Bhaumik

[Altera_Forum]

Hi Bhaumik, 

Thanks a lot.   Ashish

[Altera_Forum]

Hi, 

 Because I use the third-party flash (S25FL064), the quartus programmer cannot recognize the chip.  So I use nios2-flash-programmer to download .flash files. Will this cause any reconfig problem? If I put the user image at 0x000000, the device boots well. And if I put the same image at 0x200000, the reconfig fails. I read out the data in the flash device by using NIOS2-Eclipse in debug mod. It seems everything is same. No ideas for this issue.  hdai

[Altera_Forum]

.flash file also works