Cyclone II intenral supply voltage short after programming

[Altera_Forum]

Hi, 

I'm currently facing a problem with a control card using the EP2C8T144 with EPCS4 config EEPROM. For unkown reasons the FPGA seems to die (not immediately) after being programmed with both, I/O (3.3V) and internal voltage being shorted to GND on the Cyclone chip.  I already asked the production guys whether they have changed anything during programming e.g. plugging/unplugging the USB Blaster with card being powered but they sware not having changed anything. Actually a lot of cards are programmed on one station, moved in ESD compliant package to the final unit assembly line and then failed operation -> investigation ending in internal supply voltage being shorted. Additionally one USB Blaster failed in production line.  For me it seems as if either I/O and/or core voltage must climb above max. limit, causing the hard short to GND on the chip, but I have currently no idea, where in production (as nothing seems to be changed) this happens. Any ideas where to have a look at?  Sincerely, Carlhermann

[Altera_Forum]

--- Quote Start ---  Hi, I'm currently facing a problem with a control card using the EP2C8T144 with EPCS4 config EEPROM. For unkown reasons the FPGA seems to die (not immediately) after being programmed with both, I/O (3.3V) and internal voltage being shorted to GND on the Cyclone chip.  I already asked the production guys whether they have changed anything during programming e.g. plugging/unplugging the USB Blaster with card being powered but they sware not having changed anything. Actually a lot of cards are programmed on one station, moved in ESD compliant package to the final unit assembly line and then failed operation -> investigation ending in internal supply voltage being shorted. Additionally one USB Blaster failed in production line.  For me it seems as if either I/O and/or core voltage must climb above max. limit, causing the hard short to GND on the chip, but I have currently no idea, where in production (as nothing seems to be changed) this happens. Any ideas where to have a look at?  Sincerely, Carlhermann  --- Quote End ---    Hi ,  I'm not a production specialist, but maybe the problem is not production related.  Is it a new project ? If yes, how is it verified ( on the production board ?)? What is additional to your FPGA on the board ?   Kind regards  GPK

[Altera_Forum]

Hi, 

the project is in production for about three years w/o problems until last month. No changes have been made on the design, thus I cannot explain the problem occurring now. I think if it is something with the design itself, the failure would have occured much earlier. Regarding the programming procedure I killed a FPGA myself on the lab-bench by plugging the USB Blaster with system being powered already - the FPGA worked until I plugged the USB Blaster, no programming occurred (device not found) and - the FPGA did no longer configure. But in this case, the defect was limited to the configuration Pins, the 3V3 and internal core voltage were not shorted at all. (I would assume JTAG configuration may still have been possible - no interface to test on card)  In my humble opinion, there must have been an overvoltage condition killing the FPGA completely. An overload to either pin seems more likely to kill the pin's output structure rather than the complete IC) Does an overload the 3V3 also cause short on the core voltage or did both be overloaded?  Sincerely,  Carlhermann