RHI
New ContributorJoined 5 years ago
User Profile
New Contributor
User Widgets
Contributions
Re: Programming via rbf file stopped working
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.2.8KViews0likes3CommentsRe: Programming via rbf file stopped working
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?2.9KViews0likes0CommentsRe: Programming via rbf file stopped working
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?2.9KViews0likes0CommentsProgramming via rbf file stopped working
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... Thanks2.9KViews0likes10Comments