Maker Pro
Maker Pro

chip swelling up and getting fried

D

DJ

Jan 1, 1970
0
Hi all,
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup.The chip takes in 2 power supplies.1v for core
and a 3v3 for i/o's.There are no overshoots or undershoots that i can
see in the oscilloscopes.
The chip has worked on the same board for sometime but eventually gets
burned out or swelling in the package is seen.I have done the power
sequenceing as per the manufactures requirement but still having major
problems.
I have exhausted all the options i can look into......please help me
start looking for some thing that can lead me to the problem.
Can someone tell me where the likly problem can be?.
The CMOS chip works for a few seconds but goes on getting hot till
the swelling appears and then the chip is dead.It has a plastic
package.The chip has a PCI interface.will the overshoot on the signals
damage the chip so badly?


Regards
DJ
 
B

Boris Mohar

Jan 1, 1970
0
Hi all,
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup.The chip takes in 2 power supplies.1v for core
and a 3v3 for i/o's.There are no overshoots or undershoots that i can
see in the oscilloscopes.
The chip has worked on the same board for sometime but eventually gets
burned out or swelling in the package is seen.I have done the power
sequenceing as per the manufactures requirement but still having major
problems.
I have exhausted all the options i can look into......please help me
start looking for some thing that can lead me to the problem.
Can someone tell me where the likly problem can be?.
The CMOS chip works for a few seconds but goes on getting hot till
the swelling appears and then the chip is dead.It has a plastic
package.The chip has a PCI interface.will the overshoot on the signals
damage the chip so badly?


Regards
DJ

Don't use no name chips ;)
 
W

Winfield Hill

Jan 1, 1970
0
DJ wrote...
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup. ... The CMOS chip works for a few seconds
but goes on getting hot till the swelling appears ...

Sounds like SCR latchup, wihch once triggered causes a high-current
capable turned-on SCR to appear across the supply rails. If you are
sequencing the power supplies correctly, then you may have an input
that exceeds one of the supplies and is injecting enough current
through the chip's static-protection diodes to initiate SCR latchup.

Thanks,
- Win

(email: use hill_at_rowland-dot-org for now)
 
B

Bob F.

Jan 1, 1970
0
DJ said:
Hi all,
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup.The chip takes in 2 power supplies.1v for core
and a 3v3 for i/o's.There are no overshoots or undershoots that i can
see in the oscilloscopes.

Have you bothered to measure the current being drawn by this device? Take a
look at the data sheet and see what the expected power consumed by the
device should be then check to see how much power it is consuming in your
design. Remember, current measurements are made by connecting the DVM in a
serial connection.

What is the device? How many bumps does it have? Double check your
design/layout to ensure that all of the inputs/outputs are correctly pulled
up or pulled down according to the MFG's guidelines.
 
C

clive

Jan 1, 1970
0
Is the chip 5 volt tolerant on PCI bus or are you using a 3.3V PCI
(relatively rare). Was chip definitely working?

Clive
 
J

John Larkin

Jan 1, 1970
0
Hi all,
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup.The chip takes in 2 power supplies.1v for core
and a 3v3 for i/o's.There are no overshoots or undershoots that i can
see in the oscilloscopes.
The chip has worked on the same board for sometime but eventually gets
burned out or swelling in the package is seen.I have done the power
sequenceing as per the manufactures requirement but still having major
problems.
I have exhausted all the options i can look into......please help me
start looking for some thing that can lead me to the problem.
Can someone tell me where the likly problem can be?.
The CMOS chip works for a few seconds but goes on getting hot till
the swelling appears and then the chip is dead.It has a plastic
package.The chip has a PCI interface.will the overshoot on the signals
damage the chip so badly?


Regards
DJ

If it's a ram-based FPGA, it could be a weird configuration file. It's
possible to program some of these parts to self-destruct.

Could the PCI bus be pulling the i/o's above 3.3?

John
 
C

CWatters

Jan 1, 1970
0
DJ said:
Hi all,
I am stuck with this problem of a BGA chip getting fried within a
few seconds of powerup.The chip takes in 2 power supplies.1v for core
and a 3v3 for i/o's.There are no overshoots or undershoots that i can
see in the oscilloscopes.

Check the power sequencing. Does the chip require 3v3 to be up before the
1v?

What about inputs to the chip? Do they appear before the rails are up?
Perhaps you are "latching up" an unprotected input pin (perhaps an analog
I/O pin- they don't always have protection).

Are the clocks running? Some dynamic devices get a bit hot and bothered if
they aren't clocked.

Heatsinks not big enough? With some BGA you need to extract heat through the
PCB as well as from the top of. They need the correct PCB footprint and
weight of copper.

Reset not long enough to allow correct operation? Bit unlikely though.
 
D

DaveC

Jan 1, 1970
0
If it's a ram-based FPGA, it could be a weird configuration file. It's
possible to program some of these parts to self-destruct.

Recollection of Motorola's "CFBU" (catch fire and burn up :) opcode. That
was that in the first 6502's, wasn't it?
 
C

Clifford Heath

Jan 1, 1970
0
S/360 had a bunch of reserved opcodes...

I haven't hunted up details, but two favourites of mine (that were
real instructions) were named:

EBRS: Emit Burnt Resister Smell (on an early computer). Caused a
particular resister to overheat.

HCF: Halt and Catch Fire (caused such a tight loop in microcode that
part of the ucode ROM would melt, think this one was at Intel).

Clifford.
 
K

Ken Smith

Jan 1, 1970
0
I haven't hunted up details, but two favourites of mine (that were
real instructions) were named:

EBRS: Emit Burnt Resister Smell (on an early computer). Caused a
particular resister to overheat.

HCF: Halt and Catch Fire (caused such a tight loop in microcode that
part of the ucode ROM would melt, think this one was at Intel).

The MOT 6800 had a HCF. It didn't litterally catch fire. All of the
busses had squarewaves on them etc so a scope could be used to check the
signals.

The RCA 1802 had a SEX instruction. It stood for "set index".

The Z80 had / has several that are sort of "load and ignore value". They
cause a ram read but nothing happens to the value.
 
B

Bill Bertram

Jan 1, 1970
0
DaveC said:
Recollection of Motorola's "CFBU" (catch fire and burn up :) opcode. That
was that in the first 6502's, wasn't it?

Motorola didn't make the 6502, I think you mean the 6800.

-Bill
 
K

Keith Williams

Jan 1, 1970
0
The MOT 6800 had a HCF. It didn't litterally catch fire. All of the
busses had squarewaves on them etc so a scope could be used to check the
signals.

The RCA 1802 had a SEX instruction. It stood for "set index".

One of the microprocessors I worked with (6800? NatSemi
PACE? - too many to remember;) had an LSEX instruction
(Load with Sign EXtended).
The Z80 had / has several that are sort of "load and ignore value". They
cause a ram read but nothing happens to the value.

Some current processors have such instructions. For
example, the PowerPC's DCBT (Data Cache Block Touch) is
used for data cache prefetching (and streaming) and to
load the TLB.

Not an instruction, but one could get the monochrome
monitor on the original IBM PC to release its magic
smoke by writing an I/O register.
 
S

Sir Charles W. Shults III

Jan 1, 1970
0
Gee, this might be as simple as an unrecognized floating input. Or, it
might also be due to needing more capacitance on the power supply terminals.
Simple, simple. Try the most obvious options first.

Cheers!

Sir Charles W. Shults III, K. B. B.
Xenotech Research
321-206-1840
 
R

Rich Grise

Jan 1, 1970
0
[email protected] says...

Some current processors have such instructions. For
example, the PowerPC's DCBT (Data Cache Block Touch) is
used for data cache prefetching (and streaming) and to
load the TLB.

I believe the 8008 (I know it was one of them where the
instructions are almost microcode themselves) had a "store
immediate", kinda the converse of load immediate, i.e., it
would write the contents of A to [PC+1].
 
D

Daniel Rudy

Jan 1, 1970
0
And somewhere around the time of 07/14/2004 13:12, the world stopped and
listened as John Larkin contributed the following to humanity:
S/360 had a bunch of reserved opcodes...

http://listserv.uark.edu/scripts/wa.exe?A2=ind0406&L=vmesa-l&F=&S=&P=62319

My favorite is BKO Branch and kill operator


The PDP-11 had the (real) LandMine instruction,

MOV -(PC), -(PC)

which copied itself into all of memory.

John


Let's not forget the infamous Pentium F00F bug that would lock up the
CPU so hard that a reset was need to recover.
 
D

Daniel Rudy

Jan 1, 1970
0
And somewhere around the time of 07/14/2004 08:43, the world stopped and
listened as John Larkin contributed the following to humanity:
If it's a ram-based FPGA, it could be a weird configuration file. It's
possible to program some of these parts to self-destruct.

That can happen!?

*goes and triple checks RAM-FPGA config files*
 
J

John Larkin

Jan 1, 1970
0
And somewhere around the time of 07/14/2004 13:12, the world stopped and
listened as John Larkin contributed the following to humanity:



Let's not forget the infamous Pentium F00F bug that would lock up the
CPU so hard that a reset was need to recover.


I loved the 286 ("brain damaged CPU" to quote Bill Gates) trick to get
out of protected mode back into real mode. The CPU designers forgot to
allow an instruction to do this, so somebody patented the idea of
sending a command to the keyboard controller to reset the CPU. I think
early versions of Windoze actually used this technique.

John
 
N

Nico Coesel

Jan 1, 1970
0
Daniel Rudy
And somewhere around the time of 07/14/2004 08:43, the world stopped and
listened as John Larkin contributed the following to humanity:


That can happen!?

With Xilinx Spartan devices: Definitely YES.
*goes and triple checks RAM-FPGA config files*

Hmm, a 0.5 amp fuse will do fine to protect your FPGA, just don't (be
stupid like me and...) shunt it with a wire when it blows, but replace
it. Or get a polyswitch / polyfuse.
 
D

Daniel Rudy

Jan 1, 1970
0
And somewhere around the time of 07/17/2004 13:42, the world stopped and
listened as Nico Coesel contributed the following to humanity:
Daniel Rudy
<i0n1v2a3l4i5d6d7c8r9u0d1y2e3m4a5i6l7@n0o1p2a3c4b5e6l7l8s9p0a1m2.3n4e5t6>
wrote:




With Xilinx Spartan devices: Definitely YES.

Ok, I'm using the parts from Lattice Semiconductor.
Hmm, a 0.5 amp fuse will do fine to protect your FPGA, just don't (be
stupid like me and...) shunt it with a wire when it blows, but replace
it. Or get a polyswitch / polyfuse.

That's a good idea. My question now is how an errant config can kill
the device? Loop something around from output to input? Or is there
some way that it can short VCC to GND? I'm thinking the latter since
you mentioned the fuse...
 
Top