Cyclone IV E JTAG issues - VCCA voltage level

[Altera_Forum]

Hi all, I have a custom board with Cyclone IV E (EP4CE115-F484).  

 I am trying to access it via JTAG from Quartus, but keep receiving the "Error: Can't access JTAG chain".   I check the Quartus and USB Blaster by scanning a chain on a devkit board and it worked fine. So I assume my SW and USB BLASTER is ok.  One of the issues on my board is that I need to run banks 1,2,5,6 at 1V8 and bank 3,4,7,8 at 3V3.   Thus all the banks are powered. AND the JTAG bank (believe it is Bank1 is powered at 1V8) - question: is this ok?  My pins to the Blaster header are TCK pulled down by 2k7, TDI and TMS pulled up to 1V8 by 10k. Tdo just comes from the Cyclone Pin4 and Pin 6 on blaster is tied to 1V8 - question: is this ok? and of course pin 2 and 10 to GND.  The other issue I might have had is that the VCCA is also powered to 1V8. I read in the handbook somewhere that it should be 2V5.- question: is this ok? I doubt if this is the problem, since I have now changed the 1v8 rail to 2v5 (this all the pin that used to be at 1v8 is now at 2v5) and the problem persists  I have probed all 4 signals and there is activity on them all. however: TCK only switches to almost 1V2 (which is the VccINT level) - the clock is normally low (due to the pull down) TDO is normally low and switches high (2V) during config (not quick data pulses but more like high for the config attempt off about 330ms, then low for 26ms, then high again for 72ms, thereafter low) TDI is normally high(pull up to 2v5) and switches during config. The pattern is: High, then low for 68ms, then high for 285ms then low again for 86ms, thereafter high. TMS is normally high(pull up to 2v5) and switches during config. The pattern is low at the same time as TMS for 82ms, then high for 283ms then low again for 80ms.  Triggering the scope on the TMS signal, the following is obvious: 1. The TDO is almost a exact inverse of the TMS. 2. The TMS signal frames the TDI signal as expected 3. The TCK signal is only active during the first portion of the TMS signal, but at much lower voltage.  The other config signals are: nCE = Gnd MSEL 0 - 3 = 0100 nStatus pulled to 1V8 via 10k ConfDone pulled to 1V8 via 10k nConfig pulled to 1V8 via 10k  actually, just realised a possible cause: The device text on top is ep4ce15f23i8LN - meaning 1V0 Core voltage. I am driving it at 1V2. Could this be it? Have not seen any smoke coming out.:o  Please, any hints, tips, words of wisdom are welcome. I have done many FPGA boards in my career, but this one has me boggled.  If need be, I can attach config section of schematic and maybe some photos of the scope signals. But let see if their is something VERY STUPID I am doing (that's except for the 1V2 on 1V core)  Regards

[Altera_Forum]

Hi, 

I took a look in the handbook and maybe you could check something additional...  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 (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... 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...  I'll cross fingers :-)

[Altera_Forum]

Good 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

[Altera_Forum]

Hi, 

well the VCCA is why the slogan "you need just two voltages for the FPGA" some time ago is not valid when you have to interface with 3.3V logic... I struggled once on this "you need to connect VCCA to 2.5V" also on my first Cyclone II board...  While I have currently no clue for the nStatus (assuming there is only the FPGA and the Pull-Up on the line) the "wrong" identification on JTAG is ok... Strange enough the ID reported by the Cyclone IV and III are identical thus the "Auto detect" reports a Cyclone IV as a Cyclone III - you have to correct this to proceed with JTAG configuration...  Referring to ohmic measurements on FPGA pins - be careful when you are using a standard DMM - ohmic measurements are taken (normally) by application of voltage and measurement of currents.. If the DMM applies a measurement voltage above 3.3V, this will either result in internal clamping diodes on the FPGA (which are normally not active w/o being configured) or other I/O structure to get conductive... Sometimes with predamaging the I/O structure - just as a hint...  Nevertheless there is something tying TDI to GND (most likely the Blaster - are there not even some pulses? E.g. on "Auto-Detect"?)  Carlhermann

[Altera_Forum]

--- Quote Start ---  well the VCCA is why the slogan "you need just two voltages for the FPGA" some time ago is not valid when you have to interface with 3.3V logic... I struggled once on this "you need to connect VCCA to 2.5V" also on my first Cyclone II board...  --- Quote End ---   Yeah, there are a lot of traps in FPGA design, like pll config etc. I wish I could say this mistake is because it is my first board, but it is because it has been awhile since I did an FPGA board.    --- Quote Start ---  While I have currently no clue for the nStatus (assuming there is only the FPGA and the Pull-Up on the line)   --- Quote End ---   Checked again, nStatus is only connected to 10k pullup to 2v5.    --- Quote Start ---  the "wrong" identification on JTAG is ok... Strange enough the ID reported by the Cyclone IV and III are identical thus the "Auto detect" reports a Cyclone IV as a Cyclone III - you have to correct this to proceed with JTAG configuration...   --- Quote End ---   Ok, that is sort of good news. So the detection as an EP3S16 is normal for autodetect. I will remember to fix in programmer. This could have bugged me for a while, thanks for mentioning it.    --- Quote Start ---  Referring to ohmic measurements on FPGA pins - be careful when you are using a standard DMM - ohmic measurements are taken (normally) by application of voltage and measurement of currents.. If the DMM applies a measurement voltage above 3.3V, this will either result in internal clamping diodes on the FPGA (which are normally not active w/o being configured) or other I/O structure to get conductive... Sometimes with predamaging the I/O structure - just as a hint...   --- Quote End ---   Yip, noted, I suppose I could have damaged the pin, BUT I only measured this after it did not work. Also, I think it is highly unlikely that such a sort event would harm the device. But will keep it in mind.    --- Quote Start ---  Nevertheless there is something tying TDI to GND (most likely the Blaster - are there not even some pulses? E.g. on "Auto-Detect"?)  --- Quote End ---   I put the scope on again, Ch2 on TCK and CH2 on TDI. both normally low (TDI should be high) and this is the case with BB plugged or unplugged. Plugging BB in and running detect has clock signal toggling but nothing on TDI. Well, let me qualify that. I drop the scope voltage setting down to 10mV/DIV and then picked up some "noisy" signals on the TDI to a p-p of about 30mV. Probably the blaster doing his best to drive the signal to 2V5 or the noise feeding in during the tristated periods.   tdi low and the status pin remains the unsolved mysteries... 

[Altera_Forum]

Hi, 

well - if there is only TDI and a pull-up on this Pin and the pin did some pulses initially, even being incorrectly driven with TCK in your first wiring, this TDI perm. low seems strange as both pins are driven by same "output power" from the BB point of view...)... If the TDI pin is low as soon as the Cyclone is powered this indicates more or less that either the pull-up is missing or the device itself has a short on the input when being under bias. Second is less repairable :-/

[Altera_Forum]

Yip, this is the conclusion that I come to as well. If the nStatus was not doing it as well, I would have programmed the EPC and let it program the FPGA, but chances are this will not work either. So the other option is to replace the BGA and hope it solves the both the issues. 

 Thanks for your ideas and view. Any other (related ;>) ) brainwaves please let me know.  I will respond back with the results. ( I will also AGAIN check the pull up)  Vielen dank  Ivor

[Altera_Forum]

Hi, 

in case you are about to remove the BGA, I would suggest to use this replacement as an option to check the correct voltages at the power pins, configuration pins ans the interconnection between these pins and the pulls... Just to ensure that everything is ok with the PCB itself...  It's difficult to measure at the pins with BGAs... :-)

[Altera_Forum]

--- Quote Start ---  Hi, in case you are about to remove the BGA, I would suggest to use this replacement as an option to check the correct voltages at the power pins, configuration pins ans the interconnection between these pins and the pulls... Just to ensure that everything is ok with the PCB itself...  It's difficult to measure at the pins with BGAs... :-)  --- Quote End ---    Got the second board of the two that were built the same time. Before applying ANY power, I adjusted all the voltage rail to be as follows: Vccint = 1.015V Vcca = 2.423 Vccio = 3.273  The JTAG pins bank has VCIO of 2.423 volt.  All pull ups are checked.  nConfig goes high, nStatus seems to try to go high, but then is pulled low again, this happens every 65us.  Look very much like a POR event, but the voltages looks in range. Also checked the voltages on the scope and they are not drooping.  Any idea why the device would keep resetting. and why every 65us?

[Altera_Forum]

hi, 

"trying to go high" sounds not like there is a stable (even perhaps short) pulse but some rise in voltage which does not really reach anything near to a high level...  This definitely - as there is nothing than the Pullup and the Pin being connected to the line - indicates the Cyclone not finishing POR. The question is "why?" Can you be 100% sure, that there is no mistake in layout or manufacturing that disconnects either on of the power or gnd pins (thus triggering the Built-In Brown-Out / Power fail detection reset) and that the pull-Up is wired to the Cyclone / the 2.5V?  nStatus is bidirectional, thus if e.g. the Pull-Up is broken, not soldered correctly or not connected to VCCIO the missing "High" is detected and restarts configuration... Maybe worth checking...   Is there anything connected to nConfig that externally resets the Cyclone (nStatus goes low with nConfig being driven low) or is nConfig initially going high and remains a stable High? Besides what's written in the handbook... I may have to recheck this, but iirc  * nconfig goes high => reset condition removed * nStatus goes high => internal device reset "do this an that" completed, device can accept configuration data * Conf_Done goes high with device configured  Even with no data (e.g. blank Config device or nothing by JTAG) the nStatus should stay high as long as there is no interrupt on the power lines...  (having read through the configuration section I did not really found the magic 65µs...)

[Altera_Forum]

CarlHermann, First I want to thank you for supporting me during this problem. It helps an incredible amount to have someone to bounce ideas off, and to generate new paths of investigation. I really do appreciate your help. 

   --- Quote Start ---  "trying to go high" sounds not like there is a stable (even perhaps short) pulse but some rise in voltage which does not really reach anything near to a high level...  This definitely - as there is nothing than the Pullup and the Pin being connected to the line - indicates the Cyclone not finishing POR. The question is "why?"  --- Quote End ---   I agree with this.    --- Quote Start ---  Can you be 100% sure, that there is no mistake in layout or manufacturing that disconnects either on of the power or gnd pins (thus triggering the Built-In Brown-Out / Power fail detection reset) and that the pull-Up is wired to the Cyclone / the 2.5V?  nStatus is bidirectional, thus if e.g. the Pull-Up is broken, not soldered correctly or not connected to VCCIO the missing "High" is detected and restarts configuration... Maybe worth checking...   --- Quote End ---   You hit the nail on the head. Last night while staring at the pulses on nStats, I measured each of the voltage rails. Later I realised that I never actually measured the voltages on ALL the fpga power vias. So I did that last night (about midnight) and low and behold, the VCCINT has some disconnected pins. I have a regulator at the point of load feeding into the via grid under the FPGA, but for some reason ( I suspect incorrect copper pour sequence) the VCCINT section got split in two by a ground section. This should have been pick up by the DRC as an unconnected route. I will check later as to why I missed the DRC error.  I decided last night it would be better to remeasure all the pins again and then do the mode while I am fresh. I will report back with the results.    --- Quote Start ---  Is there anything connected to nConfig that externally resets the Cyclone (nStatus goes low with nConfig being driven low) or is nConfig initially going high and remains a stable High? Besides what's written in the handbook... I may have to recheck this, but iirc  * nconfig goes high => reset condition removed * nStatus goes high => internal device reset "do this an that" completed, device can accept configuration data * Conf_Done goes high with device configured  Even with no data (e.g. blank Config device or nothing by JTAG) the nStatus should stay high as long as there is no interrupt on the power lines...  (having read through the configuration section I did not really found the magic 65µs...)  --- Quote End ---   I have read the handbooks like crazy but also did not find anything about the 65us. As far as nConfig goes, I did have an EPCS16 on board, but I disabled it for the JTAG testing, so the nConfig goes high(according to scope) and never triggers low again.

[Altera_Forum]

Bummer, I must have made a mistake last night. All the rails are indeed correct. Which is good since I then did not miss a DRC error. 

 I measured each power pin on its via while triggering the scope on the nStatus pulse so make sure the rail is ok and that there is no voltage dip when the device tries to come out of reset. All pins are ok.  I attached 2 scope shots, one showing the recurring nStatus pulse and the second same pulse, but zoomed in a bit more.  I also attach the sch for the power and config page. (the pullups for the TDI and TMS and pulldown of TCK is on the top level at the connector). On the FPGA connection, where you see 1V2,# define to 1V and 1V8 is# define 2V5 after the rail adjustments I made. I am not planning on using any plls, this i did not bother with separating the pll rails from the int rails.  Let me know if you see something weird.  EDIT: If I pull nConfig low, the pulse on nStatus obviously goes away (device being in reset) and then reappears when nConfig released.  EDIT: did some more measurements and photo3 shows the nStatus pulse together with the DCLK signal.  Again, I appreciate the help.  Ivor

[Altera_Forum]

I wish there was a document showing the startup state machine of the FPGA, i.e. how the resets are done and at what voltage level a rail is considered good. 

Then showing the states as the device tries to get config data after reading msel etc.  Then at least one can follow some process of debugging the problem.

[Altera_Forum]

Hi there, 

I assume U23 is some level shifter - I'm not quite sure if this may not cause timing issues when configuration is to be loaded from the EPCS4 as this defintely adds twice to the timing on DCLK and Data..   Some things to mention: The configuration scheme (0010) is for active serial, 3.3V(!). As you wrote 1.8 => 2.5V, the EPCS is powered by 2.5V, this requires MSEL configuration as (0011)... The DCLK being some quite strange signal (more a sawtooth rather an rectangular signal) - is this due to the scope's limitation (bandwidth)? I have to check the rise time on my board for nStatus, but even this signal seems for me to be not really "quick" enough at High level..   Nevermind - if the DCLK is operated by the Cyclone, this indicates the FPGA is out of internal reset and as there are just two "blocks" I would assume there must be some problem with the configuration data (is there any pof stored in the EPCS). Seems like the configuration cycle ends as the internal configuration controller does either not receive any data (put the scope on Data0) or the received data indicate not being for this EP4CE115...  I'll try to record these signals on my board meanwhile...

[Altera_Forum]

--- Quote Start ---  Hi there, I assume U23 is some level shifter - I'm not quite sure if this may not cause timing issues when configuration is to be loaded from the EPCS4 as this defintely adds twice to the timing on DCLK and Data..   Some things to mention: The configuration scheme (0010) is for active serial, 3.3V(!). As you wrote 1.8 => 2.5V, the EPCS is powered by 2.5V, this requires MSEL configuration as (0011)... The DCLK being some quite strange signal (more a sawtooth rather an rectangular signal) - is this due to the scope's limitation (bandwidth)? I have to check the rise time on my board for nStatus, but even this signal seems for me to be not really "quick" enough at High level..   Nevermind - if the DCLK is operated by the Cyclone, this indicates the FPGA is out of internal reset and as there are just two "blocks" I would assume there must be some problem with the configuration data (is there any pof stored in the EPCS). Seems like the configuration cycle ends as the internal configuration controller does either not receive any data (put the scope on Data0) or the received data indicate not being for this EP4CE115...  I'll try to record these signals on my board meanwhile...  --- Quote End ---    Yes, it is a level converter. The one side connects to FPGA @ 2V5 and the other to EPCS @ 3V3, so it should be ok. BUT, I am not there yet. The EPCS is still blank and I have disabled the level converter. I have found out that the status line is going high and at about 1V2 the device is officially out of reset. Thus DCLK start to see if it can configure, but since EPCS is blank, it fails and then later tries again.  This is all good news since it means the device is happy with the power rails.  So now I am back to the JTAG port. 1. Power is ok and POR can complete 2. TCK to device is looking good at 2V5 (very little overshoot) 3. TMS to device is looking good at 2V5 4. TDI to device is also looking good 5. tdo responds to all of this but the level is sub 1v  Added a pullup to the TDO, still same voltage Disconnected pull up and wire from Blaster, voltage out of TDO still just 1V. Quartus jtag debugger says the TDO is stuck to ground, which makes sense since the 1V signal is looking like a low to the blaster.

[Altera_Forum]

Well, some success at last. 

 I cut the TDO track and inserted a tiniLogic buffer i there to lift the level of TDO to 2V5.  Now the JTAG works, the device configured and enters user mode normally.  I have a single LED active!  NEXT STEP: get the EPCS16 programmed and booted from.

[Altera_Forum]

Well, 

that sounds very strange.. if there is nothing on the "Output side" of the tiny logic that has a low impedance (or is a high capacitive load) that kills the TDO Output when driven by the cyclone, I'd assume there is still something strange on your board... Nevermind the Input of the tiny logic is a very high impedance thus I'd still assume either the supply of the TDO "bank" is not as stable as it should be or the board has some bug on the TDO line. Have you checked the TDO Signal on the tiny logic Input to be a valid Signal? Otherwise - I'm afraid - this fix might not last very Long...  But that should not minimize my lob for your work on the Problem :-D

[Altera_Forum]

Yeah, thanks, the thing is, the TDO signal is JUST A TRACK to the header, no pullup, pull downs, nothing. So my suspicion is that possible the pin driver got damaged by the USB blaster. It could be that the USB blaster is damaged, putting to high a load on the TDO pin, thus damaging it. 

 BUT, whilst I can program, I will try to sort out the configuration from the EPCS through the TXB0304. I can tell you I did not spend a lot of time on selecting this device and will probably pay the price now. The datasheet shows it can handle 150Mbs, so I figured it would be ok for the config data.