Reading a failing PLD

[jamma-plusser]

I have an AMI 18CV8-15 on a PCB from 1993 that is failing (it only
works properly when I've given it a good blast with some freezer
spray, and it's slowly getting worse, ie needing more freezer spray to
make it work every time).

If I try and read it (my EPROM programmer, a Galep-4, supports it)
then I get a different reading every time.

Now I'm not that familiar with PLDs but as I understand it they have a
security bit - if this bit is set (not sure how I can tell!) then
would this account for the different reading every time? Or are the
variable readings caused by the PLD failing?

I've tried giving it a good blast of freezer spray before I try and
read it, but I still get a different reading every time.

Any advice please?

Thanks

 

[Franc Zabkar]

On Sun, 16 Nov 2008 11:25:31 GMT, jamma-plusser@hotmail.com
(jamma-plusser) put finger to keyboard and composed:

I have an AMI 18CV8-15 on a PCB from 1993 that is failing (it only
works properly when I've given it a good blast with some freezer
spray, and it's slowly getting worse, ie needing more freezer spray to
make it work every time).

If I try and read it (my EPROM programmer, a Galep-4, supports it)
then I get a different reading every time.

Now I'm not that familiar with PLDs but as I understand it they have a
security bit - if this bit is set (not sure how I can tell!) then
would this account for the different reading every time? Or are the
variable readings caused by the PLD failing?

I believe that your programmer should be able to determine the status
of the security bit. IIRC my Sunshine Expro-60 is able to do this.

I've tried giving it a good blast of freezer spray before I try and
read it, but I still get a different reading every time.

Any advice please?

Thanks

I'd use the technique that Steve Gibson uses in his Spinrite hard disc
data recovery software. Keep re-reading the PLD, save the data, and
then perform a statistical analysis on it. Assuming the bad bits are
good more often than not, build a binary image with this in mind. If
the failure mode is known, then this may help, too. For example, are
faulty bits usually low or high?

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[jamma-plusser]

On Mon, 17 Nov 2008 06:41:24 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> wrote:

I believe that your programmer should be able to determine the status
of the security bit. IIRC my Sunshine Expro-60 is able to do this.

I would have thought so too. Can't see any indication though. I know
if I read a GAL then all bits are set to '1' so as the 18CV8 is
varying so much I would GUESS that it's not protected. Not sure
though!

I'd use the technique that Steve Gibson uses in his Spinrite hard disc
data recovery software. Keep re-reading the PLD, save the data, and
then perform a statistical analysis on it. Assuming the bad bits are
good more often than not, build a binary image with this in mind. If
the failure mode is known, then this may help, too.

Must admit that I wouldn't know where to start - what would I use to
perform such an analysis?

For example, are
faulty bits usually low or high?

It varies.

Thanks

 

[Franc Zabkar]

On Sun, 16 Nov 2008 22:28:41 GMT, jamma-plusser@hotmail.com
(jamma-plusser) put finger to keyboard and composed:

On Mon, 17 Nov 2008 06:41:24 +1100, Franc Zabkar
fzabkar@iinternode.on.net> wrote:


I believe that your programmer should be able to determine the status
of the security bit. IIRC my Sunshine Expro-60 is able to do this.

I would have thought so too. Can't see any indication though. I know
if I read a GAL then all bits are set to '1' so as the 18CV8 is
varying so much I would GUESS that it's not protected. Not sure
though!

Sorry, I just checked my programmer. It only gives me the option of
blowing the security fuse for a PEEL18CV8. It doesn't appear to detect
its status.

I'd use the technique that Steve Gibson uses in his Spinrite hard disc
data recovery software. Keep re-reading the PLD, save the data, and
then perform a statistical analysis on it. Assuming the bad bits are
good more often than not, build a binary image with this in mind. If
the failure mode is known, then this may help, too.

Must admit that I wouldn't know where to start - what would I use to
perform such an analysis?

I'd read the device several times (while freezing and/or heating it)
and save the binary images to sequentially numbered files, eg
image01.bin, image02.bin, etc. I'd then write a simple program to
check each bit in each of the .bins and count how many times it
appears as a 1 or a 0. If a particular bit consistently reads the same
when the PLD is heated (which appears to be when it is most prone to
failure), then it could be assumed that this bit is good. If a bad bit
reads as 0 most of the time, then assume it really is a 0.

For example, are
faulty bits usually low or high?

It varies.

Thanks

Let's assume that the faults are the result of decaying data, not
faults in the actual logic gates. Over time, does a particular bit
"fade" back to its blank state? If so, then if the blank state is "1",
say, you would expect that failures would only show up in bits that
had been programmed as 0s.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[Franc Zabkar]

On Mon, 17 Nov 2008 10:05:58 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> put finger to keyboard and composed:

Let's assume that the faults are the result of decaying data, not
faults in the actual logic gates.

I'd first test the input and output pins to make sure that they swing
between the correct TTL levels. Sometimes increasing the supply
voltage will see the device come good (it may damage it as well).
Reducing the supply may also help in isolating an intermittent bit.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[jamma-plusser]

On Mon, 17 Nov 2008 10:22:21 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> wrote:

Let's assume that the faults are the result of decaying data, not
faults in the actual logic gates.

I'd first test the input and output pins to make sure that they swing
between the correct TTL levels. Sometimes increasing the supply
voltage will see the device come good (it may damage it as well).
Reducing the supply may also help in isolating an intermittent bit.

Are you referring to increasing the supply voltage when the device is
in the programmer (don't think that I can do that!) or on the board?

If the latter then surely that is going to risk damaging other ICs on
the board, particularly if increasing the voltage (which I can do
easily enough via the PSU).

 

[jamma-plusser]

On Sun, 16 Nov 2008 23:32:25 GMT, jamma-plusser@hotmail.com
(jamma-plusser) wrote:

Okay, further to that - if I lower the voltage to the board then it
runs much better. So how can I lower the voltage to the 18CV8 when
it's in the programmer socket? It seems to work best at about 4.7 VDC

 

[JW]

On Sun, 16 Nov 2008 23:39:47 GMT jamma-plusser@hotmail.com (jamma-plusser)
wrote in Message id: <4920aeef.303849093@news.zen.co.uk>:

On Sun, 16 Nov 2008 23:32:25 GMT, jamma-plusser@hotmail.com
(jamma-plusser) wrote:

Okay, further to that - if I lower the voltage to the board then it
runs much better. So how can I lower the voltage to the 18CV8 when
it's in the programmer socket? It seems to work best at about 4.7 VDC

Lift it's power pin from the programmers socket, and power it with a
external supply. Make sure the grounds are connected together between the
programmer and the external power supply.

 

[jamma-plusser]

On Mon, 17 Nov 2008 05:47:16 -0500, JW <none@dev.null> wrote:

Okay, further to that - if I lower the voltage to the board then it
runs much better. So how can I lower the voltage to the 18CV8 when
it's in the programmer socket? It seems to work best at about 4.7 VDC

Lift it's power pin from the programmers socket, and power it with a
external supply. Make sure the grounds are connected together between the
programmer and the external power supply.

Thanks, nice idea.

Another possibility - how about using a diode to drop the voltage to
the PLD itself?

 

[Franc Zabkar]

On Mon, 17 Nov 2008 15:10:36 GMT, jamma-plusser@hotmail.com
(jamma-plusser) put finger to keyboard and composed:

On Mon, 17 Nov 2008 05:47:16 -0500, JW <none@dev.null> wrote:


Okay, further to that - if I lower the voltage to the board then it
runs much better. So how can I lower the voltage to the 18CV8 when
it's in the programmer socket? It seems to work best at about 4.7 VDC

Lift it's power pin from the programmers socket, and power it with a
external supply. Make sure the grounds are connected together between the
programmer and the external power supply.

Thanks, nice idea.

Another possibility - how about using a diode to drop the voltage to
the PLD itself?

AFAICS, that could cause destructive latchup problems if the voltage
on any of the input pins is greater than Vcc. You may be able to get
away with a germanium diode, or a high current Schottky diode, or a
PNP transistor with low Vce(sat).

In fact the datasheet stipulates an absolute maximum input voltage of
Vcc + 0.6V. For guaranteed operation, the limit is Vcc + 0.3V. The
recommended supply range is 4.75 - 5.25V.

If you use an external supply, be sure to power up the supply before
powering up your programmer. When powering down, turn off your
programmer before turning off the supply.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.

 

[jamma-plusser]

On Tue, 18 Nov 2008 06:09:08 +1100, Franc Zabkar
<fzabkar@iinternode.on.net> wrote:

AFAICS, that could cause destructive latchup problems if the voltage
on any of the input pins is greater than Vcc. You may be able to get
away with a germanium diode, or a high current Schottky diode, or a
PNP transistor with low Vce(sat).

In fact the datasheet stipulates an absolute maximum input voltage of
Vcc + 0.6V. For guaranteed operation, the limit is Vcc + 0.3V. The
recommended supply range is 4.75 - 5.25V.

If you use an external supply, be sure to power up the supply before
powering up your programmer. When powering down, turn off your
programmer before turning off the supply.

Thanks. I did in fact try the diode trick before reading your reply
and it worked on the board (I used a 1N4001 diode on the +5 volt pin)
- now I can run the board at the correct voltage using the diode on
the PLD only and have about 4.7 going to the PLD. It didn't help with
reading it in the programmer though, which is a pity.

 

[Clint Sharp]

In message <4921e290.382885093@news.zen.co.uk>, jamma-plusser
<jamma-plusser@hotmail.com> writes

Thanks. I did in fact try the diode trick before reading your reply
and it worked on the board (I used a 1N4001 diode on the +5 volt pin)
- now I can run the board at the correct voltage using the diode on
the PLD only and have about 4.7 going to the PLD. It didn't help with
reading it in the programmer though, which is a pity.
Would it be difficult to reverse engineer the function or do you have no

idea as to the function?

Might be worth taking a look at a few dumps from the device to see if
you have any consistent areas and then mapping them to the used I/O pins
on the device. You may be surprised how simple it actually is if you
spend a little time drawing the relevant parts of the circuit.

I'm guessing from your nick that it's going to be on an arcade board?

Naming the board might be useful, especially if there's a schematic
kicking around, it's possible that there's enough info on the circuit to
reverse the device.

Clint Sharp

 

[jamma-plusser]

On Mon, 17 Nov 2008 23:40:27 +0000, Clint Sharp
<clint@clintsmc.demon.co.uk> wrote:

Might be worth taking a look at a few dumps from the device to see if
you have any consistent areas and then mapping them to the used I/O pins
on the device. You may be surprised how simple it actually is if you
spend a little time drawing the relevant parts of the circuit.

Must admit that's going to be a bit beyond me I'm afraid.

I could send you a few dumps if you're willing to take a look.

I'm guessing from your nick that it's going to be on an arcade board?

Yeah, sorry, meant to mention that.

Naming the board might be useful, especially if there's a schematic
kicking around, it's possible that there's enough info on the circuit to
reverse the device.

It's a Raiden 2 board. No schems around as far as I can tell I'm
afraid.

 

[Franc Zabkar]

On Tue, 18 Nov 2008 10:51:42 GMT, jamma-plusser@hotmail.com
(jamma-plusser) put finger to keyboard and composed:

On Mon, 17 Nov 2008 23:40:27 +0000, Clint Sharp
clint@clintsmc.demon.co.uk> wrote:


Might be worth taking a look at a few dumps from the device to see if
you have any consistent areas and then mapping them to the used I/O pins
on the device. You may be surprised how simple it actually is if you
spend a little time drawing the relevant parts of the circuit.

Must admit that's going to be a bit beyond me I'm afraid.

I could send you a few dumps if you're willing to take a look.

Why not take several dumps, ZIP them up, and then upload them to a
file sharing site? Alternatively, email them to me and I'll put them
on my web site for others to look at.

- Franc Zabkar
--
Please remove one 'i' from my address when replying by email.