Forum Discussion

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

Cyclone II programming problems

Hi all --

I've built a few PCBs based on Cyclone II FPGAs. Some of these boards, and especially the last, suffer from an annoying problem:

When connecting the FPGA to the JTAG cable, Quartus II detects and correctly identifies the Cyclone II. When I program the FPGA with a sof file, Quartus II shows me this:

Info: Started Programmer operation at Tue Jul 31 16:22:13 2007

Info: Configuring device index 1

Info: Device 1 contains JTAG ID code 0x020B20DD

Info: Configuration succeeded -- 1 device(s) configured

Info: Successfully performed operation(s)

Info: Ended Programmer operation at Tue Jul 31 16:22:15 2007

Very nice. However, the program is not loaded on the FPGA! This can also be verified by the current drawn: when programming the CylconeII, the current consumed goes up by 10 mA, and afterwards it drops again.

At this moment, the FPGA is configured as in Figure 13-25 on page 13-63 of the CycloneII handbook, only the serial ram device has not been soldered on the board. Both MODE0 and MODE1 have been connected to ground. I'm using a USB blaster, running at 3.3V. Pullups are also conected to 3.3V. Only, I'm using 1.2kOhm resistors everywhere, I don't think this can be the cause?

With previous boards, after 10 programming attemps it worked and afer a week of FPGA usage, it worked from the first time. This latest design however does not load at all.

Any comments on this are much appreciated!

Riemer

17 Replies

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

    Refering to the configuration scheme on page 13-63, have you followed the notes below the figure? Particularly, Note 2:

    (2) The nCONFIG, MSEL[1..0] pins should be connected to support a non-JTAG configuration scheme. If only JTAG configuration is used, connect nCONFIG to VCC, and MSEL[1..0] to ground. Pull DCLK either high or low, whichever is convenient on your board.

    Regards,

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

    Thanks for the fast reply. I'll you know tomorrow morning when I'm back at work.

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

    I've checked the signals you indicated. The nCONFIG pin is pulled high, but as I had not installed a programming device, I had the DCLK pin floating. Both MSEL signals are shorted to ground.

    However, shortingthe DCLK to ground did not change the situation. I removed the short, and installed the serial programming device, did not solve it either..

    To make it even more strange, after 3 minutes or so, the FPGA enters some sort of power-down more by reducing its current drain by 40mA, making it unable to detect in QuarutsII using JTAG.

    Again, all comments/thoughts are more than welcome!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    You might double check all your pin connections (i.e. VCC, GND, clocks, etc). Also, the QII software will configure unused I/O as "Output Driving Ground" which can be a big problem if one of these pins happens to be tied to VCC. You might try changing the unused I/O to "as input tri-stated" and see if this makes any difference.

    set_global_assignment -name RESERVE_ALL_UNUSED_PINS "AS INPUT TRI-STATED"

    Is the part hot to the touch before "powering down" (unless it is programmed as such, there is no power down / sleep mode that I'm aware of).

    Considering the programmer is telling you the device is configured successfully, I think it's time to look at the pin connections and/or the design(?)
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I really appreciate your effort for helping others. The ideas you give me show me you really know what you're talking about, so it's even rarer that people like respond to questions in forum.

    However, after spending a few more hours on the problem, it showed up that there was some small error (isn't it always a small error?). I'm powering my board using a source where I can limit the current, so in case I have a shortcut I don't smoke my board and supply.

    I set the current limit about 100mAmps above the idle state. Without being able to tell by looking at the source, the CycloneII requires a current boost of well over 150mAmps immediately after configuration. My source clipped the current, so the FPGA must have reset itself. By simply putting the current limit a few mAmps higher, the problem is solved.

    Again, thanks for your answers and ideas.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    I'm happy to hear you've got things working... those pesky power supplies!

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

    Hi again --

    We have made a new pcb, and we have exactly the same problem:

    When programming the Cyclone2 in Quartus2, we get this output:

    Info: Started Programmer operation at Thu Nov 22 16:24:03 2007

    Info: Configuring device index 1

    Info: Device 1 contains JTAG ID code 0x020B20DD

    Info: Configuration succeeded -- 1 device(s) configured

    Info: Successfully performed operation(s)

    Info: Ended Programmer operation at Thu Nov 22 16:24:04 2007

    But again, the fpga is not programmed at all. The design fully complies to fig 13-22 in the cyclone handbook. Some details:

    - Pulled high 10k: nStatus, CONF_DONE

    - Pulled high 1k: TMS,TDI

    - Pulled low 1k: TCK, DATA0, DCLK

    - Shorted high: nCONFIG

    - Shorted low: MODE0, MODE1

    - This time, I've set my current limiter to unlimited ;)

    The device is correctly recognised when the 'Auto detect' is pushed. During programming, current goes up 5mAmps, and lowers afterwards.

    The CONF_DONE pin stays low (while it should go high after programming). The nSTATUS shows a pulse train (38.7kHz, 9,8% duty cycle). Immediately after programming the frequency of this pulse train becomes something like 135kHz, for less then 0.5 second. After that, it returns to a 38.7kHz pulse train.

    ANY comments you have on this are more than welcome.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    Hi all,

    Good day.

    I'm facing the same problem exactly where the CONF_DONE pin stays low and the nSTATUS shows a pulse train (frequency around the same).

    I wonder what the root cause of the above problem and what solution can be apply to solve the problem. I have 2 PCBs that working fine but the rest 3 PCBs having that problems.

    Hopefully some one able to advise. Thanks in advance.

    Regards,

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

    Hi there Dennis,

    First off, sorry for this short mail but we are currently at CeBit so I don't have much spare time.

    I was able to track the problem down by trying to configure the FGPA with an old parallel ByteBlaster instead of the USB blaster. This worked fine, so I looked at the difference between their signals. Seems like the overshoot of the USBblaster is too large, so I placed a small capacitor (I think some tens of picofarads, could be more) between TCK and ground.

    This completely solved the problem!

    Let me know if this works for you as well.

    Kind regards,

    Riemer Grootjans
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    18 years ago

    It's interesting to hear that the problem can be cured by using a different Blaster. As I've said in other threads, my custom board was almost impossible to program with the Altera USB Blaster but is 100% reliable with the Terasic version. Maybe this could be an alternative cure.