Honored Contributor
Honored ContributorGood morning CarlHermann, thanks for the reply.
--- Quote Start --- Acc. handbook the "Reset completed" is indicated by nConfig and nStatus both being high (ch. 8). This could validate the Cyclone is ready for configuration to check the 1.0/1.2 V issue --- Quote End --- Thanks for this great tip. 1. Checked the pullups are 10k to 2v5 2. nConfig is 2V5 3. nStatus is low any ideas on what the inputs are to the nstatus pin and what might cause the "not completing reset" issue? --- Quote Start --- (in fact, I would think the 1.2V on the Cyclone IV shall not cause direct failure (otherwise you would observe high current consumption / overload on the internal 1.2V regulator or a hot Cyclone). Nevertheless (assuming it's not a selection process like the speedgrades were on some intel Processors) this overvoltage will not extend the operational life... --- Quote End --- As you mentioned, the Cyclone does not even get warm, let alone hot. Current draw for the complete board is at 120mA --- Quote Start --- Regarding the USB-Blaster I/F (Pin4, VCCA) the Blaster must be powered by 2.5V as the internal circuits are not compatible with lower operation voltages. ("You must power up the VCC of the download cable with a 2.5-V supply from VCCA. For device using VCCIO of 1.2, 1.5, and 1.8V refer to Figure 8-24"). Thus first is to disconnect Pin4 from the board and apply 2.5V to power the USB Blaster... IMHO Besides this - the VCCA is always 2.5V (being the supply for the PLL) and must be applied even for circuits not using the PLL - maybe you also need to check the routing for the VCCA pins... --- Quote End --- I ALWAYS read the footnotes but somehow missed this specific one on the VCCA. Anyway, what I did last night at some silly hour was to remove the chip/components on the mainboard (that are connected to the 1V8 rail) and converted the rail to 2V5. Thus my VCCA pins are now 2V5 and so is the byteblaster. The other banks are at 3V3. I also adjusted the core voltage down to 1V, figuring that the FPGA "might" have some overvoltage protection that keeps it in reset. I tried this but got the same answer. Decided it is not acceptable and triple checked my jtag wiring (I added a separate header with short 30mm wires directly to FPGA JTAG) and found that I had Tdi and Tck swapped around. Fixed that and ran the JTAG debugger again and at last got "Some" result. The debugger detects an EP3S16 (which is not correct), but still gives a red cross on the TDI pin. So the chain is working better, but not correct yet. What I don't understand is why the TDI would give a problem. It is input to the FPGA from the byteblaster. I retested the BB on a devkit and it is still ok. Even with the TCK and TDI swapped, it should not damage the FPGA, both are inputs. TDI seems to be stuck to ground now. (it used to toggle when the voltages were wrong). I check with a ohm meter on TDI (power off) and the pin shows a resistance of about 820R to 2V5. The pull-up however is a 10k. I Triple checked that. I isolated only the TDI pin from the rest of the board and measured again the resistance and it is still in the 820R range. does anyone have ideas on the tdi stuck low issue? Thanks for your assistance. Every idea/tip triggers new thoughts on this side and is very much appreciated. Best regards Ivor
