EPC16 does not configure EP2C35 at high temperature

[Altera_Forum]

Folks, 

 I have been debugging this issue where the EPC16 device I use does not configure the EP2C35 (Cyclone II) device - at slightly high temperature. I can make it configure by cooling down both devices using freeze spray. :confused:  This is the most fascinating and ridiculous part of the problem - how could the temperature be influencing the basic config cycle??  I am using the Passive Serial mode of configuration. The programming files are proven good. I see the nCONFIG going high followed shortly by nSTATUS and after that ... nothing. The DCLK/DATA0 lines are flatlined (DATA0 continues to remain high and DCLK continues to remain low). Obviously in this case, the CONF_DONE signal does not go high at all.  See waveforms below -  Ch1 – Yellow – nCONFIG  Ch2 – Blue – nSTATUS  Ch3 – Purple – CONF_DONE  Ch4 – Green – INIT_DONE  This is a bad config cycle.  http://i41.tinypic.com/23ib0pl.jpg    On a good config cycle (same board, freezing cold ICs)...  http://i43.tinypic.com/1evt07.jpg    I verified the power up sequence - the VCCIO (3.3V) powers up first (t0). The FPGA-VCCINT (1.2V) powers up at (t0 + 69.2ms). The EPC16 is set to have a POR of 100ms. So I am assuming this powers up at (t0 + 100ms). This meets the spec.  I have tried 1K & 10K pullups on the INIT_CONF signal with no luck.  I am seeing this on 4-5 of 30 boards. On some boards the issue is a lot more aggravated than the others. One board in particular fails at room temperature. Other boards only seem to fail @ 45-55C.  I have checked to verify that the EPC16 is revC silicon.  Any ideas??

[Altera_Forum]

What does the timing of dclk and data0 look like at the fpga?

[Altera_Forum]

--- Quote Start ---  What does the timing of dclk and data0 look like at the fpga?  --- Quote End ---   During a bad cycle, the DCLK and DATA0 are dead - flatlined. During a good config cycle - they look reasonable enough. I will try to capture a waveform and post it. The CycloneII and EPC device are only a couple of inches apart.

[Altera_Forum]

Could it be a problem in the soldering process?

[Altera_Forum]

According to the waveforms, the EPC16 is simply not starting configuration after nSTATUS is deasserted. So I guess, the problem is related to this device rather than the FPGA. The reason for configuration failure can't be explained from the shown waveforms, I think. But it may be probably caused by other EPS16 signals, e. g. an incorrect terminated TCK.

[Altera_Forum]

--- Quote Start ---  Could it be a problem in the soldering process?  --- Quote End ---   I have seen this on multiple boards. I have not seen any specific issue with the soldering process on any other device on these boards.

[Altera_Forum]

--- Quote Start ---  According to the waveforms, the EPC16 is simply not starting configuration after nSTATUS is deasserted. So I guess, the problem is related to this device rather than the FPGA. The reason for configuration failure can't be explained from the shown waveforms, I think. But it may be probably caused by other EPS16 signals, e. g. an incorrect terminated TCK.  --- Quote End ---   After the nSTATUS is de-asserted, wouldn't you expect the FPGA to take over and start toggling the DCLK. Once it receives the first frame of data, it will pulldown the INIT_DONE signal.  Good thought about the TCK - I will check.

[Altera_Forum]

--- Quote Start ---  wouldn't you expect the FPGA to take over and start toggling the DCLK  --- Quote End ---   In PS mode, DCLK is controlled by the configuration device. But it's apparently never starting configuration, although all prerequisites are met according to the waveform.  Another question: What happens, if you start a configuration manually through EPC16 JTAG interface?

[Altera_Forum]

You might also check your power and grounding setup. 

Or decoupling?  These will be harder to detect with scope shots, but may be why the EPC sometimes fails at elevated temps?

[Altera_Forum]

--- Quote Start ---  In PS mode, DCLK is controlled by the configuration device. But it's apparently never starting configuration, although all prerequisites are met according to the waveform.  Another question: What happens, if you start a configuration manually through EPC16 JTAG interface?  --- Quote End ---   Yes the EPC16 definitely looks like the culprit here. The device programs fine via JTAG.

[Altera_Forum]

I collected some waveforms. 

 Here is the power up sequence - The VCCINT is up and stable 100ms after VCCIO comes up.  http://i43.tinypic.com/iei5h2.jpg    This is a zoomed out view of the good config cycle. It takes about 442ms after power for the configuration to be complete and for the CONF_DONE pin to go high.  http://i39.tinypic.com/2d85hyw.jpg   These waveforms show DCLK and DATA0 - these signals have ~2V pk-to-pk ripple on the waveforms.  http://i41.tinypic.com/2yla4r6.jpg   However, we did find something interesting.    --- Quote Start ---   Another question: What happens, if you start a configuration manually through EPC16 JTAG interface?  --- Quote End ---    Once the device does not get configured at power up (BAD CONFIG cycle), I cannot successfully program the device over JTAG. I can Auto-Detect the part - but when I try to load a file, it returns - can't recognize silicon id for device 2.  My JTAG chain looks like this  BYTE_BLASTER_HEADER --> FPGA --> EPC16  I can configure the FPGA just fine. So the TDI/TDO & TCK connections are OK. But I just cannot configure the EPC device.  However, once the device does gets configured at power up (GOOD CONFIG cycle - by freezing the EPC16), I can successfully program the device over JTAG. It does not matter if the board has been on for a while and the device is not "cold"; I can still program the EPC.   This indicates that - during power up, when it is hot, the device falls into a "bad state". This causes it to fail configuration and not respond to JTAG either. Any idea what could cause this device to go into a dead or idle state at power up?  I have checked TCK/TMS/TDI/TDO during steady state - they seem OK. I have not looked at these during power up yet.  This does feel like one step forward in some direction - not sure where.  Any ideas are much appreciated.

[Altera_Forum]

Generally, I must admit that I never used an EPC device and thus don't have any experience regarding it's particular behaviour and don't know, if there are hidden design traps or known issues.  

 From the reported observations, the problem seems to be caused by the EPC16 only, but I don't see a point how to localize it further. The previous comments on possible soldering, power supply, bypassing and grounding issues should be checked to my opinion. But it's hard to decide if these are more or less likely without knowing the design details and having the board at your fingertips.  As another comment, the (working circuit) waveforms don't look really good, the overshoot, if actually present with the shown amount, is considerably exceeding the FPGA maximum voltage range. I guess however, this may be a simple probing problem. If the design has long signal traces for the respective signals, the overshoot could be real and you're missing a source sided serial termination. But I don't think that the no-operation is related to this waveforms.  Good luck, Frank

[Altera_Forum]

Looking at the last scope image, it appears that there are some serious signal integrity issues on the board. I dont think your problem is related to the EPC16 but rather the board design.

[Altera_Forum]

--- Quote Start ---  it appears that there are some serious signal integrity issues on the board  --- Quote End ---  You're right, if the waveforms would be real. However, you easily get apparent overshoot by simply using a normal passive probe with standard ground lead.

[Altera_Forum]

It would be interesting to see the results with an active FET probe, and know that it was measured at the receiver end of the net.