Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorCyclone III EPCS16 config FAIL
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.17 Replies
Altera_ForumHi 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
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
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
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
yep, 10k connected directly to CONF_DONE it's a weird one. all clock and data lines look good too.
- 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
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
