--Solved--

[newMeat1]

Hello,

I can't offer much more than 1 BTC but I would be much obliged if an FPGA guru would help solve my JTAG issue for an FPGA.

The problem comes when I try to program my EP4CE75F23 with Quartus Programmer. I get an "Error: Can't access JTAG chain" message.

If I go into the JTAG Debugger tool, I can run an automatic test on the JTAG. This is the result of that test:

It's interesting that it recognizes the chip as an EP3C80.

I can also step through the JTAG state machine to see if the JTAG header pins cycle. TDO and TMS cycle from 0 to ~2.5V as expected. TDI is stuck low. TCK is stuck high.

I've gone through and double-checked that my JTAG-related pins are connected like pg 46 of this document:
http://www.altera.com/literature/hb/cyclone-iv/cyiv-51008.pdf

I've got no reason to suspect that the chip was harmed, and the soldering looks good. All of the bus voltages are good as well. I'll check the clock input to the chip with an oscilloscope later today, but I'm pretty sure it's good, too.

I'm skeptical of my USB-blaster, because I bought it cheap on eBay. It may not be working right. That would explain why TDI is stuck, but I don't think it explains TCK.

To all the smart people out there- thanks in advance.

[1713307076]

1713307076

[1713307076]

1713307076

[makomk]

It's interesting that it recognizes the chip as an EP3C80.

If I'm reading the Cyclone III and IV handbooks correctly, the EP3C80 and EP4CE75 have exactly the same JTAG ID, so that's not surprising.

I can also step through the JTAG state machine to see if the JTAG header pins cycle. TDO and TMS cycle from 0 to ~2.5V as expected. TDI is stuck low. TCK is stuck high.

This seems odd. Are you sure you're measuring the right pins? It's getting late, but I can't see how TDO could be toggling if TCK is stuck...

Edit: Also, I assume you've pulled nCE to GND like the diagram instructs.
Edit 2: Oh, and pulled nCONFIG high, either through whatever non-JTAG method of loading bitstreams you've got or directly if you don't have one.

[newMeat1]

If I'm reading the Cyclone III and IV handbooks correctly, the EP3C80 and EP4CE75 have exactly the same JTAG ID, so that's not surprising.

OK, that's good to know.

Are you sure you're measuring the right pins? It's getting late, but I can't see how TDO could be toggling if TCK is stuck...

Yeah, I just checked. The pin cycling behavior that I described is what's going on.

Both your edits are accounted for, too  

I'm thinking more and more that it's the USB-Blaster, since TDI and TCK both come from it

[fpgaminer]

This seems odd. Are you sure you're measuring the right pins? It's getting late, but I can't see how TDO could be toggling if TCK is stuck...

I agree. There's no way to get an IDCODE without toggling TCK.

You should have a pull-down resistor on TCK. If you disconnect the USB-Blaster, is Pin 1, TCK, low? And is TDI being pulled high with the USB-Blaster disconnected?

I'm skeptical of my USB-blaster, because I bought it cheap on eBay. It may not be working right. That would explain why TDI is stuck, but I don't think it explains TCK.

Do you have a bit-banging device to drive those pins manually from your PC? Maybe even switches and LEDs on a breadboard to create your own little bit-banging device. You could manually test JTAG that way and see if the problem was with your USB-Blaster.

[makomk]

Yeah, I just checked. The pin cycling behavior that I described is what's going on.

Both your edits are accounted for, too  

Curious. I'm all out of ideas, so it's good to see fpgaminer is here.

[newMeat1]

I think it's moving between states because I use the Debug tool to force it. That's why TCK doesn't have to toggle. In fact, maybe it's not supposed to and then TDI is my only problem.

Edit: yep, TCK has a pulldown resistor and goes low when I unplug the usb-blaster

TDI has a pullup resistor and goes high as soon as I unplug the USB-blaster. So it's got to be the blaster that is forcing TCK high and TDI low...

[fpgaminer]

I think it's moving between states because I use the Debug tool to force it. That's why TCK doesn't have to toggle. In fact, maybe it's not supposed to and then TDI is my only problem.

State won't change without a cycle of TCK. From the Device Handbook you linked:

Transitions in the state machine occur on the rising edge of TCK

How are you measuring the pins? With a multimeter or logic analyzer? If you're using a multimeter, perhaps Quartus leaves TCK high when idle, so when you tell it to change state it quickly toggles TCK low and then high, which you wouldn't be able to see on a multimeter. The same may be true of TDI; Quartus holding it low when idle, and only changing it when it needs to perform an operation.

My educated guess is that TDI is the only issue, because TCK, TDO, and TMS are all needed to get the IDCODE, unless I've read the process of reading IDCODE wrong.

Hooking TDI, TCK, and TMS from your USB-Blaster to a logic analyzer would reveal if it is correctly switching those signals, and narrow the problem down.

[newMeat1]

Yeah, I was using a multimeter.

I don't have a logic analyzer but I do have access to an O-scope. That should work well enough. I'll give your idea a shot tomorrow

EDIT: And I understand what you guys are saying about IDCODEs now. That's a very good sign that it could read so many bits

[fpgaminer]

Quick note: I didn't know much about JTAG's specifics, so I found this tutorial on it to be very helpful. It gives it in terms of a PC controlling a parallel port adapter, with C code.

[newMeat1]

Well, did you know a real Altera usb-blaster is $300? Highway robbery. At least Terasic is only $50

[fpgaminer]

Well, did you know a real Altera usb-blaster is $300? Highway robbery. At least Terasic is only $50

Xilinx's is about the same price  Surprisingly, though, my $8 knock-off USB-Blaster works better than the $50 Terasic one  The Terasic one wouldn't program some on-board flash chips I had, but the cheapo $8 one did 

[bcforum]

A board schematic would help.