Forum Discussion

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

Quartus II and Cyclone II problems

I have two problems, one on each of two boards, though both boards use the same FPGA (EP2C8) and the same PROM (EPCS4). I'm using a parallel port ByteBlaster II to program.

Problem 1: On board A, I completed and loaded my firmware a few months ago, though found out recently that I needed to make some slight changes. After tweaking my VHDL code, I had to reinstall Quartus II thanks to some licensing weirdness before I could compile, convert to .jic, and load. When I finally did so, I found that all outputs from the FPGA were stuck high. My code changes were very slight and this problem cannot be attributed them. I reloaded my old (good) .jic and found that the hardware (and programmer) was still functional.

I then went back to the source files for that old .jic file, recompiled, converted, and loaded. The outputs were again stuck high. It seems that some compiler settings must've changed during my reinstall, though I can't figure out what. The .qsf that Quartus outputs looks OK, so it didn't try to overwrite my I/O assignments.

Problem 2: On board B, I'm unable to program. When I try to load my .jic, I get a "Flash Loader IP not loaded on device 1" error. However, when I take an older board B (same hardware configuration) that has previously been programmed, I am able to load the same .jic file that wouldn't load on the newer board B. I'm going over all of the components on the board to make sure that everything has been installed correctly, and so far it looks like I'm OK. Is there anything that needs to be done for the initial load of an FPGA/PROM? I thought that everything needed was packaged in the .jic.

Thanks for any help. As you can probably tell, FPGAs aren't my area of expertise!

4 Replies

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

    Can't say anything regarding problem 1, except I didn't yet experience Quartus II to do things not set by the user.

    Regarding problem 2, it seems to be exactly what the error message says, no design containing an SFL instance is loaded at that time. Did you try to load the factory default SFL *.sof file, shipped with Quartus?
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    Can't say anything regarding problem 1, except I didn't yet experience Quartus II to do things not set by the user.

    Regarding problem 2, it seems to be exactly what the error message says, no design containing an SFL instance is loaded at that time. Did you try to load the factory default SFL *.sof file, shipped with Quartus?

    --- Quote End ---

    Thanks for your response. In the programmer window, when I add my .jic file, it shows "Factory default SFL" next to the EP2C8Q208 and the EPCS4 below, so that led me to believe that I was loading the necessary flash loader on the FPGA. The FPGA load is successful when trying the .jic, but it fails when it goes onto the second step - loading the EPCS4.

    In any case, I tried what you said (loading the .sof that ships with Quartus). That too is successful, but I get the same error message when it goes to load the flash device. One issue that I noticed was that the device that is listed when I add the sfl_EP2C8.sof is the EP2C8F256, not the Q208 package. I can't switch it to the proper device.

    As an aside, I erased one of the good boards that already has been programmed and did allow me to reprogram. Once erased it has the same problem as the new boards, so this is definitely a Quartus/programming issue, not a hardware issue.

    Thanks for your help.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    It may be the case, that the JTAG loaded configuration has been removed by a reconfiguration attempt in-between, e. g. by some hardware activating NCONFIG.

    Sometimes, tt may be necessary to check halt on-chip configuration controller in Tools - Options - Programmer.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    17 years ago

    --- Quote Start ---

    It may be the case, that the JTAG loaded configuration has been removed by a reconfiguration attempt in-between, e. g. by some hardware activating NCONFIG.

    Sometimes, tt may be necessary to check halt on-chip configuration controller in Tools - Options - Programmer.

    --- Quote End ---

    It looks like that was the problem - the NCONFIG pin, though pulled high, is connected to a voltage monitor. I suppose it was tripping after the SFL was loaded but before the PROM was loaded.

    Thanks for your help.