Forum Discussion

jlats2's avatar
jlats2
Icon for Occasional Contributor rankOccasional Contributor
4 years ago
Solved

Loading FPGA from Flash

Hello,

Thank you for taking time to read my post.

I am working with a Cyclone 10 GX using micron MT25QU01G flash memory. I am able to generate a programming file (.JIC) and load the flash memory. When I power cycle the chassis the fpga loads from the flash and appears to run fine.

I am also generating a hexout file. Using this as my reference on how to interpret the records in the hexout file, I am able to write the hexout contents to the flash memory. When I power cycle the fpga, the fpga hangs (is unresponsive, similar to how it behaves before ever being programmed with a JIC/SOF).

Am I correct that writing the contents of the hexout to the flash should be the same as loading a JIC?

Is there anything special that I need to do (such as add a pointer in the first address in flash)?

I am able to readback the flash memory and compare it to the contents of the hexout file and the checksum values to match so I am fairly confident that I am writing the flash chip correctly.

Again, thank you so much for reading this and helping me.

Best Regards.

  • jlats2's avatar
    jlats2
    4 years ago

    Thank you for your help. I certainly will need the 'remote update ip' as this will help me reconfigure the fpga without power cycling the entire board. Thank you for sharing.

    It turns out that there is a difference between EPCS and EPCQ flash memories . EPCS can accept the hexout file which is produced during compilation. However, the EPCQ will not work with the hexout directly loaded to flash (bug with quartus?).

    The work around is to generate a JIC file, and while doing this, check the box for generating a .RPD file. This .RPD will need to be loaded to flash and will work for EPCQ. The .RPD is not in an 'intel hex' format. Fortunately, there is a python project which allows one to convert from the RPD to what we will call a 'hexout' format (shown below for future readers):

    <<< python code >>>

    from intelhex import IntelHex
    ih = IntelHex()
    ih.loadbin(filename)
    ih.write_hex_file('test.hex',byte_count=128)

    <<<end python code>>>

    I am not sure why the hexout file varies from the rpd, maybe someone from intel can comment?

    Best Regards

6 Replies

  • sstrell's avatar
    sstrell
    Icon for Super Contributor rankSuper Contributor
    4 years ago

    I'm not sure what you're trying to do, but a .hex file is normally used to initialize the contents of RAMs or ROMs in the design, not as an overall programming file for the device. It gets pointed to by a parameter or a synthesis attribute and then gets included in the programming file generated by the Assembler at the end of the compilation process (.sof or .jic in your case). What are you trying to accomplish?

    • jlats2's avatar
      jlats2
      Icon for Occasional Contributor rankOccasional Contributor
      4 years ago

      Thank you so much for your reply.

      Perhaps I have some of my terminology incorrect, but the overall goal is to remotely update the fpga configuration data over the network. When I generate a JIC file and program my C10GX with a byteblaster, I understand that this is actually loading the 'configuration data' to a flash chip. Whenever I power cycle my fpga, the 'configuration data' from this flash chip will configure the fpga. My goal is to be able to update the 'configuration data' on this flash chip over the network (not with a byte blaster). This will allow me to 'remotely update' the firmware. My assumption was that the generated hexout is the 'configuration data.'

      Is my goal clearly described above?

      Assuming that the records in the hexout file are correctly written to the flash memory, should this be sufficient in updating the configuration data so that during the next power cycle the new contents of the flash will configure the fpga?

      Again, thank you for all of your help.

  • jlats2's avatar
    jlats2
    Icon for Occasional Contributor rankOccasional Contributor
    4 years ago

    Something else that I noticed and thought it might be worth sharing:

    Whenever I generate a JIC file, I can also generate a rpd file. After programming the the JIC and power cycling the fpga, I can read the flash memory and see that the values loaded into the flash memory seem to match the rpd. The rpd is raw data and does not include the same record type information that the hexout file contains (which makes it difficult to compare the two). However the data contained in the .rpd and the .hexout appear to be similar with a few differences (some bytes are different, and the rpd appears to have ff's shifted into the first 30ish bytes).

    Just adding to the above discussion.

  • jlats2's avatar
    jlats2
    Icon for Occasional Contributor rankOccasional Contributor
    4 years ago

    Thank you for your help. I certainly will need the 'remote update ip' as this will help me reconfigure the fpga without power cycling the entire board. Thank you for sharing.

    It turns out that there is a difference between EPCS and EPCQ flash memories . EPCS can accept the hexout file which is produced during compilation. However, the EPCQ will not work with the hexout directly loaded to flash (bug with quartus?).

    The work around is to generate a JIC file, and while doing this, check the box for generating a .RPD file. This .RPD will need to be loaded to flash and will work for EPCQ. The .RPD is not in an 'intel hex' format. Fortunately, there is a python project which allows one to convert from the RPD to what we will call a 'hexout' format (shown below for future readers):

    <<< python code >>>

    from intelhex import IntelHex
    ih = IntelHex()
    ih.loadbin(filename)
    ih.write_hex_file('test.hex',byte_count=128)

    <<<end python code>>>

    I am not sure why the hexout file varies from the rpd, maybe someone from intel can comment?

    Best Regards