I completed a design using a Cyclone III EP3C5F256C8N back in 2013. We have been shipping the board with no problems until now. The last batch of 50 boards we built all have the same problem, in which, I cannot configure the FPGA. The only difference that I can see between a good board and a bad board is that on a bad board the CONF_DONE pin is stuck low out of POR and remains low forever. On a good board, the CONF_DONE pin is high out of POR, is driven low when configuration starts and released high when the configuration process is complete. I'm configuring the FPGA from a Microchip/Atmel AVR32 MCU using the Passive Serial (Standard POR) scheme (MSEL pins = GND). The nSTATUS pin seems to function as specified at the start of configuration and does not get driven low during data transfer to indicate an Error. The board has been proven and working this whole time so we thought that maybe the Assembly house didn't place the FPGA's correctly or maybe damaged the parts in their process. We had them replace FPGA's on a few bad boards and we ended up still having the same problem. The nCONFIG, nSTATUS, and CONF_DONE pins all have 10K pull-ups that are connected properly. I checked that the voltages (+1.2VCCINT, +2.5VCCA, +3.3VCCIO) are stable and that they are ramping up correctly and within the specified time. The rest of the board is also operating as specified.I attached images of the configuration process on both a good and bad board. You cannot make out the data stream (even though it is the same for both boards) but you can see the difference between the CONF_DONE pins. I'm not really sure what else to do at this point. Unfortunately, this problem is holding up production. Does anyone have an Idea on what is going on?
The fact that CONF_DONE never goes high, even before configuration starts, may indicate a problem with the CONF_DONE pullup. It does not look like you're stuck in POR because nSTATUS is held low during POR and that is not happening.Do you have a JTAG connector on the board? If so, it would be interesting to know what Quartus sees in the JTAG chain.
I thought the same thing but I validated that the pull-up is measuring 10K Ohms. I checked that it is at least connected to +3.3V and the VIA thats connected to the ball pad (this is a BGA package). The only thing I do not know is whether the trace between the pad and the VIA is broken, however, I think this is unlikely. I checked that their is a good trace on a raw PCB so if it were broken it would have had to happen to all 50 boards during the assembly process. One thought that I had was that maybe the I/O bank of the FPGA that the CONF_DONE pin is under never powered up. The CONF_DONE pin is part of Bank 6 and the nSTATUS pin is part of Bank 1. This might explain why part of the chip seems to be working and not the other. If this is the case then my problem could simply be that the Assembly house failed to properly solder the FPGA to the board both times. This also seems unlikely as they have successfully built this board for us a couple times in the past.I did put the JTAG interface in the design but it has not been used because the other serial method has been working. I will look into this as well.
Still sounds to me like CONF_DONE is the problem. If the 10k pullup is in place and tied to +3.3V then the only possibility is that the line is being held low by something. Where all does CONF_DONE go on the board? Just the AVR? Is it possible that the AVR is holding the line low? Anything else? What is the resistance from CONF_DONE to GND?
The CONF_DONE pin is only connected to the AVR. I thought the same thing so I lifted the AVR pin and the problem was still there. The resistance between CONF_DONE and GND is 10K.