SHARC 21065L hardware problem

Hi Jon,

Given the information you provided, it seems to me that either the DSP chip
itself or the PCB board are the cause of the problem, since many boards work
as expected. Can you test your PCB?

When you say that you "lifted the pin", did you mean that you separated the
specific pin on the DSP from the PCB, and measuring the level at the pin it
is still driven low? What if you check at the point on the PCB where the DSP
pin was originally connected?

Is the DSP running the same program as the other working DSPs?

I've not done multiprocessing with this chip, but one question that comes to
my mind is about what conditions make this pin being driven low, and which
ones driven high, and try to experiment with it. Maybe you can make the pin
go high, at least under some conditions. Has the DSP worked fine, as
expected, at least a few times?

For one ADDS-21065L-EZLITE I got that flags 4, 5 and 6 don't work anymore...
can't get the led's to glow. They used to work, the leds still are OK (I can
get them on, getting the voltage from somewhere else). I suppose those pins
on the DSP got damaged, for some strange reason (unproper handling, maybe?)

Just my 2 cents.

--
Jaime Andr�s Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)

"Jaime Andres Aranguren Cardona" <jaime.aranguren@ieee.org> wrote in message 
news:14a86f87.0412290509.2f30912a@posting.google.com...
> Hi Jon,
>
> Given the information you provided, it seems to me that either the DSP chip
> itself or the PCB board are the cause of the problem, since many boards work
> as expected. Can you test your PCB?

Not easily.  I suppose I could use an ohm meter to check out the hundreds (or 
thousands) of nets, but that would take way too long.

> When you say that you "lifted the pin", did you mean that you separated the
> specific pin on the DSP from the PCB, and measuring the level at the pin it
> is still driven low? What if you check at the point on the PCB where the DSP
> pin was originally connected?

Yes, that is what I meant by lifting the pin.  The idea there is to separate 
chip problems from PCB problems.  When I did this, the pin was still driven low 
by the DSP, and the PCB net is floating in an indeterminate state (which is to 
be expected since now there is no pin driving it).

> Is the DSP running the same program as the other working DSPs?

Yes.  This is a production situation where one board out of many fail.

> I've not done multiprocessing with this chip, but one question that comes to
> my mind is about what conditions make this pin being driven low, and which
> ones driven high, and try to experiment with it. Maybe you can make the pin
> go high, at least under some conditions. Has the DSP worked fine, as
> expected, at least a few times?

It has never worked correctly.  My understanding is that the pin should be 
tri-stated during reset, so the fact that it is low during reset seems to 
indicate the chip should be replaced.  That is the path I will take.

> For one ADDS-21065L-EZLITE I got that flags 4, 5 and 6 don't work anymore...
> can't get the led's to glow. They used to work, the leds still are OK (I can
> get them on, getting the voltage from somewhere else). I suppose those pins
> on the DSP got damaged, for some strange reason (unproper handling, maybe?)

ESD would be a likely cause of blowing up pins.  That may be what I have as 
well. 

Thanks to all who contributed to this thread.  It turned out to be a bad DSP
chip.  Replacing it solved the problem.

All the evidence pointed to the DSP itself, but I am usually hesitant to pin the
blame on an IC.  In my experience, by far the most frequent cause of non-working
boards are solder problems (shorts or cold joints).  Second comes problems with
the PCB itself, with ICs coming in third.  But in this case, it was the IC.

"Jon Harris" <goldentully@hotmail.com> wrote in message news:...
> I have one board that has a problem with a 21065L SHARC (many other
"identical"
> boards work properly). The main symptom I have noticed is that the bus request
> line (\BR1) line is always low, even during reset. The board has 2 21065L
chips
> connected in a standard multi-processor set-up (i.e. shared busses and control
> signals). But it appears that DSP ID #1 is driving bus request 1 line low even
> during reset. This signal is of course connected to both DSPs, so to isolate
> the problem, I lifted the pin from DSP ID #1. The pin still is driven low, so
> it seems that the DSP is driving it rather than a short on the board or
problem
> with the other DSP.
>
> My first assumption is that I have a bad DSP chip. But since it is fairly
> difficult and costly to replace the chip, I wanted to see if there was
anything
> else obvious that might cause this behavior. I checked clock, reset, and chip
> ID and they all looked OK. \HBR and \HBG were both high as expected. The boot
> mode is set to host boot (\BMS high, BSEL low). Can you think of anything that
> would cause the bus request line to be driven low?
>
> Thanks in advance,
> Jon

"Jon Harris" <goldentully@hotmail.com> escribi&#4294967295; en el mensaje
news:34lmdnF4dnr4pU1@individual.net...
> Thanks to all who contributed to this thread.  It turned out to be a bad
DSP
> chip.  Replacing it solved the problem.
>
> All the evidence pointed to the DSP itself, but I am usually hesitant to
pin the
> blame on an IC.  In my experience, by far the most frequent cause of
non-working
> boards are solder problems (shorts or cold joints).  Second comes problems
with
> the PCB itself, with ICs coming in third.  But in this case, it was the
IC.

Hi Jon,

I'm glad you got the problem solved. As you point out, most of the times the
problems come from other points in the hardware design and assembly chain.
And most of the times they are small problems, hard to track. And we trust
the IC manufacturers. Could you imagine how of a hell would it be if the IC
manufacturer was highly unreliable?

Regards,

--
Jaime Andr&#4294967295;s Aranguren Cardona
jaac@nospam.sanjaac.com
SanJaaC Electronics
Soluciones en DSP
www.sanjaac.com

(Remove "nospam" from e-mail address)