Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
17 years ago

Cyclone 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

Show More
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- 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?