Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
Announcements
Need Forum Guidance? Click here

Search our FPGA Knowledge Articles here.
18466 Discussions

Programming via rbf file stopped working

RHI
Beginner
647 Views

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

Thanks

 

0 Kudos
10 Replies
RHI
Beginner
638 Views

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?

RHI
Beginner
633 Views

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?

NurAiman_M_Intel
Employee
601 Views

Hi,


Thank you for contacting Intel community.


How did you generate the .rbf file? And did you choose 4 bytes addressing?


Regards,

Aiman

 



RHI
Beginner
598 Views

Hi

I used the original rbf file generated after compiling the project.

I also generated the rbf file through the GUI (Convert Programming Files). There are no option for 4 byte addressing.

Both of these options do not work.

NurAiman_M_Intel
Employee
573 Views

Hi,


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:

https://www.intel.com/content/dam/www/programmable/us/en/pdfs/literature/ug/ug_pfl.pdf



Regards,

Aiman

 


RHI
Beginner
564 Views

Hi

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.

RHI
Beginner
563 Views

Sorry, I missed placing the file

BoonBengT_Intel
Moderator
442 Views

Hi @RHI,

Hi,

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

Wamr regards
BB

BoonBengT_Intel
Moderator
394 Views

Hi @RHI,

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. 

Thank you

Warm Regards
BB

NurAiman_M_Intel
Employee
526 Views

Hi,


Apologize for the delay in response as we are looking into this case. We will get back to you once we have the findings.


Thank you.


Regards,

Aiman


Reply