A few years ago we developed a bootloader application for Cyclone V E that receives an application.rbf file via UART (in NIOS II) and then writes the data into the EPCQ32 flash device for. It then switches to the application. This worked fine until we needed to update the application and bootloader for support of the EPCQ32A devices. What we have found
1) When creating a pof file from both the bootloader and the application sof files and program it via the USB blaster, the bootloader boots up and loads the application and all works fine.
2) Sending the application.rbf file to the bootloader and reading back the memory via USB blaster, seems to write all the data correctly to the flash, however the the application does not run - the bootloader reboots witha reconfiguration trigger value of 2. I am not sure what this means as in the NIOS code it seems to be a ALTERA_RU_RECONFIG_TRIGGER_CONDITIONS_WDTIMER trigger, however when looking at the Remote Update User Guide (Chapter 1.3.5 - for Cyclone V) it states that a value of 2 is nSTATUS condition.
3) When only programming the bootloader.pof via the USB blaster, the memory readback is significantly different from that of combined bootloader-application.pof.
4) The original rbf file seems to have a 3 byte offset (after the "nii header") difference compared to the bootloader-application.pof and its memory readback. See Capture.PNG
5) There is also a "half byte" difference between the original pof and the bootloader-application.pof where the data is also "half-byte-mixed-and -shifted".
In short, the rbf that we load at the application memory location, is verified to be correct, however it does not load the application. How can we solve this issue...
I wrote a small C program that takes a snippet from the bootloader-application.pof (Note the strange thing: it is the pof file) that was genereated via the GUI application selecting the sof files of both bootloader and application. The snippet is from the application start address + 152 bytes to the end of the file. I then saved this snippet as an rbf file and programmed it through the bootloader application. This actually boots the application and everything works.
Why does the original application.rbf not work, while the above does the trick?
On point 3,4 and 5 of the post, the difference is due to generating the pof files either as 1-bit passive or 4-bit passive configuration. Also using the 4-bit passive configuration generating pof files has the exact same result as generating a rbf file except that the pof file has an extra header and footer and holds the entire memory content.
The question still stands, why does the original rbf file not work?
How was the rbf being program as rbf is meant for user own programmer and cannot be program by using Quartus?
On top of that, if .sof can be program, it does not mean PS setup is correct, hence might need to check the setup and follow the guide. There are a lot of possibility on why the .rbf cannot be programmed but .sof file can be programmed.
Below are the PFL guide example if you are using MAX series as host controller:
As mentioned in the original post: rbf file data is sent serially to NIOS running in the bootloader application that writes the data into the EPCQ32A flash memory.
Secondly: As mentioned, the previous version of the project (Using the EPCQ32 on Quartus 15) did the job just fine. Also, the new version (Quartus 20.1 updating the IP's) writes the data byte-for-byte correct into the EPCQ32A device. We use the USB blaster to verify that the correct data is found in the flash device. Therefore programming the flash does not seem to be the problem at all. BTW - we can program both pof and sof as well as we can use the JTAG and serial programming interfaces, however we only use this during development.
Taken that the sof is OK, there are but a very few possibilities that the rbf goes wrong (you would agree), as generating the rbf is very simple. Generating the rbf with only the application.sof does not work, however doing the following does:
1) Generate an pof with both bootloader.sof and application.sof where the address of the application.sof is specified at xxx.
2) Cutting the data in the pof from address xxx +152 bytes into a new file and renaming it app.rbf does work.
See the picture below (Capture2) from a compare of the auto-generated (left) and the cut-from-pof (right) files. The header content is different, but also you will notice the three byte offset difference between the two files (FF FF FF that is found in red at the lower end of the picture). This offset is evident throughout the whole file, however the rest of the content is exactly the same.
Good day and hope this message find you well, a quick check on the issues is it still persisting?
And is the device are you using? As for the .rbf generation, its has been generated via the GUI and there is some manual steps (i.e. cutting of data and rename to .rbf) involved? This steps are also used and working in the previous quartus 15? The comparison of the screenshot capture2 is from quartus15(left) and quartus20.1 (right)?
Hope this message find you well, we are suspecting the different of flash configuration might be the cause, would suggest to try regenerating the pof via the GUI by select the configuration device as EPCQ32A, followed by same generation of rbf files. Here are also some guideline which highlight the different between the flash devices which might be useful. Please do try and let us know.
Unfortunately as we do not receive any response from you to the previous clarification that we have provided. Please post a response in the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.