Spartan-3e JTAG no device id
Alan Nishioka
1. impact reads 0x00000000 as idcode
This causes impact to error out during identify with a strange
error about missing bsdl's
2. JTAG works using impact debug mode. I can put it in bypass and
also see the length of the instruction register. I can see data
shifting in and out so I know JTAG works.
3. Part markings are:
XC3250E
TQ144AGQ0601
D1392255A0
4C
so it is a step 0 part.
4. I have tried impact 8.1.3 and 9.1
5. I get identical results with two pc boards.
6. Same software / computer / cable setup works fine with a virtex2p
design.
7. All power supplies look good. (1.2Vint, 2.5Vaux, 3.3Vio)
8. spartan-3e is the only part in the JTAG chain.
I have tried removing all the parts except the spartan and power to
make sure nothing else was interfering with it.
I have not made any progress with my Avnet FAE and Xilinx webcase so I
thought to try here.
I have run out of things to try. Does this look familiar to anyone?
Any ideas to try?
Alan Nishioka
al...@nishioka.com
Antti
Alan Nishioka
Yes. Originally it had a 10K pullup. One of the things I tried was
lifting this pin so it relies on the internal pullup. Also measured
high with a scope.
Alan
Antti
>
> - Zitierten Text anzeigen -
and you are not pulling init_b low either?
strange I had no issues with 250e on my self made boards
Antti
austin
I even hate to bring this up, but how do we know it really is the part
it is supposed to be? We have seen counterfeit parts (some odd die,
packaged, and marked as Xilinx) sold to unsuspecting people by "gray
market" resellers...
If it doesn't wake up, and say "I am the Xilinx FPGA you expect me to
be" perhaps it isn't?
I certainly hope this is a simple case of a mis-wired pcb, and not a
case of bogus components sold to an unsuspecting buyer.
Austin
austin
Further, we have seen where old board test continuity systems apply
voltages (and currents) that my damage the newer 90nm and smaller devices.
I certainly hope no one exceeded the absolute maximum voltage stress
limits, and has damaged the parts.
Austin
Alan Nishioka
I bought them from Avnet, so hopefully they are not counterfeit.
Xilinx thinks it is a software problem, but I am pretty sure it is a
hardware problem.
Again, it seems JTAG works, but the internals don't. How is this
possible?
But I have run out of ideas to try.
Alan Nishioka
Alan Nishioka
No testing was done (this is a new board bring up)
The same micrel mic2204 power supplies were used successfully with a
virtex2p design (spartan-3e swapped in to lower cost; slightly
different vint used).
Is there a reason spartan-3e would behave differently than virtex2p?
Could this be caused by the ramp up of vint?
Alan Nishioka
Tim (one of many)
> Again, it seems JTAG works, but the internals don't. How is this
> possible?
>
> But I have run out of ideas to try.
Can you restrap the mode pins and try slave serial mode? That might give
you a clue.
Alan Nishioka
I have tried changing the mode pins (difficult because they are
connected directly to V33 and gnd) to no effect. But JTAG should work
regardless of the mode pin settings, right?
Thanks,
Alan Nishioka
austin
No, this is not an issue of the ramp of any supplies....
I would look for something very simple, and basic, like an open, or a short.
Austin
austin
Mode pins have no effect on JTAG.
Austin
austin
http://direct.xilinx.com/bvdocs/userguides/ug332.pdf
On page 184, it details the settings for Vccaux 2.5 volt powering of the
JTAG. Perhaps, this being the only difference with V2 Pro, this may
need to be looked into?
Also, the INIT should go low, and then once the device has cleaned out,
and is ready to be configured, INIT will return high (requires a pull-up
resistor).
Holding INIT low, continues the cleanout, and prevents any further
operation (until it is released).
I am not sure, but it may be that as long as INIT is low, the JTAG state
machine may not be operating (..?..).
Austin
Tim (one of many)
> I have tried changing the mode pins (difficult because they are
> connected directly to V33 and gnd) to no effect. But JTAG should work
> regardless of the mode pin settings, right?
Yes, JTAG works in all modes. And maybe you have the mode pins set to
salve serial. Or even floating, which means that the default pullups
pull them to slave serial, depending on the HSWAP pin.
What I was suggesting is that you try programming the part in slave
serial mode. That could show up any one of a host of problems. If slave
serial works and JTAG doesn't...
Good luck.
austin
INIT is not the signal that holds the JTAG block in reset, it is the
PROG signal, or the power ON reset.
So, if the core voltage AND the Vccaux AND the IO bank which has the
config pins on it are all powered ON, AND if the PROG_b is not being
intentionally held low, THEN the JTAG state machine should be released,
and should operate. Basically, when INIT goes high, the mode pins are
sampled, and then based on the mode pins, the configuration state
machine goes to whatever mode is specified, and proceeds with configuration.
If JTAG is specified by the mode pins, then the part waits to be
configured through the JTAG port.
JTAG device ID can be read out prior to configuring (by any mode).
Amazing what digging through the schematics reveals.
Austin
Alan Nishioka
Thank you all for your ideas. I now have a few more things to try.
Alan Nishioka
Alan Nishioka
I tried tying PROG_B to gnd on my working virtex-2p board, and
identify works fine (JTAG reads device id okay).
Is there any reason to expect spartan-3e to behave differently from
virtex-2p in this respect?
I also tried using a bench power supply for vint (in case my on board
supply was bad), but this made no difference.
My next thought is I fried the chip in some weird way and I will try
replacing it.
Alan Nishioka
austin
Holding PROG_b low should hold the JTAG state machine in reset.
I did not check the V2P schematics, so maybe they did something different.
Austin
Antti
>
> - Show quoted text -
its another try, sure.
I happen to own 3 dead FPGA boards with XC3S100E-TQ144 on them..
they are those "sample pack boards", think there is something badly
wrong with power supply on that board
so I managed to get all 3 boards to fry..
at least one of them was damaged in a way that FPGA was half dead, eg
can configure ok, but not all LUTS work
Antti
Alan Nishioka
I finally tried it with a Platform USB cable belonging to my Avnet
FAE, and it WORKED!
I had been using a Parallel Cable III (I guess I left that out). I
was certain that this would have no effect.
I still can't explain why JTAG partially works, but won't read device
id.
I would love for someone to confirm this or explain it.
My guess would be some sort of voltage incompatibility (But I was
*sure* changing the cable would have no effect, so how good are my
guesses?)
Thank you to everyone for your suggestions.
Alan Nishioka
austin
I did bring up the 2.5 volt issue, but I guess you were chasing some
other issue. Virtex 4, Spartan 3 (basically, everything since the first
90nm products) did change from 3.3 volts to 2.5 volts (3.3V
compatible...) on the JTAG. It is the "compatible" that is not so easy:
older programming cables, aren't.
Sorry you got bit by this. Glad to hear you did not have a toasted chip.
Austin
Antti
Austin,
the Xilinx "Cable problem" is pretty much serious one. It bites again
and again.
there are boards that can be programmer with USB cable or with Cable
IV both not with both.
there are boards that can be programmed using Impact 8.2 but not with
Impact 9.1
the list is endless.
so in case of Xilinx JTAG trouble:
check ALL your cables you can get hands on
try different version of software.
try impact try download with chipscope, etc..
there have been cases where chipscope can configure but impact cant,
etc...
Antti
Ulrich Bangert
I am not sure whether my own experiences have anything to do with your case
but here they are:
I had built me my own parallel-3 compatible jtag cable. Instead of 74HC125
(original) I used 74AHC125 buffers in the cable which should even perform
better in the necessary level translation. With this cable I had programmed
a lot of different Xilinx devices without any problem. Then came the day
when I tried to program an XC3S400 with this cable with pretty much the same
effect as you have noticed: Even reading the device idea failed.
The person who had developed the board with the XC3S400 on it
(http://www.siphec.com/) had also an matching download cable to sell,
developed by himself. I ordered one and see: This one worked. By looking at
the pcb I could not find any big differences to my own circuit, thats why I
contacted the developer to ask for his advice. When I told him about my
experiences he explained that he had had pretty the same problem and that he
has found an solution for it. However, as he said, while he has an solution
for it , he has NOT an deeper understanding WHY it is an solution. The
solution is to terminate the TCK line behind the 100 Ohm resistor with abt
560 Ohms to ground and it is important that this termination happens on the
driving side of the cable and not on the fpga side. That's all. I included
the termination and my cable worked like charme with the XC3S400. Weeks
later he called me on the phone to tell me that he had found a second way to
make it run: Putting 470 Ohm instead of 100 Ohm into all jtag lines had also
given him a stable result.
So while I would not warrant for 100% it seems to be more a problem of clock
conditioning than level translation. Clock conditioning in this case does
not necessarily mean that the clock generated by the cable is by some means
*bad* and needs to be conditioned. It may also be possible (which I believe
in) that the Spartan device can source/sink high amounts of current on its
TDO output and/or generate high slew rates on this pin. Both of that could
be the source of crosstalk happening on the cable which (when big enough)
may be the cause for additional false edges appearing on the TCK line.
Please note that this is an assumption and that it is not easy to verify.
Even the few picofarads capacity of an scope's probe applied to an jtag pin
may make an big difference alone when it comes to really fast signals.
Best regards
Ulrich Bangert
"Alan Nishioka" <al...@nishioka.com> schrieb im Newsbeitrag
news:1183660087....@d30g2000prg.googlegroups.com...