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_ForumHi again.
This is coming a bit late, but I redesigned my PCB and made sure the MSEL pins were connected correctly for Active Serial programming. I also added a connector for AS, to be on the safe side. It works fine this time, so it would seem that it was only the MSEL pins that were incorrect. Apparently, when Altera wrote "JTAG-based configuration takes precedence over other configuration schemes, which means the MSEL pin settings are ignored." in the datasheet they also meant that another configuration scheme needed to be selected. Thank you so much for your help, Carlhermann! :)- Altera_Forum
Ok, now you just have to use small, tiny wires, push them through your drilled holes and position them to contact all MSEL pin to GND - shouldn't be a "Mission impossible", should it?
Just kidding :-) - Altera_Forum
Drilling the MSEL holes didn't help.
Seems like I have to do a redesign after all. - Altera_Forum--- Quote Start --- Hey, so you've got your instructions... Come on - take some tiny wire and do it, it's just only a FBGA... :-) --- Quote End --- Hehe, my thought exactly! :D Edit: Just so there's no misunderstanding, I didn't get any instructions from Altera until a few hours ago.. Edit 2: Actually, I like your idea. I'll have to check if I have access to the tools though, but I'll try to give it a shot. I'm not sure the MSEL-pins will have a weak pull-up though, but it's worth a shot.
- Altera_Forum
Hey, so you've got your instructions... Come on - take some tiny wire and do it, it's just only a FBGA... :-)
(Sorry for the sarcasm) Well - based on the layout, perhaps you can use a small drill to open the connection of MSEL1 (H12) to GND by drillling the via (my Layout is somewhat standard and thus any Pad for the BGA is routed to a via crossing the complete board (no burried via). If your's is similar, maybe the internal weak pull ups will do the job to get the system running.. Ok - this still is not as recommended in the handbook (don't leave MSEL pins floating)... Except some additional minutes of worktime there seems to be less to loose, as the board itself in the actual configuration seems to be unuseable so far.. - Altera_Forum
I did actually file a service request. The suggestion I got was to set the MSEL pins to a correct combination. Damn it!
- Altera_Forum
Hi,
the Conf_Done (High/Low) is taken by Boundary Scan, thus the status is "measured" w/o being physically connected to the JTAG I/F. Maybe it's worth filing a service request at ALTERA - perhaps you really found that magic MSELx combination... - 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.. - 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
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...
