Honored ContributorHi 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:
Honored ContributorHi 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.Honored ContributorHello 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.)Honored ContributorHi 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!Honored ContributorExtracting 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.Honored ContributorHonored ContributorI'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.Honored ContributorI 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!Honored ContributorThe 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).Honored ContributorUpdate?
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...Honored ContributorI'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.
