Cyclone III + EPCQ AS configuration corruption / flash wipe

[mateijordache]

Hi,

We recently have started having some issues with a design that we have been using for several years now. Basically, the problem is that there is intermittent FPGA booting, eventually total failure to boot. From checking some things (CONF_DONE, etc) it looks like the FPGA is not being configured at all during boot. Reading the program memory from the EPCQ serial flash (using Quartus examine feature) reveals that for some reason or another, the memory is being entirely wiped (all contents FF). 

I don't see any note about behavior like this in the datasheet for the memory. Additionally, since it is serial flash, there is a dedicated opcode (with write protect) that needs to be setup in order to wipe the whole device. So, we have been having a hard time figuring out what could cause this since an accidental erase command is entirely unlikely. Like I mentioned earlier- we have reused this design for more than 10 years. However, in the most recent implementation of the design, we needed to run some cables for certain signals, like the clock for the Cyclone III. 

Is there some sort of undocumented behavior like irregular/ dropout clock causing this flash wipe? Could power rail deregulation cause this? We also have some motors nearby, which are not really shielded to prevent stray EMI (seems unlikely this would cause it, or corruption instead of total wipe). Has anyone else seen this problem? The serial flash we are using is EPCQ64ASI16N. The FPGA is Cyclone III EP3C25.

Something to add is that the chip does not become damaged by means of this wipe- re-programming via ASP with Quartus restores the program, verification passes and functionality is restored. However we have seen the problem return after some time, meaning that there is an external stimulus for this problem.

Thanks

[Kenny_Tan]

Hi,

Thanks for using Intel community forum,

Kindly expect some delay in the reply due to holiday.

Thanks,

[mateijordache]

Hi,

I'm not sure what holiday you mean, at least in the US.

Thanks,

Matei

[YuanLi_S_Intel]

Hi mateijordache,

Just would like to check:

1.     Have you changed anything in the design or recompile the design before this issue?

2.     Do you use any QSPI IP or any IP to interact with the serial flash in the design?

Thanks

[mateijordache]

Hi YuanLi-

1. No, nothing is changed between working boards and non working boards. We did not recompile this in several years and it is stable on other systems, so we think there is something local to the board. The code is fine, this is really more a question of undocumented hardware behavior.

2. Just the basic SPI, not any other IPs.

Thanks,
Matei

[YuanLi_S_Intel]

Hi Matei,

Thanks for the clarification. If there is no any controller or IP in FPGA that can alternate the flash content. I think it could be due to EMI or any radiation that flipped the bit. You may check the CRC_Error in case of error detection.

[mateijordache]

Hi YuanLi-

It's not a matter of bit flipping or failed CRC check- the entire memory is erased. For a serial memory that seems like it would need to be intentional. Besides, all of the systems we shipped with this design do not have this problem, it's just a few boards (3 of ~80), so I don't think it's something like EMI produced locally on the board, and the entire system is shielded via a large enclosure, so I don't think something like solar flares is to blame.

Has some problem like this never been reported before?

Thanks,
Matei

[YuanLi_S_Intel]

Seems like not much issue on this. Just would like to check, is the 3 EPCQ keep on having the same issue which part of the memory is erased after sometime and the remaining is behaving good?