Forum Discussion

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

Cyclone V: switching between application images using altremote_update

Hi all,

I am using a Cyclone V in a custom design and I have some issues while using the altremote_update megafunction:

I have 3 different images stored in an EPCS device:

  • factory image, stored at 0x000000

  • application image A, stored at 0x180000

  • application image B, stored at 0x300000

The factory image is never used in normal operation, it is only used as a fall back image when updating one of the application images has gone wrong.

I want to switch between application image A and application image B and back (the FPGA receives an external pulse signal when it should switch between the images). According to the Cyclone V Handbook, Figure 7-22, it appears that it is only possible to switch between the application images via the factory image, and not directly.

My problem is that I am only able to load one of the application images, and then switch back to the factory image. The factory image then loads the same application image as before, while the other application image is never loaded (so only image A is started every time, or only image).

In the factory image I am using logic to determine which application should be loaded. This logic is based on a Cyclone IV design, in which this setup works OK. In the Cyclone IV design, it is possible to use the READ_SOURCE port of the altremote_update megafunction to determine which boot address the previous image had been loaded from. The factory image can then use the address of the previously loaded image (for instance of image A), to switch to the other other image (in this case image).

For the Cyclone V, the READ_SOURCE port is not available in the altremote_update megafunction, so no information about previous configurations seems to be available. When I read the boot address (using the Page Select parameter) in in the factory image, it always reads back 0x000000, also when I try to write this address to another value in one of the application images.

Does anyone know whether it is possible in a Cyclone V design to still get information about the previously loaded application image? Or is the only solution to store that information in an external memory? Or is there another solution to this problem and am I trying to solve it in the wrong way?

Thanks in advance,

martenv

14 Replies

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

    Extracting the 'rbf' data from a 'pof' file is relatively easy (sof is harder).

    You do need to remember to bit-reverse the data (from a rbf or pof) before writing it to the epcq.

    This is all easily verified by reading what the altera tools write to the epcq.

    I do wish Altera had documented the 'remote update' block as a 'reconfigure from epcq' block and then explained how it could be used for user/factory (etc) images.

    I've managed to correctly write the epcq, but can't manage to request the fpga reconfigure itself (works ok on power up).

    This might be because I've added the jtag<->epcq block in order to expose the epcq interface.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi julianca,

    For writing the data directly to the EEPROM using a USB-Blaster I use a .jic file. You can create a .jic file from a .sof file in Quartus via File > Convert Programming Files. Then you can put multiple image files, for instance a factory image and multiple application images, in 1 .jic file.

    In your case, you seem to write the EEPROM via the asmi core, so I assume you are trying to write a file with one image to a known location in the EEPROM. You cannot use .sof file format for that purpose. You need to use a .rbf file or a .rpd file, depending on the kind of FPGA you are using (you can create .rbf and .rpd files via the same tool, via Convert Programming Files). You can probably find which file you need in the documentation, or alternatively: you can first create a .jic file of your .sof file. Then you can create both a .rbf file and a .rpd file, and compare the contents to the .jic file, using a HEX editor (note that some of those files have an extra header). The file that matches the .jic file is the one you should use.

    Good luck!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hello martenv,

    I am working on something similar. What type of file did you store as a factory image?

    Thanks!

    J

    (I'm using a .sof as the new factory image (to address 0x00000000) using my logic to write via asmi core to the EPROM. The writing seems to happen, but the reboot isn't loading the new image correctly - I'm trying to identify my problem.)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    11 years ago

    Hi all,

    in case someone is experiencing the same problem: I found a solution that works for me:

    In contrast to what Altera advices in the Cyclone 5 Handbook, I now do not set the AnF (Application / Not Factory) bit to 1 when I reconfigure to an application image. This allows the application images to write the Remote System Upgrade control registers, so the application images can directly switch to another application image, without going via the factory image (this is also different from the Cyclone V Handbook, Figure 7-22). In the case that an application image becomes corrupted, the remote_update circuitry reconfigures to address 0x0, which is the factory image. So this is the behavior I was looking for.