Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
15 years ago

Parallel Flash Loader issues

Hi all,

on a custom board we are using PFL (implemented in a MAX II device) to configure a single Stratix II GX device using FPP. The flash memory (S29GL064N) holds 2 firmware images, user and factory, programmed in page 0 (0x0000000) and in page 1 (0x00200000) respectively. The bitstreams are NOT compressed. The option bits are stored at address 0x003F0000. The user image can be programmed using JTAG or through the Stratix II GX FPGA. In this latter case the flash access is implemented as part of the custom FPGA firmware (i.e. not PFL) and uses a HEXOUT file which is converted from SOF.

When the flash memory is written using Quartus II programmer and a POF, the FPGA is configured properly with the user image. However, if the user image is updated through the FPGA the configuration failes.

This is what happens. Following power-up the PFL starts to load the configuration from the user area, but after a few miliseconds nStatus is pulled down and the PFL (as expected) reverts to the factory default. We verified that the user image is properly programmed into the flash by reading it back and comparing it with the HEXOUT file. Unfortunately, this verification could not be done using the Quartus programmer, because there seems to be a fixed 4-byte offset when the data is written by Quartus.

In order to debug this problem I made some measurements using an oscilloscope (screenshot available on request). Normally, for each flash address cycle there should be 2 DCLK cycles, because the flash data is 2-byte wide while the FPGA requires 1 byte (a la FPP). On the scope however I could see that the PFL uses a different scheme before the configuration fails: 8 DCLK cycles per address (i.e. 4 DCLK pulses per byte). As far as I could understand, this is required for compressed bitstreams. Actually, shortly before the failure happens the PFL switches between the 2 modes (compressed -> normal) making me even more puzzled. :confused:

Why would the PFL start the configuration in compressed mode ? If this is really the case, why would it suddenly switch to normal mode ?

Legend for attached file:

yellow - nStatus

green - FPGA DCLK

purple - Flash A0 (address LSB)

BR

12 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    The 4 byte offset, you observed, is there, because the PFL image contains a 32 bit header with additional information, e.g. the PFL version and, if I remember right, also a compression mode flag. You can refer to the PFL sources to check for the details. Don't expect much explaining comments.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Thanks for your reply. Does this mean that I cannot use a HEXOUT file directly to update the flash content ? I will try to figure out what is in that header anyway.

    By the way. There was a mistake in the original post. I meant that the bitstreams are NOT compressed.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    --- Quote Start ---

    Does this mean that I cannot use a HEXOUT file directly to update the flash content ?

    --- Quote End ---

    I think you can, if you know, what to write to the first four bytes.

    --- Quote Start ---

    I meant that the bitstreams are NOT compressed.

    --- Quote End ---

    I didn't think about the details of your post. Obviously, you don't manage to write an image identical to the Quartus programmer, and apparently, it has to do with compression (at least among other issues).
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Ok, I think it is clear now. I will try to write back the original values of the 4 bytes (with or without the offset) and see what happens.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    It did not work ... :(

    So, what file/format should I use to program the flash without the Quartus II programmer, if HEXOUT is not compatible with PFL, and if POF format is not public ?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    As you can see from the PFL source, the upper 16 header bits contain also an image length information. If it's not set accordingly, the configuration load must be expected to fail. This point is also involved with "know, what to write to the first bytes". I didn't yet try to write a PFL flash image by user code, so I can't tell you precisely where to find the respective information. But I'm sure you can get it, also other embedded configuration methods are able to retrieve an image size information.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I understand your "know, what to write to the first bytes" statement. However, I don't think this should mean that the user must figure out the details from the HDL source. Well, I kinda like this, but it is really time consuming. So, if someone knows a better information source (datasheet, application note etc.) I would really appreciate that. ;)

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    I reviewed my collected PFL docs. It seems like the basic information is given in AN386, possibly not as clear as desirable.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    15 years ago

    Ok. AN386 does state that RBF is not supported (did not say anything about HEXOUT, but I think it is almost the same). I will ask our software engineer to implement flash programming with POF support. We shall see...