Cyclone III AS configuration bizarreness

[Altera_Forum]

I am using a cyclone III (EP3C25F324C8N) with an EPCS16 configuration device. 

I am programming the configuration device through the FPGA with the serial flash loader. The problem is that the Cyclone III device will not configure itself from the EPCS16. It is stuck in an endless loop of retries UNTIL I MOMENTARILY SHORT THE nSTATUS PIN TO 3.3 VOLTS!!!! (...I discovered this by accident, no grounding the pin doesn't do it.)  As soon as I do that the device configures and runs my test program (blinks LEDs). I also tried driving it high momentarily with an 8051 to no avail.   Any ideas?   Thanks, Rob  UPDATE: It also configured when I touched CONF_DONE with a probe. Upon further investigation I found that adding a 100 pF capacitor from CONF_DONE to GND fixes this problem ...no idea why.

[Altera_Forum]

I suppose they could have added aa extra NOOP byte (or something) at the end of the configuration file to make sure all required data was in the FPGA before CONF_DONE asserts.

[Altera_Forum]

I can add another bizarre behavior. I have custom board with 3C10. I use PS configuration using serial port of DSP processor. The serial port TX register is 32 bit wide, so I can send 32 bits at once. There is a pause between the 32 bit bursts. I took care of all the timing in few gates ( I used the same approach on several other boards with 6000 and 8000 FPGAs). If I run the FPGA configuration function, the /STATUS goes low after 84 32 bit configuration words sent out through the serial port. If I put a 75 us pause between the two 32 bit bursts, everything looks OK. The software sends all configuration bits to the 3C10 and /STATUS line stays high. 

However, the /CONFIG_DONE never goes high and 3C10 never switches to user mode. I am stuck, my project is turning into a disaster and I can not do anything. I have requested Altera tech support, but they are useless. The guy insists on using JPEG port to try to program 3C10 and I keep telling him that I do not have JTAG pins connected to a connector. I have captured a bunch of serial stream waveforms, everything looks ok. I am clocking data at 8MHz rate, while the max clock speed is 133MHz. I have planty of setup and hold time. I tried another board (I have two) and it exhibited the same problem. I switched from compressed stream into uncompressed stream, it did not help a bit. I am running out of time. Can anybody help?

[Altera_Forum]

I just can say, that PS configuration is generally operating, also with C III. It doesn't require any delay in addition to the specified timing. I don't know exactly, at which points the serial bit stream is checked for errors, but I expect that you have either a problem at the physical level (signal quality, e.g. ringing DCLK) or at the logical level (wrong data). That probably sounds banal, but it's likely anyway.  

 Personally, I would never design a board without a JTAG interface, at least accessable at test points. The issue may be caused, by the way, also by floating TCK and TMS inputs, they must be hold during power up and programming at their idle levels.

[Altera_Forum]

Thank you for the post. I am running at very low frequency (8.192MHz), therfore, waveforms look very clean. I confirmed that using an osciloscope.  

I had the probes atttached to CLK and DATA while I was programming the FPGA so if the probes are reason for clean waveforms, they were attached  during the whole event. I do not think that data is wrong because with 75 us pause between the bursts the /STATUS never goes low, which should mean that all checksums are OK. I am so confused...

[Altera_Forum]

I have a similar problem and just as described, while probing either nCONFIG lines or nCONFIG_DONE things started to work from then on. 

 Has anyone discovered or solved what causes this erratic configuration problem?

[Altera_Forum]

Yes! The power pad at the bootom of the chip HAS TO BE GROUNDED !!!! 

Otherwise, strange things can happen ...

[Altera_Forum]

In actuality, I'm seeing the problem on a Cyclone I not III but the symptoms are extremely similar. My device does not have a power pad on the bottom. 

(240-Pin Plastic Quad Flat Pack)    Sure enough while probing on the configuration lines with the scope the device configured, from that point kept working. Anyone else has resolved this issue or has an explanation to what may be causing it?       Thank you!

[Altera_Forum]

In that case I do not know. Only thing I can suggest is to slow down the clock and make sure that JTAG pins are pulled up/down to inactive level, as the guru said few posts above. 

 Good luck.

[Altera_Forum]

Hi all, 

I encounter exactly the same "bizarre" problem, using an EP3Q240C8 on a homemade board.The reconfig in AS mode (with an EPCS16) is only effective when the dclk pin from the fpga is link to the usb blaster dclk pin, or to a probe, or just to a wire. I can't understand at all why disturb the dclk wire fix the problem. Morover when i see this topic it's not a totally isolate unique lucky fix.

[Altera_Forum]

It could be because you have bad overshoots on the clock signal that disturb the configuration. Just connecting something adds enough parasitical capacitance to smooth the signal. You can try and add a small resistor in series with the dclk signal or a small capacitor in parallel. If you have a scope with an attenuated probe that has a lower capacitance, maybe you can try and observe the signal without disturbing it.

[Altera_Forum]

You possibly need an active probe to see the CLK signal undistorbed, The final cause for configuration problems related to JTAG signal quaility is often a non-monotic, ringing CLK edge, which is seen as double clock edge by the JTAG logic. A small capacitive load like the 10 or 12 pF of a standard passive 10:1 oscilloscope probe can be already sufficient to fix the problem.  

 Placing a small capacitor, e.g. 15 or 22 pF between TCK and ground near the FPGA would be my first try to solve issue.