Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

Remote update EPCS file format?

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?

17 Replies

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

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

    Jake