Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20704 Discussions

Cyclone II programming problems

Altera_Forum
Honored Contributor II
3,379 Views

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
0 Kudos
17 Replies
Altera_Forum
Honored Contributor II
933 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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!
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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(?)
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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

0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

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.

0 Kudos
Altera_Forum
Honored Contributor II
933 Views

Hello, 

 

it would be interesting, which USB Blaster revision shows the error. With revisison B, a ca. 100 ohms series resistor at TCK (there's already a 10 ohms resistor mounted as R14) could also help in many cases. 

 

Regards, 

Frank
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

 

--- Quote Start ---  

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 

--- Quote End ---  

 

 

Hi Riemer, 

 

Appreciate your time to post a reply. 

I've done exactly following your method but the FPGA still failed to configure. Instead, I have my first 2 PCBs that working fine on both JTAG and AS programming. But my 3 PCBs after that were only able to configure through AS but not JTAG at all. I'm wonder what else will be the cause.  

 

From my observations, the nCONFIG cant be pulled high to VCC (sometimes at the 1.xx V level) when power up the board. CONFIG_DONE has no response at all while downloading through JTAG. nSTATUS sometimes showing a pulse train and sometimes may not. 

 

Both JTAG and AS showing "Info: Configuration succeeded -- 1 device(s) configured" with no error. 

 

Hope you able to enlighten me with other posibble solutions. 

 

Regards, 

Dennis
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

Hello Dennis, 

 

from your report, I guess that's a special problem related to your hardware and most likely can't be identified without examining all hardware details (supply voltages, circuitry at all pins affecting configuration). Also an assembly issue or part defect should be considered. I assume, that AS and JTAG configuration actually was using an identical compiled design (sounds obvious, but ain't necessarily so...). 

 

However, I didn't experience a similar problem with a lot of Cyclone II designs during the last years. If it's caused by JTAG signal quality (particularly ringing TCK), as other reports suggest, this should be seen watching the respective signals. 

 

Regards, 

Frank
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

 

--- Quote Start ---  

Hello Dennis, 

 

from your report, I guess that's a special problem related to your hardware and most likely can't be identified without examining all hardware details (supply voltages, circuitry at all pins affecting configuration). Also an assembly issue or part defect should be considered. I assume, that AS and JTAG configuration actually was using an identical compiled design (sounds obvious, but ain't necessarily so...). 

 

However, I didn't experience a similar problem with a lot of Cyclone II designs during the last years. If it's caused by JTAG signal quality (particularly ringing TCK), as other reports suggest, this should be seen watching the respective signals. 

 

Regards, 

Frank 

--- Quote End ---  

 

 

Hi Frank, 

 

Thanks for the reply. 

 

For hardware wise related issues, several attempts had been applied through. For your information, all the PCBs were fabricated at the same time by 1 vendor (means same batch). I also tried to isolate all the supply voltage circuitry and pumped in external supply but still getting the same resuly. I even assembly the board with the mere basic FPGA and JTAG circuitry only with external supply.  

 

The weird situation is: 

2PCBs have no problem on JTAG and AS. 

3PCBs have no problem on AS but JTAG. 

 

In conclusion, all the AS is working fine but not JTAG on 3 PCBs. So i cant relate the problems on boards/assembly/chips issue. 

 

I'll try to capture and compare the screenshot for all the JTAG signals on working PCB vs non-working PCB. 

 

Regards, 

Dennis
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

Hello, 

 

I see, that you have been working very seriously on the problem. However, the issue looks really strange and unusual to me, there must be a simple, understandable reason.  

To my opinion, Cyclone II configuration is rather easy to get along with, e. g. AS configuration memory programming is more sensitive to signal quality issues than JTAG. I can program Cyclone II JTAG with USB Blaster through a 1 meter IDC cable with no problems on all boards, I have ever used. I still wonder, if there is something special in wiring of configuration related pins in your design. 

 

Regards, 

Frank
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

Hi, 

 

I'm able to solve (or maybe partially solve) the JTAG problem by enable the "Halt on-chip configuration controller" under Quartus II software. This option prevent AS reconfiguration loops from the blank series configuration device

 

I wonder isn't that the main cause of the problem as if not mistaken, JTAG configuration takes precedence over other configurations. 

 

Further more, my other 2 PCBs have not such symptom with that option turned off. And also, JTAG not working even with the absent of series configuration device, hence "Halt on-chip configuration controller" options should not applicable to it. 

 

Regards, 

Dennis
0 Kudos
Altera_Forum
Honored Contributor II
933 Views

Hello Dennis, 

 

thanks for mentioning the interesting option. I wasn't aware of it's existence, but also didn't experience yet similar problems. If the description given in the Quartus Handbook is correct, I wonder why the option has been almost hidden in options menu? 

 

 

--- Quote Start ---  

halt on-chip configuration controller 

Halts the on-chip auto-configuration controller of the FPGA device for AS configuration, or the configuration device for PS or Fast Passive Parallel (FPP) configuration to allow JTAG configuration through a download cable. If you want to configure your FPGA through JTAG 

while the FPGA MSEL pins are set to AS mode, you should halt the on-chip configuration controller if any of the following occurs: 

● the active serial configuration device connected to your FPGA is blank 

● the active serial configuration device is not present 

● an error occurs during AS configuration prior to JTAG configuration 

quartus ii version 7.2 handbook 

--- Quote End ---  

 

 

Regards, 

Frank
0 Kudos
Reply