Cyclone V: switching between application images using altremote_update

--- 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

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?

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.

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.

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...

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

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!

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.

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