Cyclone III EPCS16 config FAIL

[Altera_Forum]

Hi all, 

 I'm working on a revision of a PCB that contains a total of 12 EP3C16Q240C8N all configured with the same object file as in figure 10-6 of the datasheet. As it stands now, the configuration never succeeds (continually repeats and fails). Something that seems odd to me is that CONF_DONE briefly starts to rise before nSTATUS gets pulled low, restarting the cycle. I uploaded the image as CONF_DONE-and-nSTATUS.jpg The top (yellow) trace is CONF_DONE and the bottom (blue) is nSTATUS. Is this typical of a failed config?  I have the DATA and DCLK lines buffered as follows: the EPCS feeds the master FPGA directly along with a pair of buffers. Each of these buffers then feeds a pair of slave devices and another set of buffers, which feeds another pair, and so on, up to a maximum of three buffers in the signal chain. I did things this way, up to two buffers in the signal chain in my first revision and after some initial struggle, now have no configuration issues with that board. As far as I can tell with my 200MHz scope, the signal looks pretty good, even at the end of the chain. I've uploaded the image as data_and_clock.jpg Perhaps someone with more experience in this department will have a different opinion?  What does anyone suggest for a debugging methodology? I'm thinking of starting to break the nSTATUS and CONF_DONE connections on a chip-by-chip basis to see if I can isolate one or more chips that is causing the problem. Does this seem like a good idea? My thought is to cut as few traces as possible and to also keep the load on the buffers consistent through the testing. Do I also need to break nCONFIG to keep a chip from triggering a global fail?  Any ideas are much appreciated!  Thanks, -Nick.

[Altera_Forum]

Hi Nick, 

 Have you found a solution yet?    I'm having a similar problem when configuring in AS mode via an EPCS16, where nstatus is pulling low as conf_done rises. This is using a stratix2gx with AES encryption key programmed.   The FPGA does boot however when I leave the ethernet blaster cable connected (I mean physically just the cable, not the programmer!)   Fitting a capacitor of between 66pF and 330pF between conf_done and GND is allowing the FPGA to boot without the cable fitted, just need to know why now!    Let me know if you've found anything different.   Cheers   Andrew

[Altera_Forum]

Hey Guys, 

 Just wanted to check, do you have CONF_DONE hooked up to a 10K pull-up resistor? Just wanted to make sure before people start throwing crazy suggestions your way. Good luck!  Chris

[Altera_Forum]

yep, 10k connected directly to CONF_DONE it's a weird one. all clock and data lines look good too.

[Altera_Forum]

from the altera knowledge base: 

 problem  is a 10k pull-up resistor mandatory on the conf_done signal or can i use a 1k pull-up resistor?   solution  Yes, a 10k pull up resistor is mandatory on the CONF_DONE signal. A 1k pull-up resistor may cause CONF_DONE to rise too early, causing the target FPGA to reset and thus cause configuration failure.  However, I had similar issues with the Conf_Done on the Cyclone 3 device in Active Serial mode where the Conf_Done did not rise fast enough. Just the opposite of the Altera note.  The Cyclone 3 utilizes a faster configuration clock. I have to wonder if the timing of the status checks have increased proportionally as a result. Would be interesting to know.  I'm looking to find more information regarding the timing on the Conf_Done, nStatus, etc upon configuration completion. Anyone have any good timing diagrams and specifications? Apparently, a status test routine samples the Conf_Done sometime after configuration completes.  And, I currently don't understand what Altera is describing about Conf_Done rising too fast.  In any case, I had one out of four boards that would successfully configure via Active Serial. All have 10K pull-ups on Conf_Done. If I add capacitance to the --working-- board (scope probe, tweezers, etc), the board will --not-- configure.   As a result, it seems that the rise time was not fast enough. I replaced the 10K with 5K decreasing the rise time. Now the boards configure fine.  I'm going to stick with the 5K until I can determine the root cause of the difference further. Please let me know if anyone is able to solve their problem by changing the pull-up as well.   Regards, Jay Vicory

[Altera_Forum]

I am having a similiar problem. When I power up my board, the nStatus line settles at about 0.9V. When I try and configure the device (3C16 and 3C80), the Config_Done line goes to about 1V for a few milliseconds, then drops to 0V. If I replace the 10K pullups on nStatus and Config_Done to 4.7K, the board works fine. 

 Regards, Phil Reum

[Altera_Forum]

Phil, thanks for the response. If you know, did a pull-up change on just the Conf_Done resolve this for you or did you have to change the value for both Conf_Done and nStatus? I may ask an FAE out this way to ping the factory about how this operates on the CIII. And, if the timing has changed.

[Altera_Forum]

Hi All, 

 i have 10K Pullup to 3.1VCC (3.1VCC for all Banks) up for config_done and n_status. Also an pulldown 10K for nCe. MSEL is switch to AS. No Problems. Programming over JTAG with *.jic also no Problem.   Your MSEL are right?  It is also possible what Jay Vicory think, it is a problem of a charge of series production?  regards Michael

[Altera_Forum]

--- Quote Start ---  Phil, thanks for the response. If you know, did a pull-up change on just the Conf_Done resolve this for you or did you have to change the value for both Conf_Done and nStatus? I may ask an FAE out this way to ping the factory about how this operates on the CIII. And, if the timing has changed.  --- Quote End ---    Jay,  I required a pullup on both done and nstatus. The device would configure with just the 4.7K on the done line, but the nstatus was still "stuck" at ~0.9V.   Phil

[Altera_Forum]

--- Quote Start ---  Hi All,  i have 10K Pullup to 3.1VCC (3.1VCC for all Banks) up for config_done and n_status. Also an pulldown 10K for nCe. MSEL is switch to AS. No Problems. Programming over JTAG with *.jic also no Problem.   Your MSEL are right?  It is also possible what Jay Vicory think, it is a problem of a charge of series production?  regards Michael  --- Quote End ---   what is *.jic file? my sycloneIII JTAG Configuration has some problem.

[Altera_Forum]

--- Quote Start ---  Jay,  I required a pullup on both done and nstatus. The device would configure with just the 4.7K on the done line, but the nstatus was still "stuck" at ~0.9V.   Phil  --- Quote End ---     Hmmm, diode drop? I'm curious, what is the voltage on the bank with the nstatus pin? How about the pull-up voltage on the done line?

[Altera_Forum]

Hi Michael 

 A JIC is a JTAG Indirect Configuration File (.jic) . You can program devices with either the Serial Flash, Parallel Flash, or Active Parallel Flash Loader schemes, with an in-system JTAG programming method. From QII Help: 

1. Use the Assembler to generate an SRAM Object File (.sof) containing the FPGA configuration data.  
2. On the File menu, click Convert Programming Files.   
3. Under Output programming file, select JTAG Indirect Configuration File (.jic) in the list.  
4. In the Configuration device list, select the target configuration device you want to program.  
5. In the File name box, type the file name for the JTAG Indirect Configuration File you want to create.  
6. To specify an existing SRAM Object File for conversion to a JTAG Indirect Configuration File, select the SOF Data item under Input files to convert and click Add File.  
7. To specify the target FPGA device that will program the configuration device, select the Flash Loader item under Input files to convert and click Add Device.   
8. To generate the JTAG Indirect Configuration File containing configuration device programming data, click OK.  
9. On the Tools menu, click Programmer.   
10. If necessary, in the Mode list, select JTAG.  
11. To add the newly created JTAG Indirect Configuration File to the programming list, click Add File in the Programmer window and select the JTAG Indirect Configuration File.  
12. In the same row as the FPGA device in the programming list, turn on the Program/Configure option.  
13. In the same row as the configuration device in the programming list, turn on the Program/Configure option.  
14. To configure the FPGA device with the Serial Flash Loader IP and then program the configuration device, click Start in the Programmer.  
15. To reconfigure the FPGA device with configuration data from the configuration device, turn the power to the FPGA device off and on. 

  regards Mikuman

[Altera_Forum]

Random thought, you didn't tie all of your conf_dun pins together and also put a 10k pull-up on each one did you? Or something similar on the nStatus pin?

[Altera_Forum]

Or do you have an LED on the CONF_DUN pin? Or protection diodes on any of the pins that may be backwards? vicorjh brought up diode drops, and if i remember without looking they like to put diodes on all the 3.3 io pins because of the ciii ioe architecture. Maybe you have one on upsidedown or something? Or hooked to ground instead of vcc?

[Altera_Forum]

--- Quote Start ---  Hmmm, diode drop? I'm curious, what is the voltage on the bank with the nstatus pin? How about the pull-up voltage on the done line?  --- Quote End ---    I think the problem is being caused by a buffer that is connected to the lines. There is a std 74lvth244 buffer that both signals are connected to. I think the bus hold circuitry is latching the inputs low on power on. I am going to replace the buffers with a non-bus hold type and see if it fixes my problem.  Phil

[Altera_Forum]

--- Quote Start ---  I think the problem is being caused by a buffer that is connected to the lines. There is a std 74lvth244 buffer that both signals are connected to. I think the bus hold circuitry is latching the inputs low on power on. I am going to replace the buffers with a non-bus hold type and see if it fixes my problem.  Phil  --- Quote End ---   I have verified that our config problem was caused by a buffer with bus hold circuitry. We disconnected the buffer and the config lines were pulled up normally. We will switch to a buffer without bus hold circuitry.

[Altera_Forum]

I have almost the same problem.. 

 My EPCS16 can't config my 3C16 while the QuartusII reports well. And my 3C16 works right through JTAG mode...

[Altera_Forum]

--- Quote Start ---  I have verified that our config problem was caused by a buffer with bus hold circuitry. We disconnected the buffer and the config lines were pulled up normally. We will switch to a buffer without bus hold circuitry.  --- Quote End ---     Hi phil:   Servral questions: 1, Are there 2 devices in your system? if so, is it necessary to add buffer? 2, After you disconnecting the buffer, were the config-done and nstatus pull-uped by 10k? or 4.7k?