Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorParallel 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) BR12 Replies
Altera_ForumThanks 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
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.
