Forum Discussion
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_Forum--- Quote Start --- 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")... --- Quote End --- Are you sure you're not looking at the combinations for Cyclone IV GX? In my datasheet those combinations are in the table for GX, while the combination you are using is actually the same for both. --- Quote Start --- 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"? --- Quote End --- It's a cool 2kOhm so that shouldn't pose a problem.- Altera_Forum
Uuups. My fault, indeed.. Sorry for that irritation.
While this MSEL stuff will require a modification of PCB anyway, I'm wondering what prevents JTAG operation... Especially as "The JTAG configuration is always available, regardless of MSEL pin selection.". - Altera_Forum--- Quote Start --- Uuups. My fault, indeed.. Sorry for that irritation. While this MSEL stuff will require a modification of PCB anyway, I'm wondering what prevents JTAG operation... Especially as "The JTAG configuration is always available, regardless of MSEL pin selection.". --- Quote End --- Maybe I've hit upon a magic MSEL-combination which prevents usage? That would be a bit funny I guess.
- Altera_Forum
Well, based on "engineering judgement" and experience... If one combination exists preventing operation even with JTAG, you've hit it... (other might call it "Murphy's law"...)
Nevertheless - if the JTAG chain is valid (as the Device is detected in Programmer window / JTAG chain check completes) there might be something else... Have you checked the power lines are all avaliable (VCCINT, VCCPLL and VCCIO) and stable during and with end of JTAG datatransfer? Perhaps there are some pins connected by the FPGA (as being the default for unused ones) to GND that are low ohmic connected to VCCIO on your board... Otherwise I'm running out of ideas :-/ - Altera_Forum
I have checked the lines, yes. They look fine.
Yes, I have thought about that the pins could have been connected to GND. As far as I have understood they are all tri-stated until configuration is done, since the default value is set in software..? - Altera_Forum
The default is to connect all unused Pins to GND - it might anyhow be the better solution to use the "tri-state" option...
- Altera_Forum--- Quote Start --- The default is to connect all unused Pins to GND - it might anyhow be the better solution to use the "tri-state" option... --- Quote End --- I agree, but that's after the fpga is configured. Since I can't get it to start the configuration it shouldn't matter what I choose. I did try it now anyways, just in case. It did not help.
- Altera_Forum
Ok, I went back to the first page and reviewed all posts and things done so far - did also "googled" around and hooked my scope to the pins you plotted... One thing is the TDI Pin - this should not really be just spikes as shown as this pin is used to push the information to the FPGA. It also seems that the "Auto detect" function does not use the TDI at all, as the ID Code is read by combination of TCK, TMS and TDO only, thus any problem on the TDI line would not be recognized at this stage. Maybe it is worth to have another look at the physical connections of TDI.. Should be pin9 of JTAG Header to Pin H4 with only a pull up connected...
- Altera_Forum
Ok, seems like you've used a different horizontal scaling, thus I assume the TDI signal is not only a spike but some transitions as well... If you have another board you can hook it up to the JTAG chain as second device to validate the JTAG connections are ok as the first FPGA would be in bypass when configuring the second one.. Maybe something went wrong with the layout and the signals are disturbed at the FPGA pin itself, somewhere beneath the Chip...
- Altera_Forum
Yep, I think there was something more than spikes there.
I tried the JTAG Chain Debugging tool, and tried the "Scan Data Register" and "Scan Instruction Register" commands. They both returned different results in the TDO-box for different values of TDI. Shouldn't that indicate that TDI is operational? Edit: The fact that it is able to measure that CONF_DONE is low might also indicate that TDI is indeed operational? I'm not sure how this is supposed to work..
