Lattice XP2 getting hot and/or reading 0's as JTAG ID

Hi

I guess I am alone with the issue, but asking still :)

board(s) working ok, FPGA in SDM mode.
suddenly after some repramming FPGA

1) goes HOT, reads bad JTAG ID, can be restored to live by changing CFG mode and erasing

2) does not go hot, but reads 0's as JTAG ID, can not be restored, setting CFG0=CFG1=PROGRAMN=0 (GND) still yields 0 JTAG ID and to my surprise the NOT CONFIGURED FPGA seems to DRIVE regular IO (should be tristated unless FPGA configured)

any body had any issue?
please reply with any similar issue being seen ever.
to groups or in private

Antti

Antti <antti.lukats@googlemail.com> wrote:
> Hi
> 
> I guess I am alone with the issue, but asking still :)
> 
> board(s) working ok, FPGA in SDM mode.
> suddenly after some repramming FPGA
> 
> 1) goes HOT, reads bad JTAG ID, can be restored to live by changing CFG mode and erasing
> 
> 2) does not go hot, but reads 0's as JTAG ID, can not be restored, setting CFG0=CFG1=PROGRAMN=0 (GND) still yields 0 JTAG ID and to my surprise the NOT CONFIGURED FPGA seems to DRIVE regular IO (should be tristated unless FPGA configured)
> 
> any body had any issue?
> please reply with any similar issue being seen ever.
> to groups or in private

I've seen this once on an XP2-8E device on which the on-chip Flash was not
properly programmed, while I was experimenting with self-devised JTAG
bit-banging hw / sw design, which didn't work quite right.

Can you read back the bitstream from the on-chip Flash and verify that
it is really 100% OK?

Does the design work if downloaded directly to SRAM, leaving the on-chip
Flash untouched / erased?

Marko

Hi

thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system.

well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF.

Antti

Antti <antti.lukats@googlemail.com> wrote:
> Hi
> 
> thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system.
> 
> well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF.

When I was faced with a similar issue, my device drained more current than
the USB port to which it was hooked to could provide.

I apparently had some luck by hooking the FPGA to a better power supply,
just long enough to have it properly respond to JTAG commands and have
the on-chip Flash erased.  The chip got really hot during the process,
but still works OK today.

If all else fails, perhaps you could try to power up the chip with only
VCCJTAG provided, while disconnecting the I/O and core (1.2 V) VCC.  I
don't know if this is out of the specs, but if you already proclaimed the
chip to be dead you might try this out and let us know the outcome :)

I think the moral of the story is that one should be really careful with
programming the on-chip Flash on XP2 devices, otherwise I really like
those chips a lot.

Marko

Antti <antti.lukats@googlemail.com> wrote:
> Hi
> 
> thanks a lot for reply - but the issue is that JTAG ID is being read back as 00000000 so we can do anything.. all VME functions BAIL out if initial ID verify fails. We are using VME ver 12 player on custom ARM9 linux system.
> 
> well we could strip out ID verify from SVF file and regenerate the VME files from patched SVF.

I guess you could also try to pull down the INITN pin, in addition to having
CFG0 & CFG1 grounded, in an attempt to prevent the device to autoconfigure
from a (suspected bad) bitstream stored in the on-chip Flash.  From specs
it is not clear whether pulling down the PROGRAMN pin is sufficient to prevent
the device from autoconfiguring.

Marko

ok, yes, the programn/initn are bit confusing, I have some more interesting results:

IR readback 0x19 bits 1,0 are as per JEDEC 1149.1 so JTAG chain is NOT DEAD
CFG0=CFG1=PROGRAMN=0(gnd) JTAG ID readback 0x00000000
CFG0=CFG1=PROGRAMN=1(open) JTAG ID readback 0xFFFFFFFF

in both cases the ERASE seems to work as normal, eg it does poll a few times, and get erase done flag ok.

but the chip still seems to be configured from bad flash as it never tristates its IO pins :(

--

HOT, yes I had one chip that got hot, and was still possible to reflash and erase and worked well after

Antti

lattice reply, proper setting for no config:

CFG0=CFG1=INITN=0
PROGRAMN=1 (not clear if 1 or is enough to leave open?)

re JTAGID=0000000 we have some device that WORKS but has ID 0
and can not be reprogrammed. hmm and some devices that do not
work and get not be reprogrammed.

maybe some OTP bit got flashed. there is nothing in datasheet
about how JTAG ID reads if OTP is set, or if flash erase would
fail or not if OTP set.