Forum Discussion
Altera_Forum
Honored Contributor
Honored ContributorError: CONF_DONE failed to go high in device 1.
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?37 Replies
Altera_ForumOk - 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...- Altera_Forum
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? - Altera_Forum
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. - Altera_Forum
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. - Altera_Forum
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.. - Altera_Forum
Thanks for the offer. I've sent you a PM.
Edit: I just realized I could post the archive here. So here it is. - Altera_Forum
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 - Altera_Forum
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)). - Altera_Forum--- 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.
- Altera_Forum
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"?
