Forum Discussion

RHI's avatar
RHI
Icon for New Contributor rankNew Contributor
5 years ago

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

Thanks

10 Replies

  • RHI's avatar
    RHI
    Icon for New Contributor rankNew Contributor
    5 years ago

    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's avatar
    RHI
    Icon for New Contributor rankNew Contributor
    5 years ago

    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's avatar
    NurAiman_M_Intel
    Icon for Super Contributor rankSuper Contributor
    5 years ago

    Hi,


    Thank you for contacting Intel community.


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


    Regards,

    Aiman



    • RHI's avatar
      RHI
      Icon for New Contributor rankNew Contributor
      5 years ago

      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's avatar
    NurAiman_M_Intel
    Icon for Super Contributor rankSuper Contributor
    5 years ago

    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's avatar
      RHI
      Icon for New Contributor rankNew Contributor
      5 years ago

      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's avatar
        RHI
        Icon for New Contributor rankNew Contributor
        5 years ago

        Sorry, I missed placing the file

  • NurAiman_M_Intel's avatar
    NurAiman_M_Intel
    Icon for Super Contributor rankSuper Contributor
    5 years ago

    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