[sdiy] [OT] puzzling EPROM problem

[Theo]

Probably a dumb remark, but that's why I am here for ;^)
Doesn't reprogramming the Eproms include lifting the ICs from the sockets
and re-inserting them?
A well known repair method for C64s...

Theo



From: Magnus Danielson <cfmd at swipnet.se>


> From: "Trevor Page" <trevor at resonance.fsnet.co.uk>
> Subject: [sdiy] [OT] puzzling EPROM problem
> Date: Thu, 20 Sep 2001 22:22:26 +0100
>
> > Hi list,
>
> Hi Trevor,
>
> > I've got a funny EPROM problem here. Sorry for the OT, but this is
probably
> > the best place to ask this sort of question.
>
> Indeed. However, as I read through it I also think it applies to ower
> older synth friends. Some of them might actually experience similar
things.
>
> > I'm repairing two Martin Imagescan projectors (dirty great big heavy
things
> > that spin strange images all over the place in nightclubs!!!). Without
going
> > too much into detail, the projectors were failing to initialise
properly.
> >
> > They use an Atmel CPU and have an EPROM (27256) containing programme
> > information. The EPROM versions in these projectors was V3.0. Having
spent
> > ages on these things and coming to a complete loss as to what the cause
of
> > the fault was, for a laugh I tried reprogramming one of the EPROMs with
the
> > latest image, V5.0.
> >
> > That caused the projector to work perfectly.
>
> Ah. Interesting.
>
> > Before reprogramming the EPROM, I verified it's contents against a V3.0
mask
> > that I downloaded also, and it verified correctly. So it's not as if the
> > EPROM contained bad data in the first place. V5 may well have bug fixes
and
> > so on over V3 - but it's strange how updating the firmware like this
would
> > make a suddenly disfunctional machine work again.
>
> Naturally, you should try to load the old firmware once again just to
> see if the errors comes back or not. I don't think they will thought.
>
> > When an EPROM is programmed, or with the passing of time, is it at all
> > possible for certain bits, or 'fuses', to be only partially 'blown' so
that
> > although the logic levels of those bits are such that they satisfy the
EPROM
> > programmer that they're correct, these particular bits read out at funny
> > voltages when the EPROM is in use, and hence the CPU reads them wrong?
But
> > then again, the outputs are surely buffered, aren't they.
>
> Let's forget about fuses. Those exist in PROMs but not EPROMs.
>
> EPROMs operate with a floating gate. This means that one has a little
> piece of deposited aluminium in the siliconoxide. When programing one
> deposit a charge onto it. The isolation is so great that it takes the
> energy of an UV lamp for the electrons to jump back. There is however
> a slow leakage mechanism, so the deposited charge will very slowly
> evaporate.
>
> > The EPROMs are being accessed pretty fast. The CPU is on a 24MHz xtal.
If
> > this means anything. They're 27256-10's.
>
> It could be, but not necessarilly have to be so, that the slow access
> of these reads correctly where as a quick access can fail.
>
> > One other possibility is that the CPU is detecting a certain fault
condition
> > from one of the sensors, and whereas V3 would just hang up in the event
of
> > this happening, V5.0 will carry on regardless. But there are really very
few
> > inputs to the CPU - DIP switches for mode settings, a microswitch and an
> > optosensor - all of which work fine.
>
> Try loading the old firmware back again.
>
> > Any thoughts? It's bad enough not being able to repair something, but
it's
> > worse having got something working and not knowing why...
>
> Indeed. I hope you got some dash of insight which can come in handy.
>
> > Trev (sitting in a dark room, with psychaedelic images floating around
the
> > walls and ceiling... :-)
>
> Trev, please come down...  ;O)
>
> Cheers,
> Magnus - about to hit the bed
>