I'm currently using Cyclone III (EP3C5F256C8) and I'm trying to configure it and it's not happening. I'm using AS connected to a FLASH chip (M25P16). nCONFIG, nSTATUS, CONF_DONE and INIT_DONE are pull-up to 3.3V through a 10K resistor.Using a logic analyzer, I looked at the Serial data and the configuration signals from the FPGA(nCONFIG, nSTATUS, etc.) The First part of the SPI transaction which is requesting to read the FLASH is done correctly; nSTATUS is high and nCONFIG is high during this. Then the second part of the SPI transaction which is supposed to read the data stored in the FLASH starts, but I'm seeing that CS comes up before all the data stored in the FLASH is read; This leaves nSTATUS high and CONF_DONE low. After a while nSTATUS goes low and then the the CYCLONE III tries again to reconfigure, but the same thing happens over and over again. Any ideas why the CYCLONE III might be giving up before reading the whole data in the flash? The size of the data in the FLASH is: 368.0 KBytes CS is down for 93uS. DCLK rate is 36.23MHz. This numbers indicate that the CYCLONE III is only reading ~430.5 Bytes
Suggests wrong configuration data with corrupted header CRC in a first order, or a hardware problem causing wrong data. How are you writing the AS configuration?
Do you see any activity on nSTATUS - other than when it 'follows' nCONFIG at the start of a configuration cycle? This would indicate an error in the data the FPGA is receiving.Cheers, Alex
So, I nSTATUS once it goes high it never goes down indicating a configuration error (sorry I mixed up nCONFIG and nSTATUS in my first description of the problem). I actually tried to trigger the Logic analyzer on the falling edge of nSTATUS and it was not possible to do so.
The design has a socket where I plug-in the Flash. The flash is loaded with the .rbf through a BK precision programmer, then plug it to the board. I suspected that maybe the data was corrupted and had a wrong header, but when I went in with the logic analyzer at least the first 50 bytes looked correct.
--- Quote Start --- The flash is loaded with the .rbf through a BK precision programmer. --- Quote End --- This gives room for a lot of faults. You might already misunderstand the expected configuration data bit-order which is different from regular SPI protocol. Do you know that you can load the AS flash through JTAG indirect programming and also verify the flash content this way? Hope you didn't omit the JTAG interface.