Cyclone V: switching between application images using altremote_update

Altera_Forum · ‎11-05-2014

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

Altera_Forum · ‎11-07-2014

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.

Altera_Forum · ‎08-26-2015

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 · ‎08-27-2015

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 · ‎08-27-2015

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 · ‎08-27-2015

--- Quote Start ---

Hi julianca,

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). QUOTE]

Yes thank you, this is exactly what I was asking.

I am currently paused my project, loaded the .jic via JTAG, and I am using a logic analyzer to view what is being read out of the EPROM... it goes through a process that includes Read Status, Read Device ID, etc, and I'm afraid that my application will have to mimic these steps. I may first try to write the .rbf file to the EPROM, and load upon power cycle/boot up without adding those extra steps. (The final goal is to include reboot selected images. Baby steps.)

Altera_Forum · ‎08-27-2015

I'd first just try reading the image from the epcq.

This is really easy to do if you have access to actual epcq pins.

You just big-bang out a read command (initially test with address 0) and then bit-band in the read data.

For cyclone V (Arria II and later) the epcq is configured for two extra dummy clocks so that they can use epcq256 with 4 byte addresses.

You can read the nv status register to find this out - but for a specific board you know what is there.

Altera_Forum · ‎08-31-2015

I am trying to identify the reboot process, and the difference in data being read on EPROM data lines.

Regardless if I am looking at the .jic/JTAG image or if I used my application to write the .rbf file, the states seem to be the same:

a. DCLK starts low, data lines high (starts with nCS trigger; signal goes low)

b. READ STATUS (register) op code

c. READ DEVICE ID op code and it reads the fact I have an EPCQ256 device

d. FAST READ op code followed by a string of data over the D1 line only (as is appropriate for Fast Read operation)

Fast Read lasts .24ms and ends with a pulse in the nCS

(the JTAG/jic version also includes e. EXTENDED QUAD INPUT FAST READ op code followed by 32-b address of 0x00012C00 and data in on all 4 D-lines)

However, in the version where I reboot from my application, it tries the FAST READ and must not like the data it's reading because it continually restarts the process after reading about 3ms of data.

Any idea what the data is that it is trying to read here? Is this supposed to be the actual image file? The data doesn't seem to match the image, or even a bit reversal of image data (jic or sof or rbf)

Also - dsl - you mention bit reversal. Is that by 4 or 8 bits? Do you have a suggestion on simple ways to do this to create a new image to write?

Thanks so much!

Altera_Forum · ‎09-01-2015

The data that is stored on the epcq should match that embedded in the .pof (under 128 bytes of header) or the entire .rbf file.

The data starts with IIRC 128 0xff bytes.

For some unknown reason there are slight differences between the image in the .pof and .rbf.

If your hardware is setup to generate correct 'quad reads' then you need to bit-reverse each byte of the rbf file data.

I'd program the epcq from a .pof and then use your own logic to read the data back and then check the data matches.

Then erase, write back and re-read to check your writes work.

Then check power-on-load from your own image.

Finally try the 'altremote_update' reset (which is where I get stuck).

Altera_Forum · ‎09-10-2015

Update?

Yes, I am set up for Active Serial, x4, and now bit-reverse each byte of the .rbf data.

When I compare .jic to the .rbf, I can see the part of the .jic that includes the .rbf data. Good.

When I program the epcq using USB blaster to JTAG the .jic file, it comes back VERY similar to when I use my FPGA application to write through the bit reversed .rbf file. (I am comparing by creating a new .jic as an "examine" from the Programmer utility) Good, but not good enough. There are just a few bytes that are altered and slightly. Enough that the FPGA hangs (stuck in an inf.loop) on a reboot.

I'm playing around with .pof to lesser degree. When you talk of .pof, which option in the "Convert Programming Files -> Programming file type:" do you use? I have been using the first option, with 1-bit Passive Serial mode (?). If I try to use the POF for Remote Update, I can't get it to generate a file... error messages.

Another suggestion was to try the .hex option. Have you tried that? I am going to now...

Altera_Forum · ‎09-10-2015

I'd select 'passive serial' probably with 4 bits. You'll probably find that the output file doesn't change (the .rbf ones don't).

Our build is set to generate the .pof and .sof by default - dunno where/when that got set.

It also isn't at all clear why the .pof and .rbf (and probably .jic) binary data differ slightly. The bits may not matter (provided the overal checksum is correct).

I'd try writing the data you've read back from the epcq for an image that loads.

And, if you can, do a readback of your written image.

You might have a timing error - so reads/writes are occaisionally corrupted.

Altera_Forum · ‎09-19-2015

Hi,

Instead of using .rbf file, use .rpd file for ASx1/x4 configuration scheme. AS configuration scheme 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. The .rbf file is not supported in AS mode as there are option bits for AS mode is not available in the .rbf file.

starting in Quartus II v13.1, you can generate a .rpd file which only contains the required configuration data (not the whole flash size).

1.Open the File -> Convert Programming Files GUI.

2.Select Programming file type: Programmer Object File (.pof) or JTAG Indirect Configuration file (.jic).

3.Select the appropriate configuration device and Mode.

4.Click SOF Data in the window at the bottom then Add File and add the SRAM Object file (.sof).

5.Check the Create config data RPD box.

6.Click Generate.

Altera_Forum · ‎09-21-2015

Etoomanyfileformats

Altera_Forum · ‎10-02-2015

Thanks.

To this point, I have had similar experiences/observations with the .rbf and .rpd (bit reversal, compression on, no timing issues, no bit corruption that I can see.)

In both cases, the board gets stuck in an infinite loop upon startup. The clock starts around 10MHz through initial config stages, then jumps up to about 90MHz for the quad-read. In this phase, the data is being read on 4 data lines from the flash device, but then goes back to the beginning of the boot cycle.

Do you think it may have to do with some setting or checkbox when creating the file?

Altera_Forum · ‎03-02-2017

--- Quote Start ---

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

--- Quote End ---

Although this is an old thread...how do switch from the application image back to the factory image?

I have tried to set ru_reconfig high (after setting AnF back to 0 and flash address back to 0x0), but the FPGA freezes and ru_reconfig gets stuck at high (as in POR).

Br

Marius