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

Error: CONF_DONE failed to go high in device 1.

Altera_Forum
Honored Contributor II
4,250 Views

Before anyone comments on this, I have searched the forum and read everything I have found on the internet with people getting this error message. :) 

I'll try to post as much relevant information as possible, so the next one who has this problem might get off a bit easier. 

 

"Error (209014): CONF_DONE failed to go high in device 1" 

 

The error message happens both when trying to program the Serial Flash Loader and when trying to program JTAG directly. The programming fails before there is any progress, it doesn't even say 0%.  

Auto Detect Device functions as it should though. I get the choice between EP4CE15 and EP3C16, but that has never been a problem with other designs. 

 

 

I have made a custom board with a FBGA256 Cyclone IV EP4CE15 fpga and some peripherals.  

The fpga is hooked up with JTAG for Serial Flash Loader (SFL) as described in the Device Handbook on page 218 (figure 8-29, revision november 2011). 

 

 

I'm using a 20MHz CMOS oscillator, although that shouldn't have any impact on this issue as far as I know.  

 

 

The supply voltages are derived through separate low-noise, high PSRR LDO-regulators which can deliver max 150mA each.  

They are connected as such: 

VCCIO of all IO-bank is 3,3V.  

VCCINT and VCCD_PLL is 1,2V. 

VCCA is 2,5V 

 

 

nCE (J3) is connected to ground.  

nStatus (F4), nConfig (H5) and CONF_DONE (H14) are all pulled to VCCIO by 10k resistors. 

 

 

MSEL are connected as MSEL0(H13)=2,5V, MSEL1(H12)=GND, MSEL2(G12)=GND. But since I'm using JTAG these would be overridden anyways. 

 

 

The JTAG plug is connected as such: 

1 - TCK (pin H3), pulled to GND by 1k 

2 - GND 

3 - TDO (pin J4) 

4 - 2,5V 

5 - TMS (pin J5), pulled to VCCIO by 10k.# modded this to VCCA. 

6, 7,8 - N.C. 

9 - TDI (pin H4), pulled to VCCIO by 10k.# modded this to VCCA. 

10 - GND 

 

 

Does anyone know anything I can try?
0 Kudos
37 Replies
Altera_Forum
Honored Contributor II
1,469 Views

I have tried checking the JTAG signals with a scope. While I haven't done a very thorough check of the signals against spec it does seem to be some activity on all the lines.

0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Things I have noticed:  

1. DEV_OE and INIT_DONE are each connected to a LED to ground with 470ohm resistors. They light up for a moment when I click the program-button in the Device Programmer. They both give 3,3V. 

 

- When INIT_DONE lights up, this should mean that the FPGA has entered "User Mode". But what does it mean when it goes high for a moment and then low again?  

Might this be the registers initializing to a high value or something like that before configuration? 

 

More things I have tried: 

2. Checking the box for Compressed Bitstream. No effect. 

3. Enabling device-wide output enable (DEV_OE) and reset (DEV_CLRn) as per suggestions in another thread. No effect. 

4. Disconnecting the LEDs on DEV_OE and INIT_DONE, suspecting they'd overload the output. No effect.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Does anyone have a suggestion? 

 

Edit:  

I have manufactured a new board, but the same error is still persisting.  

 

I have tried disconnecting the 2,5V from pin 6 on the jtag-plug. That had no effect either.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

I have probed the JTAG signals (see pictures below).  

 

Is this normal waveform?  

This pattern repeats itself for a little while when I press the program-button, and then nothing. 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6714  

TCK 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6715  

TDI 

 

https://www.alteraforum.com/forum/attachment.php?attachmentid=6716  

TDO
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

 

--- Quote Start ---  

 

VCCD_PLL and VCCA is 2,5V 

... 

The JTAG plug is connected as such: 

... 

4 - 2,5V 

 

--- Quote End ---  

 

Please, check your schematic.  

- VCCD_PLL must be 1.2V for Cyclone IV (handbook, vol.1, chap.11, page 2) 

- JTAG pin 4 is a target VCCIO (3.3V in your case) 

- JTAG pin 6 (nCS) is an output from JTAG, leave it unconnected.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

 

--- Quote Start ---  

Please, check your schematic.  

- VCCD_PLL must be 1.2V for Cyclone IV (handbook, vol.1, chap.11, page 2) 

 

--- Quote End ---  

 

I'm sorry. That was a typo. It is connected to 1.2V.  

 

 

--- Quote Start ---  

Please, check your schematic.  

- JTAG pin 4 is a target VCCIO (3.3V in your case) 

 

--- Quote End ---  

 

Are you sure? The Device Handbook says to use 2,5V as far as I can comprehend.  

And in the figure (fig. 8-29) pin 4 is connected to VCCA (which is 2,5V), unfortunately. 

 

The Device Handbook says the following about the pin: 

" Power up the VCC of the EthernetBlaster, ByteBlaster II, USB-Blaster, or ByteBlasterMV cable with a 2.5- V VCCA supply. 

Third-party programmers must switch to 2.5 V. Pin 4 of the header is a VCC power supply for the MasterBlaster cable. 

The MasterBlaster cable can receive power from either 5.0- or 3.3-V circuit boards, DC power supply, or 5.0 V from 

the USB cable. For this value, refer to the MasterBlaster Serial/USB Communications Cable User Guide." 

 

 

--- Quote Start ---  

Please, check your schematic.  

- JTAG pin 6 (nCS) is an output from JTAG, leave it unconnected. 

--- Quote End ---  

 

Yes, I've realized that mistake. I have disconnected it, but I forgot to post it. 

 

 

Edit: 

I've tried using 1k pull-up on CONF_DONE as well. That had no effect either. The pesky pin holds low anyways. 

 

Edit 2: 

While I was reading the Device Handbook again to check up on the 2,5V on pin 4 I came to notice that I have pulled TMS and TDI to VCCIO(3,3V) instead of VCCA(2,5V). I will try to mod this ASAP.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

 

--- Quote Start ---  

 

While I was reading the Device Handbook again to check up on the 2,5V on pin 4 I came to notice that I have pulled TMS and TDI to VCCIO(3,3V) instead of VCCA(2,5V). I will try to mod this ASAP. 

--- Quote End ---  

 

 

This had no effect unfortunately.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Ok. So you can auto-detect your FPGA, CONF_DONE toggless and pll voltage is ok. Can you now check fpga supply voltages with oscilloscope at the rising edge of conf_done?

0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

 

--- Quote Start ---  

Ok. So you can auto-detect your FPGA, CONF_DONE toggless and pll voltage is ok. Can you now check fpga supply voltages with oscilloscope at the rising edge of conf_done? 

--- Quote End ---  

 

 

No, CONF_DONE never toggles. It just stays low from start up.  

 

I have checked the supply voltages to verify that they don't dip or anything like that. So that part should be OK. 

 

 

Edit: 

According to this app note it would seem that the FPGA is in Configuration Mode. I don't know if that has any implications though.. 

http://www.altera.com/literature/hb/cfg/cfg_cf51001.pdf
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Hi there, 

I think the JTAG I/F should be ok regards voltages and pulls as otherwise the programmer would state a "device not found" or similar message. Additionally you can (or most likely already did) use the "Auto detect" function to check the JTAG itself. If there is anything wrong with the JTAG, the device would not be found at all.  

Next is (in my opinion) to check, that you have not (unintended) activated the "enablel user supplied start up clock" option (settings => device => device and pin options => General).  

And even while it may be really stupid to ask this - the target device selected in quartus matches the Cyclone on Hardware? Are there any external Watchdog devices installed that should be "served" to prevent them to reset the FPGA (and if so - is there the required code in the file?) 

In my opinion (assuming the JTAG I/F is working) this sounds more like some mismatch between the configured device and the hardware... 

 

Best regards
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Ok - one thing left..  

Check the conf_Done and nconfig Pins on power up of the board. Both should be high for a quite short time until the FPGA is running (this would cause e.g. the pulled Conf_Done to be lowered by the FPGA). If the Conf_Done is low from power up there seems to be more likely something else grounding this pin...
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

I have measured the statup with the oscilloscope now. From power-up Conf_Done is low while nConfig and nStatus are both high.  

 

The only thing enabled in the device and pin options are auto-restarting configuration when there are errors.  

 

I've triple checked that I'm using the right device. Unfortunately I'm using the right one. :( 

 

 

I even tried removing the EPCS4 part now, to see if there could be any problem with it trying to configure and block me or something. No luck with that either. 

 

Edit: 

The CONF_DONE actually goes high when trying to program. It has a risetime of 4us and is high for about 15ms.  

 

Why doesn't Quartus see this as well? And shouldn't it stay high?
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Hi, 

one thing I got wrong (I hooked up my scope to check) is the CONF_DONE pin which is definitely low from power up.  

If the nConfig is high, there is nothing on your circuit triggering a reconfiguration (e.g. the EPCS4). It definitely seems like the configuration data are not matching the device as the pin is raised only for fault free configuration data received and configuration being completed... Using a *.sof not targeting the device detected ends in "Can't configure device. Expected JTAG ID code... for device 1, but found JTAG ID code ...". 

This seems to eliminate the "false target device" option. 

One last: Which version of QuartusII are you using for generation of the *.sof? Have you tried to compile with "generated compressed bitstream" disabled? (There was one QuartusII release that failed generation of compressed bitstreams...) 

 

HTH 

 

I can offer you to try your's sof on my board to countercheck if the file or the HW is causing the trouble anyhow.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

I'm using Quartus 11.1 Build 259. I have also tried both compressed and uncompressed bitstream. 

The firmware I'm trying to program is at the moment (for testing purposes) a simple nor-gate. I can email it to you if you think it would be any point in testing it.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Hi,  

I don't know whether it is worth or not, but if you create an archive and send this I'll try it on my PCB also using an EP4CE15. If it's operative, it's time for a closer look on the hardware (or the fabrication, maybe there is a short or something else beneath the FBGA), if it doesn't it's some configuration stuff..
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Thanks for the offer. I've sent you a PM. 

 

Edit: I just realized I could post the archive here. So here it is.
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Hi, 

while I cannot rate if this is good or bad news.. I do not get any error message programming the *.sof via JTAG. Thus there is either something left on the PCB not being as it should be or the solder joints beneath the FBGA are not really ok... At least you have to focus on the HW now :-) 

 

Best regards
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

Ok, one final..  

Have you already configured other boards with the PC you are using at the moment?  

(just to be 100% sure it's not some USB-Blaster driver issue as often mentioned for 64Bit OS (Win7 or even XP)).
0 Kudos
Altera_Forum
Honored Contributor II
1,469 Views

 

--- Quote Start ---  

Ok, one final..  

Have you already configured other boards with the PC you are using at the moment?  

(just to be 100% sure it's not some USB-Blaster driver issue as often mentioned for 64Bit OS (Win7 or even XP)). 

--- Quote End ---  

 

 

I've tried two different pc's and two different usb-blasters.  

I had a computer specific problem when programming a Max V a while back, where the usb-blaster would work on Cyclone IV boards, Cyclone III and Max II. Just not Max V. It turned out to be a driver issue so it was the first thing I checked actually. :) 

 

 

It's bad news really, since I've tried everything hw-related that I can think of.  

 

Unfortunately I've connected the MSEL-pins in an invalid combination so I cannot hack on a provisional Active Serial either.  

 

 

Seems like I might just have to make a new pcb design and hope for the best I guess. I'm running out of ideas.
0 Kudos
Altera_Forum
Honored Contributor II
1,302 Views

Hi,  

according to my datasheet (which might be not the most recent) the combination  

MSEL0(H13)=2,5V, MSEL1(H12)=GND, MSEL2(G12)=GND 

 

is defined as Active Serial, Standard. (my configuration is MSEL0(H13)=2,5V, MSEL1(H12)=GND, MSEL2(G12)=2,5V, i.e. Active Serial fast...). As this is just the frequency of DCLK I would assume this not being anything to worry (except you need "fast mode")... 

 

Maybe you should use a DMM and measure the resistance of CONF_Done to GND (w/o board powered) - maybe there is a "hard short"?
0 Kudos
Reply