Programmable Devices
CPLDs, FPGAs, SoC FPGAs, Configuration, and Transceivers
20704 Discussions

Debugging TDO on Cyclone V

Altera_Forum
Honored Contributor II
1,640 Views

Hello, 

 

I am making my first attempt at a custom Cyclone V 5CEBA4U15 board after using a rival FPGA vendor for several years, so I have probably made some rookie mistakes. The JTAG chain is broken, and I'm having a hard time understanding why. I have set MSEL to 00000. 

 

I have scoped the TCK, TMS, and TDI lines going to the chip, and can see each of them twiddling as expected when I click the "Test JTAG Chain" button in the Quartus JTAG Debugger or use the "jtagconfig" program at the command line. Signal integrity looks decent on the scope. Unfortunately, TDO never moves, so the tools correctly report that the JTAG chain is broken. 

 

Since it's a BGA, I don't have complete visibility of these signals all the way to/from the chip package, but my fab house did x-ray them today, and they looked fine. I am probing the signals in the last via before they enter the BGA. I have tried cutting the TDO trace to make sure nothing else is holding it down, and it is not shorted to power/ground. 

 

VCCPD3A, VCCPGM, and VCCIO3A are measuring 3.3v. VCC_AUX is measuring 2.5v, and VCC is measuring 1.1v . The I/O pads that I can probe are showing weak pull-up to their respective VCCIO, as expected. The configuration signals are as follow: 

 

MSEL = 00000 

nCONFIG = high 

nSTATUS = low (there is a pull-up resistor on it, so the FPGA is actively pulling it low) 

nCE = grounded 

CONF_DONE = low 

DCLK = low 

 

Since I am just using JTAG configuration, I had assumed that the power supply ramp time was irrelevant, but it is measuring approximately 60ms for the 3.3v rail and ~20ms for the 1.1v rail. 

 

What debugging steps are recommended from a situation like this, when TDO is unresponsive? I'm not quite sure what to try next. 

 

Thanks for your time, 

Morgan
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
661 Views

Since nSTATUS is low, the FPGA is indicating some form of error. Lets assume its your power-supply ramp time for now. Try shorting nCONFIG to ground and then releasing it. If nSTATUS releases (goes high), then at least you know the FPGA is now happy with its power. Then re-try JTAG access (just use Quartus to try and detect the JTAG chain) ... 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
661 Views

Hi Dave, 

 

Thank you for the quick response. 

 

I happen to have a microcontroller on this board connected to nCONFIG, so I now have it wait 500ms after power-up and then apply a 100ms negative pulse on nCONFIG. This looks fine on the scope. Unfortunately, the TDO behavior is the same. 

 

nSTATUS never releases high; it stays continually low during and after power is applied to the board. From the state diagram on page 7-4 of the Cyclone V manual, I'm not sure if this means that the chip is in the "power up," "reset," or "configuration error handling" state. Is there a way to determine this? 

 

Regards, 

Morgan
0 Kudos
Altera_Forum
Honored Contributor II
661 Views

 

--- Quote Start ---  

 

I happen to have a microcontroller on this board connected to nCONFIG, so I now have it wait 500ms after power-up and then apply a 100ms negative pulse on nCONFIG. This looks fine on the scope.  

 

--- Quote End ---  

 

Ok, that should satisfy the power-on requirements (at least it would for earlier generation devices, I have not read the Cyclone V handbook in detail). 

 

 

--- Quote Start ---  

 

Unfortunately, the TDO behavior is the same. 

 

nSTATUS never releases high; it stays continually low during and after power is applied to the board. From the state diagram on page 7-4 of the Cyclone V manual, I'm not sure if this means that the chip is in the "power up," "reset," or "configuration error handling" state. Is there a way to determine this? 

 

--- Quote End ---  

 

 

I'd recommend focusing on nSTATUS being low to start with. This signal should release after power-on-reset and nCONFIG deassertion. The fact that it is low indicates some low-level hardware error that may preclude the JTAG actually working. 

 

Do you have multiple boards? Check if this is a common problem. 

 

I'd start with the obvious checks (though you may have already done this). Look at the power supply voltages, and impedance of each power segment. If you have multiple boards, then compare their impedance. Quite often the impedance values will not be identical, but if you measure >1k on several boards, and <100-ohm on one, you can suspect it as possibly having an issue. 

 

Do you have a Cyclone V reference board? If you do, look at its power and configuration scheme. Measure its nSTATUS and nCONFIG signals at power-on. If you do not have a Cyclone V board, download a Altera kit installation file, and install it. Inside you'll find its schematic. Look at the schematic and see if anything weird jumps out at you. 

 

Cheers, 

Dave
0 Kudos
Altera_Forum
Honored Contributor II
661 Views

Hi Dave, 

 

Thank you very much for your suggestions; they pointed me in the right direction and quickly led to the problem. I had failed to understand the requirements of VCCPD on each bank. I mistakenly thought they only applied to bank 3 (which has the external JTAG signals), so I was trying to run bank 5 with VCCPD = VCCIO = 1.8v, which led to the behavior described above.  

 

The VCCPD pads are tied to VCCIO on an inaccessible layer on that bank, but I switched the entire VCCIO=VCCPD net up to 3.3v and now the JTAG chain initializes successfully. This requirement is listed on pages 5-8 and 7-5 of the manual, but I failed to grasp the concept of an i/o pre-driver supply. 

 

Thanks again for your help. 

 

Regards, 

Morgan
0 Kudos
Altera_Forum
Honored Contributor II
661 Views

Hi Morgan, 

 

--- Quote Start ---  

 

Thanks again for your help. 

 

--- Quote End ---  

 

You're welcome! 

 

Cheers, 

Dave
0 Kudos
Reply