Cyclone IV configuration - nCONFIG signal and JTAG programming issue

[Altera_Forum]

Hi, 

 I have a custom board for EP4CE22E22 Cyclone IV FPGA. I have configured the board for JTAG only mode and using USB Blaster Rev.B for programming. The problem I am facing is that JTAG Scan fails with "JTAG chain Broken" error. The signal levels are are follows:  AT POWER UP:  nSTATUS -> HIGH (A0 on attached figure) nCONFIG -> LOW (Screen shot from logic analyzer shows that nConfig (A1 on figure) goes low after 4ms but this duration is random and sometimes it stays high for several ms) TCK -> LOW TDI -> HIGH TMS -> HIGH TDO -> LOW nCE -> LOW  DURING JTAG SCAN:  nSTATUS -> HIGH nCONFIG -> LOW TCK -> Square wave with varying duty cycle TDI -> Toggle few times (Some Bit stream) TMS -> Toggles few times (Some Bit stream) TDO -> LOW   Voltage Levels / Connections): VCCINT: 1.2V VCCIO : 3.3V (All VCCIOs) VCCA : 2.5V E-PAD : GND JTAG Connector -PIN 4: 3.3V nCONFIG : Pulled high by a 10K resistor (VCCIO) nSTATUS : Pulled high by 10k resistor (VCCIO) TCK : Pulled low by 1K  TDI : Pulled high by 10K (VCCA) TMS: Pulled high by 10K (VCCA) TDO : NO pull-up / down nCE: GND MSEL[2:0] : GND   According to Cyclone IV handbook the nCONFIG is an input pin but it looks like FPGA is driving it low after power ON, Why is that? Any ideas why JTAG chain scan failing on my board?  Thanks

[Altera_Forum]

Hi, 

 according to the Cyclone IV handbook, pin 4 of the USB Blaster connector should be tied to VCCA, which s 2.5V in your case, but you connect it to 3.3V. It is not quite clear to me what the USB Blaster does with that signal, so I'm not sure if that is really bad.  However, what bothers me is that you say that nCONFIG goes low. I agree that this pin should be high, since you pull it high, and the Cyclone IV really doesn't seem to have a driver for that pin. Did you check, e.g. using a multimeter that VCCIO is stable? Maybe the DC-DC comes up properly, but then goes into CC or hiccup-mode, which would explain why nCONFIG shows a random timing when going low again.  Another stupid idea: is it possible that you accidentally used the very same pull-up resistor for both nSTATUS and nCONFIG? Or that these are too close together and shorted during soldering? That would also explain, as nSTATUS is driven low by the FPGA immediately after power-up.   Best regards, GooGooCluster

[Altera_Forum]

Hi, 

 nConfig problem is solved. The E-PAD was not properly connected to GND :). However JTAG is still not working (JTAG Chain Broken). The snap shot of different signals is attached:  A0: TCK A1: TDO A2: TMS A3: TDI A4: nSTATUS A5: nCONFIG  There is no activity on TDO which stays high all the time. Any ideas why is that ?   Thanks

[Altera_Forum]

You shouldn't have nSTATUS high without nCONFIG high. It's your responsibility to 'drive' nCONFIG. This could well amount to a simple pull-up resistor. I'd suggest you either have a manufacturing fault or one (or more) of your power pins are not powered. Check them all. 

 The JTAG will not work unless nCONFIG is high.  Yes, you should power your USB-Blaster from VCCA (2.5V). However, this is a common design fault that is not likely to be, or cause you, a problem. I do recommend you correct it, by modifying your board, and certainly if you re-spin the board.  If connected for JTAG only you should also ensure DCLK and DATA0 are drive high or low (whichever is convenient), don't leave them floating.  Refer to Table 8-20 on page 8-64 of the configuration and remote system upgrades in cyclone iv devices (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/cyclone-iv/cyiv-51008.pdf) for an explanation of the relevant configuration pins. Also note the behavior of nCONFIG and nSTATUS in any of the 'Configuration Timing Waveform' figures.  Cheers, Alex

[Altera_Forum]

How should i check either Cyclone IV has some kind of manufacturing issue. Because I am facing same kind of problem with my custom board. nConfig and nStatus are at 3V3. Epad is properly connected. But still not been able to configure via JTAG or AP. 

  Regards

[Altera_Forum]

--- Quote Start ---  You shouldn't have nSTATUS high without nCONFIG high. It's your responsibility to 'drive' nCONFIG. This could well amount to a simple pull-up resistor. I'd suggest you either have a manufacturing fault or one (or more) of your power pins are not powered. Check them all.  The JTAG will not work unless nCONFIG is high.  Yes, you should power your USB-Blaster from VCCA (2.5V). However, this is a common design fault that is not likely to be, or cause you, a problem. I do recommend you correct it, by modifying your board, and certainly if you re-spin the board.  If connected for JTAG only you should also ensure DCLK and DATA0 are drive high or low (whichever is convenient), don't leave them floating.  Refer to Table 8-20 on page 8-64 of the configuration and remote system upgrades in cyclone iv devices (https://www.altera.com/content/dam/altera-www/global/en_us/pdfs/literature/hb/cyclone-iv/cyiv-51008.pdf) for an explanation of the relevant configuration pins. Also note the behavior of nCONFIG and nSTATUS in any of the 'Configuration Timing Waveform' figures.  Cheers, Alex  --- Quote End ---    Hi Alex,  Yes, in my design both nCONFIG & nSTATUS are pulled high by a 10K resistor to VCCIO. You can see in the latest attachment that both nSTATUS (A4) and nCONFIG (A5) signals are high during JTAG scan. It was unconnected E-pad that was causing nConfig to go LOW.   I forgot to mention, both DCLK and DATA0 are also tied to VCCIO. I have also tried to perform JTAG scan with 2.5V on Pin.4 of JTAG connector (Powering USB Blaster) but TDO remains stuck at High.

[Altera_Forum]

Well done on fixing nCONFIG. You still need to check all the power and ground pins are connected up. Beyond that the bare minimum you need to allow JTAG to work is: 

 nCE low. nCONFIG pulled up. nSTATUS pulled up. MSEL pins connected to GND or VCCA (2.5V). DCLK & DATA0 at valid levels.  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  Well done on fixing nCONFIG. You still need to check all the power and ground pins are connected up. Beyond that the bare minimum you need to allow JTAG to work is:  nCE low. nCONFIG pulled up. nSTATUS pulled up. MSEL pins connected to GND or VCCA (2.5V). DCLK & DATA0 at valid levels.  Cheers, Alex  --- Quote End ---    Thanks Alex. JTAG is working now and I am getting correct IDCODE. Now when I try to program any SOF file, the progress bar moves till 75% and then programming Fails. Is there a way to know what operation is failing during JTAG programming ? Further I am using EP4CE22E22 Chip while "AUTO DETECT" operation shows only EP4CE22.

[Altera_Forum]

Signal integrity. I've had similar, intermittent issues before and it turned out to be a signal integrity issue between the USB-Blaster and the board. How are you programming the FPGA? Using a USB-Blaster or something else? 

 What revision is the USB-Blaster? The older units - rev A especially - have trouble with the newer FPGA families (I count Cyclone IV in that). Do you have particularly long JTAG traces on your PCB?  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  Signal integrity. I've had similar, intermittent issues before and it turned out to be a signal integrity issue between the USB-Blaster and the board. How are you programming the FPGA? Using a USB-Blaster or something else?  What revision is the USB-Blaster? The older units - rev A especially - have trouble with the newer FPGA families (I count Cyclone IV in that). Do you have particularly long JTAG traces on your PCB?  Cheers, Alex  --- Quote End ---    I am using USB Blaster Rev.B. Traces on PCB are not long (< 1 cm) but the JTAG cable is ribbon type about 6 inches in length. Could that be an issue with new FPGAs?

[Altera_Forum]

--- Quote Start ---  I am using USB Blaster Rev.B. Traces on PCB are not long (< 1 cm) but the JTAG cable is ribbon type about 6 inches in length. Could that be an issue with new FPGAs?  --- Quote End ---     I think it is not the problem with long JTAG cable as I have program my Altera cyclone II custom board with same JTAG length of cable. So is there any who can let me know that there is a problem with Rev of USB Blaster.

[Altera_Forum]

The rev B cable was updated to rev C to overcome this issue. The change was to move to a flex-rigid cable - the electronics in the USB-Blaster are unchanged. 

 So, you can get yourself a rev C cable and you'll be away. Alternatively, I suggest you shorten the ribbon cable on your rev B and you'll be happier, since won't have forked out for a new cable. I have several rev B cables all working happily with the new parts. See attached pic. Note - you don't need to go nearly as short as this!  Cheers, Alex

[Altera_Forum]

--- Quote Start ---  The rev B cable was updated to rev C to overcome this issue. The change was to move to a flex-rigid cable - the electronics in the USB-Blaster are unchanged.  So, you can get yourself a rev C cable and you'll be away. Alternatively, I suggest you shorten the ribbon cable on your rev B and you'll be happier, since won't have forked out for a new cable. I have several rev B cables all working happily with the new parts. See attached pic. Note - you don't need to go nearly as short as this!  Cheers, Alex  --- Quote End ---    Thanks Alex, We have sort out the issue. Apparently there was a dry solder connection on the PCB and after applying some hot air on FPGA pins the problem disappeared :).  now The board works fine with "SOF" files but the FPGA won't reconfigure after power cycle. I have both JTAG and AS mode connectors on the board and tried both POF and JIC files to program the EPCS64 chip. The quartus programmer shows 100% success but reconfiguration doesn't happen after power cycle.   After some try and error, I noticed that if I left the JTAG cable connected to the AS header of the board (and connect the USB end to PC) the FPGA reconfigures successfully upon power up. I wonder if there is a Licence issue of some kind , even though my code is a simple counter program in verilog without any IP cores from Altera?

[Altera_Forum]

No it can't be a license problem. If you had some Opencores IP it would only work when uploading the .sof file using the programmer and you wouldn't be allowed to flash the design into the EPCS. 

I would rather look for some earthing/grounding problems. When you connect the USB blaster to your board and the PC, you connect your board's ground plane to earth. Another possibility is load on the JTAG pins or the VCC power plane connected to the JTAG connector. Do you have pull-up/pulldown resistors on the FPGA's JTAG pins? It's not required but depending on your PCB design they could pick up noise during startup that would disturb the start-up process.