Discussion:
OTP-EPROM nachprogrammieren?
(zu alt für eine Antwort)
Gerrit Heitsch
2011-04-19 17:19:32 UTC
Permalink
Hallo,

hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?

Die korrekten Daten habe ich (mit 4,3v statt 5V ausgelesen stimmen sie
noch und im Netz sind sie auch zu bekommen).

Gerrit
Henning Paul
2011-04-19 17:33:42 UTC
Permalink
Post by Gerrit Heitsch
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
Warum nimmst Du nicht ein leeres EPROM dafür?

Gruß
Henning
--
henning paul home: http://home.arcor.de/henning.paul
PM: ***@gmx.de , ICQ: 111044613
Gerrit Heitsch
2011-04-19 17:43:39 UTC
Permalink
Post by Henning Paul
Post by Gerrit Heitsch
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
Warum nimmst Du nicht ein leeres EPROM dafür?
Hab ich im Moment drin. Nur sind 27(C)128 nicht mehr ganz so einfach zu
bekommen und warum ein gutes EPROM 'verschwenden' wenn man das OTP
wieder raktivieren kann?

Gerrit
Joerg
2011-04-19 18:16:47 UTC
Permalink
Post by Gerrit Heitsch
Post by Henning Paul
Post by Gerrit Heitsch
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
Warum nimmst Du nicht ein leeres EPROM dafür?
Hab ich im Moment drin. Nur sind 27(C)128 nicht mehr ganz so einfach zu
bekommen und warum ein gutes EPROM 'verschwenden' wenn man das OTP
wieder raktivieren kann?
Zumindest mit den Holtek SPI-EPROMs (auch OTP) kann man wohl byte-weise
programmieren:

http://www.holtek.com/english/docum/memory/25lc512.htm

Frage: Wenn das Dingen ohnehin am Abtrieseln ist, warum nicht einfach
ausprobieren?
--
Gruesse, Joerg

http://www.analogconsultants.com/

"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Gerrit Heitsch
2011-04-19 18:34:22 UTC
Permalink
Post by Joerg
Post by Gerrit Heitsch
Hab ich im Moment drin. Nur sind 27(C)128 nicht mehr ganz so einfach zu
bekommen und warum ein gutes EPROM 'verschwenden' wenn man das OTP
wieder raktivieren kann?
Zumindest mit den Holtek SPI-EPROMs (auch OTP) kann man wohl byte-weise
http://www.holtek.com/english/docum/memory/25lc512.htm
Frage: Wenn das Dingen ohnehin am Abtrieseln ist, warum nicht einfach
ausprobieren?
Ich wollte lieber erstmal fragen, nachher gibts da noch einen Trick den
man beachten sollte.

Bisher kam nichts, also werde ich es probieren. Dummerweise steht nicht
drauf ob es ein 12,5V oder 21V-Typ ist, der Originalaufdruck ist
natürlich abgeschliffen. Mal sehen was mein alter EPROG 27011 dazu
meint. Dank Holgers Software jetzt auch unter Linux brauchbar.

Gerrit
Guido Grohmann
2011-04-19 19:13:14 UTC
Permalink
Post by Gerrit Heitsch
Hab ich im Moment drin. Nur sind 27(C)128 nicht mehr ganz so einfach zu
bekommen und warum ein gutes EPROM 'verschwenden' wenn man das OTP
wieder raktivieren kann?
Ich havon 'ne Handvoll aus alter Computerhardware hier zu liegen. wenn
du Bedarf hast, laß es mich wissen. Auch 64er ,256er und 512er sind noch
da.

Guido
Gerrit Heitsch
2011-04-19 19:27:50 UTC
Permalink
Post by Guido Grohmann
Post by Gerrit Heitsch
Hab ich im Moment drin. Nur sind 27(C)128 nicht mehr ganz so einfach zu
bekommen und warum ein gutes EPROM 'verschwenden' wenn man das OTP
wieder raktivieren kann?
Ich havon 'ne Handvoll aus alter Computerhardware hier zu liegen. wenn
du Bedarf hast, laß es mich wissen. Auch 64er ,256er und 512er sind noch
da.
Im Moment hab ich genug (alte VGA-Karten sind dankbare Spender von RAM
und EPROMs), aber bevor du sie wegwirfst nehm ich sie natürlich, vor
allem die 27C64 und 27C128. Das sind die Grössen die man für
Retro-Computer am häufigsten braucht und im Gegensatz zu NMOS-Typen
brauchen sie deutlich weniger Strom. In Rechnern mit heizendem 7805 ist
das durchaus gewünscht :)

Gerrit
Hanno Foest
2011-04-19 21:58:06 UTC
Permalink
Post by Gerrit Heitsch
In Rechnern mit heizendem 7805 ist
das durchaus gewünscht :)
Schau dir mal
http://www.conrad.de/ce/de/product/154496 (Recom R-785.0-1.0)
an. Pinkompatibler Ersatz für 7805 mit vernachlässigbaren Verlusten.
Teuer, ja, aber wo das Kühlblech eines ZX81 vorher knallheiß wurde,
braucht er hinterher keines mehr - und das ist sehr gut für die
Lebensdauer mancher Chips. Die Verluste des EPROMs sind da eher egal...

Hanno
Gerrit Heitsch
2011-04-20 16:03:53 UTC
Permalink
Post by Hanno Foest
Post by Gerrit Heitsch
In Rechnern mit heizendem 7805 ist
das durchaus gewünscht :)
Schau dir mal
http://www.conrad.de/ce/de/product/154496 (Recom R-785.0-1.0)
an. Pinkompatibler Ersatz für 7805 mit vernachlässigbaren Verlusten.
Teuer, ja, aber wo das Kühlblech eines ZX81 vorher knallheiß wurde,
braucht er hinterher keines mehr - und das ist sehr gut für die
Lebensdauer mancher Chips. Die Verluste des EPROMs sind da eher egal...
Dafuer ist die Frage wie sauber der Strom ist, soll heissen wieviel
Reste der Schaltfrequenz darauf zu finden sind. Ausserdem ist das dann
nicht mehr Retro... Die von mir verbauten 27C128 hingegen passen im
Alter zur Hardware, nur die Programmierung ist neu. ;)

Zum Verlust: 2 Masken-ROMs durch 2 27C128 ersetzen spart 100mA, also 500mW.

Die anderen Chips bekommen Kühlkörper.

Gerrit
Guido Grohmann
2011-04-20 16:38:26 UTC
Permalink
Post by Gerrit Heitsch
Im Moment hab ich genug (alte VGA-Karten sind dankbare Spender von RAM
und EPROMs), aber bevor du sie wegwirfst nehm ich sie natürlich, vor
allem die 27C64 und 27C128. Das sind die Grössen die man für
Retro-Computer am häufigsten braucht und im Gegensatz zu NMOS-Typen
brauchen sie deutlich weniger Strom. In Rechnern mit heizendem 7805 ist
das durchaus gewünscht :)
HMm ich habe 10 Stück 27C128 und 2 stück 27C64 gefunden, ein paar wenige
27128 und einen 2764 (glaub ich) und der überwiegende Teil (um die 20
weitere) sind 512er und 256er. Du kannst ja statt einem 128 einen 256
einsetzen, und den Inhalt zweimal hintereinander draufbrutzeln. Wenn du
jetzt noch Interesse an dem Zeuch hast -> Mail an mich.

Guido
Bjoern Wieck
2011-04-20 16:46:59 UTC
Permalink
Post by Gerrit Heitsch
Im Moment hab ich genug (alte VGA-Karten sind dankbare Spender von RAM
und EPROMs), aber bevor du sie wegwirfst nehm ich sie natürlich, vor
allem die 27C64 und 27C128. Das sind die Grössen die man für
Retro-Computer am häufigsten braucht
27C64 (21V-Typen) von TI hätte ich noch welche abzugeben.
Mail an mich bei Interesse.

Grüße
Björn
Gernot Fink
2011-04-19 18:00:01 UTC
Permalink
Post by Gerrit Heitsch
Hallo,
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
Die korrekten Daten habe ich (mit 4,3v statt 5V ausgelesen stimmen sie
noch und im Netz sind sie auch zu bekommen).
Kommt auf den Prommer an.
Um welchen Epromtyp handelt es sich. Man könnte ja ein löschbares einbauen.
--
MFG Gernot
Axel Schwenke
2011-04-19 18:37:36 UTC
Permalink
Post by Gerrit Heitsch
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
AFAIK sind in OTP-EPROMs die gleichen Chips drin wie in den UV-
löschbaren. Nur eben ein billiges Plaste-Gehäuse drum herum.

Wenn du deinem Eprommer beibiegen kannst, daß er keinen Leertest
machen soll, dürfte das Programmieren kein Problem darstellen.

Interessanter ist die Sache mit dem Programmieralgorithmus. So
ca. ab 27(C)64 wurde angefangen mit 0.1ms Impulsen zu programmieren,
bis die Daten erstmals korrekt lesbar waren. Und dann nochmal das
doppelte der bisherigen Zeit drauf. Wenn die Daten schon drin stehen,
klappt das natürlich nicht mehr so ganz.

Besser wäre wohl, sich an den schlechtesten Bits zu orientieren.
Also so lange mit 0.1ms über alle Zellen, bis alles korrekt ist.
Und dann nochmal das doppelte drauf.

Wenn du einen (Zahn-)Arzt kennst, gib ihm den Chip, daß er ihn
mal röntgt. Danach ist er dann leer :)


XL
Gerrit Heitsch
2011-04-19 18:51:22 UTC
Permalink
Post by Axel Schwenke
Post by Gerrit Heitsch
hat hier schonmal jemand ein OTP-EPROM (also EPROM-Chip in Plastik-DIP)
welches nach deutlich mehr als 10 Jahren so langsam seine Daten verliert
mit genau denselben Daten nachprogrammiert? Oder stellt sich der
typische EPROMer quer?
AFAIK sind in OTP-EPROMs die gleichen Chips drin wie in den UV-
löschbaren. Nur eben ein billiges Plaste-Gehäuse drum herum.
Wenn du deinem Eprommer beibiegen kannst, daß er keinen Leertest
machen soll, dürfte das Programmieren kein Problem darstellen.
Macht meiner hier anscheinend nur auf Anfrage und legt wohl gleich
los... Es sei denn er testet jede einzelne Zelle auf leer bevor er sie
programmiert.
Post by Axel Schwenke
Interessanter ist die Sache mit dem Programmieralgorithmus. So
ca. ab 27(C)64 wurde angefangen mit 0.1ms Impulsen zu programmieren,
bis die Daten erstmals korrekt lesbar waren. Und dann nochmal das
doppelte der bisherigen Zeit drauf. Wenn die Daten schon drin stehen,
klappt das natürlich nicht mehr so ganz.
Es gab verschiedene Algos... Manche mit 1ms-Pulsen (Intel), andere mit
0,1ms (AMD) und noch was von Fujitsu, mein Standard ist der von Intel,
es sei denn, ich hab ein EPROM von AMD.
Post by Axel Schwenke
Besser wäre wohl, sich an den schlechtesten Bits zu orientieren.
Also so lange mit 0.1ms über alle Zellen, bis alles korrekt ist.
Und dann nochmal das doppelte drauf.
Mal sehen. ich melde mich wenn der Versuch geklappt hat oder ich den
Chip zerlegt habe. :)
Post by Axel Schwenke
Wenn du einen (Zahn-)Arzt kennst, gib ihm den Chip, daß er ihn
mal röntgt. Danach ist er dann leer :)
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle Röntgengeräte 'belichten' einfach zu kurz.

Gerrit
Kurt Harders
2011-04-20 03:25:12 UTC
Permalink
Hallo Gerrit,
Post by Gerrit Heitsch
Post by Axel Schwenke
Wenn du einen (Zahn-)Arzt kennst, gib ihm den Chip, daß er ihn
mal röntgt. Danach ist er dann leer :)
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle Röntgengeräte 'belichten' einfach zu kurz.
Dann zum Orthopäden, der belichtet länger :-).

Grüße, Kurt
--
KHTronik - Kurt Harders
Elektronik, Softwareentwicklung, Opensource-Beratung
Leimbacher Str. 36
42281 Wuppertal

T +49 202 2 50 11 64
F +49 202 2 50 11 65
M +49 171 8 36 82 33
Harald Wilhelms
2011-04-20 09:44:40 UTC
Permalink
Post by Gerrit Heitsch
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle R ntgenger te 'belichten' einfach zu kurz.
Dann zum Orthop den, der belichtet l nger :-).
Früher (tm) gabs da ja auch mal so schöne Geräte in den
Schuhgeschäften, um nachzusehen, ob die Kinderfüsse
in die Schuhe passten. Da könnte man die Belichtungs-
zeit selber wählen.
Gruss
Harald
Ralph A. Schmid, dk5ras
2011-04-20 10:36:42 UTC
Permalink
Post by Gerrit Heitsch
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle Röntgengeräte 'belichten' einfach zu kurz.
Ja, da brauchts mehr Bums. An diversen Unis wurde das mit radioaktiven
Präparaten gemacht, auf das im EPROMer steckende PROM draufgelegt und
immer wieder ausgelesen, bis es leer war, dann die Zeit
sicherheitshalber verdoppelt, aufgeschrieben und nach und nach dann
alle ICs so glöscht.


-ras
--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Rolf Bombach
2011-04-22 19:26:15 UTC
Permalink
Post by Gerrit Heitsch
Post by Axel Schwenke
Wenn du einen (Zahn-)Arzt kennst, gib ihm den Chip, daß er ihn
mal röntgt. Danach ist er dann leer :)
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle Röntgengeräte 'belichten' einfach zu kurz.
Hmf, ich könnte den Chip kurz in die Gammacell fahren, zu den einigen
kCi Kobalt. Ob der dann noch geht, halte ich für zumindest fraglich.
Colaflaschen mutieren bei der Dosisleistung da recht schnell zu Braunglas,
wobei ich jetzt nicht kundtun will, woher ich das wissen könnte.
--
mfg Rolf Bombach
Ralph A. Schmid, dk5ras
2011-04-23 07:32:35 UTC
Permalink
Post by Rolf Bombach
Hmf, ich könnte den Chip kurz in die Gammacell fahren, zu den einigen
kCi Kobalt. Ob der dann noch geht, halte ich für zumindest fraglich.
Einfach mal ausprobieren.
Post by Rolf Bombach
Colaflaschen mutieren bei der Dosisleistung da recht schnell zu Braunglas,
wobei ich jetzt nicht kundtun will, woher ich das wissen könnte.
Ooch :) Der Inschinör ist halt neugierig...


-ras
--
Ralph A. Schmid

http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/
Horst-D.Winzler
2011-04-23 11:08:57 UTC
Permalink
Post by Ralph A. Schmid, dk5ras
Post by Rolf Bombach
Hmf, ich könnte den Chip kurz in die Gammacell fahren, zu den einigen
kCi Kobalt. Ob der dann noch geht, halte ich für zumindest fraglich.
Einfach mal ausprobieren.
Post by Rolf Bombach
Colaflaschen mutieren bei der Dosisleistung da recht schnell zu Braunglas,
wobei ich jetzt nicht kundtun will, woher ich das wissen könnte.
Ooch :) Der Inschinör ist halt neugierig...
-ras
Reine Beobachtung. Rolf war im Getränkeshop Einkaufen. Da stehen viel
braune Flaschen herum, sog. Braunsche Röhren. Sehr schmackhaft der
braune Inhalt.
--
mfg hdw
Gerhard Hoffmann
2011-04-23 09:40:36 UTC
Permalink
Post by Rolf Bombach
Post by Gerrit Heitsch
Sollte man meinen. Hab ich schonmal probiert (mit einem 55ns-OTP), ist
mitnichten so. Aktulle Röntgengeräte 'belichten' einfach zu kurz.
Bei dem was meine Eproms damals an UV-Dosisleistung vor
Dr. Müllers Solettina ohne Kosmetikfilter eingesammelt haben, da waere
von 1* löschen die Haut in Fetzen abgegangen, und das Gewebe darunter
vermutlich aus.
Post by Rolf Bombach
Hmf, ich könnte den Chip kurz in die Gammacell fahren, zu den einigen
kCi Kobalt. Ob der dann noch geht, halte ich für zumindest fraglich.
Colaflaschen mutieren bei der Dosisleistung da recht schnell zu Braunglas,
wobei ich jetzt nicht kundtun will, woher ich das wissen könnte.
Wenn Du noch einen 160 dB-Abschwächer hättest oder so, dann könntest Du
mal eben ausprobieren, ob bei meinem aktuellen FPGA das Scrubbing des
Konfigurationsspeichers und die 3-fach Redundanz tatsächlich
funktionieren. Fette schnelle Ionen wären aber noch besser.

;-) Gerhard
Rolf Bombach
2011-04-25 17:39:01 UTC
Permalink
Post by Gerhard Hoffmann
Post by Rolf Bombach
Hmf, ich könnte den Chip kurz in die Gammacell fahren, zu den einigen
kCi Kobalt. Ob der dann noch geht, halte ich für zumindest fraglich.
Colaflaschen mutieren bei der Dosisleistung da recht schnell zu Braunglas,
wobei ich jetzt nicht kundtun will, woher ich das wissen könnte.
Wenn Du noch einen 160 dB-Abschwächer hättest oder so, dann könntest Du
mal eben ausprobieren, ob bei meinem aktuellen FPGA das Scrubbing des
Konfigurationsspeichers und die 3-fach Redundanz tatsächlich
funktionieren. Fette schnelle Ionen wären aber noch besser.
Kaa Problem, wir hätten da noch einen Protonenbeschleuniger, 2 mA
bei 590 MeV. Man bräuchte nur noch ein genügend schnelles DSO
um festzustellen, ob Löschen schneller war als Verdampfen.
--
mfg Rolf Bombach
Martin Laabs
2011-04-25 18:43:55 UTC
Permalink
Hallo,
Post by Rolf Bombach
Kaa Problem, wir hätten da noch einen Protonenbeschleuniger, 2 mA
bei 590 MeV. Man bräuchte nur noch ein genügend schnelles DSO
um festzustellen, ob Löschen schneller war als Verdampfen.
Das sind ca. 1.2MW. Ist das die Eingangsleistung oder tatsächlich die
Leistung des Strahls?
Was passiert, wenn der auf Luft trifft?

Viele Grüße,
Martin
Rolf Bombach
2011-04-26 20:45:45 UTC
Permalink
Post by Gerrit Heitsch
Hallo,
Post by Rolf Bombach
Kaa Problem, wir hätten da noch einen Protonenbeschleuniger, 2 mA
bei 590 MeV. Man bräuchte nur noch ein genügend schnelles DSO
um festzustellen, ob Löschen schneller war als Verdampfen.
Hmf, war eigentlich als Witz gedacht, ich sehe aber gerade:
http://pif.web.psi.ch/

Irgendwie dumpf in Erinnerung ist mir auch was mit Latch-Up bei
grossen IGBT in Lokomotiven aufgrund kosmischer Strahlung. War
vor einigen Jahren mal top-Thema.
Post by Gerrit Heitsch
Das sind ca. 1.2MW. Ist das die Eingangsleistung oder tatsächlich die
Leistung des Strahls?
Dauerleistung des Strahls, wenn alles funzt, 24/7. Input für die
Anlage dürfte in der Gegend von 18 MW liegen. Im Moment krieg ich
das Java Applet hier nicht zum Laufen, nur Daten vom August letzten
Jahres...
http://aea.web.psi.ch/Urs_Rohrer/MyWeb/accstapp.htm
Vielleicht geht
http://gfa-status.web.psi.ch/ACSstatus-g-r.html
Im Moment wird allerdings eh grad was ausgetauscht und alles
läuft nur so im Leerlauf ;-)
Post by Gerrit Heitsch
Was passiert, wenn der auf Luft trifft?
Keine Ahnung. Gibt wohl eh kein Fenster dafür, die müssten doppel-
wandig gekühlt sein. Bei der Neutronenquelle muss der Strahl ja
auch irgendwie durch ein Fenster.
Mit geringeren Leistungen geht das schon, wird in der Protonentherapie
genutzt. Die Reichweite dürfte im Meterbereich liegen, kenn mich da aber
nicht so aus. Die grösste Leistung wird dann kurz vor dem Stopp
deponiert, so dass "Zielen" auch in der dritten Dimension möglich ist.
http://de.wikipedia.org/wiki/Bragg-Kurve
--
mfg Rolf Bombach
Rafael Deliano
2011-04-20 03:54:10 UTC
Permalink
Post by Axel Schwenke
Wenn du einen (Zahn-)Arzt kennst, gib ihm den Chip, daß er ihn
mal röntgt. Danach ist er dann leer :)
Jed Margolin ( http://www.jmargolin.com/patents/eprom.htm )
hat mal Dov Frohman gefragt:

---------

The 1702 was introduced to the world in the May 10, 1971 issue
of Electronics Magazine in an article written by Dov Frohman,
the inventor of the EPROM. It contains a very curious paragraph:
" Erasure, however, has to be accomplished by non-electrical
methods, since the gate electrode is not accessible electrically.
Shining ultraviolet light on any part of an unpackaged device
causes a photocurrent to flow from the floating gate back to
the silicon substrate, thereby discharging the gate to its initial,
uncharged condition. This method of erasure allows complete
testing and correction of a complex memory array before the
package is finally sealed. Once the package is sealed, information
can still be erased by exposing it to X radiation in excess of
5 X 10**4 rads, a dose which is easily attained with commercial
X-ray generators."

X-rays? X-RAYS??
According to Dr. Frohman who was still working for Intel when I
spoke to him in 1993, they ended up deciding to ship the part
with a window because erasing the EPROM with X-rays created
surface states in the silicon that required annealing. What
this means is that the X-rays disrupted the crystal structure
at the surface of the silicon which could be fixed by annealing
in which sufficient thermal energy is supplied to the damaged
layer of atoms so they can rearrange themselves. Since the
underlying wafer is single-crystal, it serves as a seed for
the epitaxial regrowth of the layer being treated. Generally,
the required temperature is between 450 degrees Celsius and
something less than the melting point of silicon which is
1410 degrees Celsius.

In other words, to erase your EPROM you would first have to X-ray it
and then put it in an oven at about 600 degrees Celsius. The effects
of this process on the reliability of the part would have required
extensive testing so they decided on the window instead.

--------

Die 600´C macht das OTP-Plastikgehäuse nicht mit. Insofern ist
ist es letztlich doch urban-legend, selbst wenn es einen wahren
Kern hatte.

MfG JRD
Hanno Foest
2011-04-20 15:36:50 UTC
Permalink
Post by Rafael Deliano
Die 600´C macht das OTP-Plastikgehäuse nicht mit. Insofern ist
ist es letztlich doch urban-legend, selbst wenn es einen wahren
Kern hatte.
Na ja, es wird auch wohl ohne den thermischen Ausheilungsprozeß gehen,
ist nur nicht gut für den Chip, der kann halt nur eine bestimmte
Ionendosis ab.

Aber ein interessanter Artikel, danke.

Hanno
Heinz Schmitz
2011-04-20 09:41:27 UTC
Permalink
Post by Axel Schwenke
Interessanter ist die Sache mit dem Programmieralgorithmus. So
ca. ab 27(C)64 wurde angefangen mit 0.1ms Impulsen zu programmieren,
bis die Daten erstmals korrekt lesbar waren. Und dann nochmal das
doppelte der bisherigen Zeit drauf. Wenn die Daten schon drin stehen,
klappt das natürlich nicht mehr so ganz.
Bisher bin ich der Meinung, daß man immer versucht hat, die Zeit
für die gesamte Programmierung kurz zu kriegen. Wenn man aber
Zeit hat, sollte man beliebig lange nachprogrammieren können,
auch wenn die Zelle schon begriffen hat was man von ihr will.

Grüße,
H.
Axel Schwenke
2011-04-20 11:13:44 UTC
Permalink
Post by Heinz Schmitz
Post by Axel Schwenke
Interessanter ist die Sache mit dem Programmieralgorithmus. So
ca. ab 27(C)64 wurde angefangen mit 0.1ms Impulsen zu programmieren,
bis die Daten erstmals korrekt lesbar waren. Und dann nochmal das
doppelte der bisherigen Zeit drauf. Wenn die Daten schon drin stehen,
klappt das natürlich nicht mehr so ganz.
Bisher bin ich der Meinung, daß man immer versucht hat, die Zeit
für die gesamte Programmierung kurz zu kriegen.
Ja, das war wohl die Intention. Außerdem verringert man so den
Streß der Zellen und erhöht Lebensdauer und Anzahl Schreibzyklen.
Post by Heinz Schmitz
Wenn man aber
Zeit hat, sollte man beliebig lange nachprogrammieren können,
auch wenn die Zelle schon begriffen hat was man von ihr will.
Beliebig lange schon mal nicht. Zum einen kann man wohl die Zellen
kaputt kriegen, wenn man zu lange drauf rum brät. Zum zweiten deutet
eine zu lange Programmierzeit auf ein Problem hin und dann sollte man
das EPROM lieber entsorgen, weil die Zuverlässigkeit fraglich ist.

Aber das Problem das ich mit dem "intelligenten" Algo beim Nachpro-
grammieren sehe, ist dieses: wir wissen, daß das EPROM langsam Daten
verliert. Einige Zellen sind normal schon nicht mehr lesbar. Andere
hingegen schon. Der Algo wird jetzt nur die Zellen brennen, die
derzeit falsche Daten liefern. Die schwachen Zellen (die gerade noch
richtige Daten liefern) wird er nur mit minimaler Zeit brennen,
oder gar ganz ignorieren. Und die vergessen dann als nächstes.

Um das zum umgehen würde man

- entweder mit einem dummen Algo brennen: 50ms pro Adresse und gut
- intelligenter Algo, der eine sichere Mindestzeit verwendet
- intelligenter Algo, der sich an der schlechtesten Zelle im ganzen
Chip orientiert

Nachdem ich das gesagt habe, noch etwas aus Datenblättern. Ich habe
hier das Datenblatt des 27C128 von Microchip und NatSemi.
Beide programmieren mit 100µs-Impulsen. Bei Vcc=6.5V und Vpp=13V ist
dabei keinerlei Nachprogrammierung notwendig. Mit diesem Algo wird
die Sache dann gegenstandslos.


XL
Gerrit Heitsch
2011-04-20 16:10:56 UTC
Permalink
Post by Axel Schwenke
Aber das Problem das ich mit dem "intelligenten" Algo beim Nachpro-
grammieren sehe, ist dieses: wir wissen, daß das EPROM langsam Daten
verliert. Einige Zellen sind normal schon nicht mehr lesbar. Andere
hingegen schon. Der Algo wird jetzt nur die Zellen brennen, die
derzeit falsche Daten liefern. Die schwachen Zellen (die gerade noch
richtige Daten liefern) wird er nur mit minimaler Zeit brennen,
oder gar ganz ignorieren. Und die vergessen dann als nächstes.
Der Eprommer hier basiert auch einem 8749 (OTP, mal sehen wie lange der
noch mitmacht) und redet mit dem PC über eine RS232. Da denke ich mal,
dass der nicht allzu intelligent vorgeht. Also einfach Daten reinhauen
und erst dann nachsehen. Ergibt bei Zellen die noch lesbar sind also 1ms
plus 2ms Nachprogrammierzeit bei INTeL-Algo. Wenn ich das zweimal mache
müsste das ne Weile halten.

Ich hab allerdings noch nicht nachgemessen ob und wie weit er dabei Vcc
anhebt.
Post by Axel Schwenke
- entweder mit einem dummen Algo brennen: 50ms pro Adresse und gut
Den kann er auch noch. Bleibt die Frage ob das das EPROM mitmacht oder
ob die das schon nicht mehr mögen.

Gerrit
Holm Tiffe
2011-04-21 06:55:39 UTC
Permalink
Post by Gerrit Heitsch
Post by Axel Schwenke
Aber das Problem das ich mit dem "intelligenten" Algo beim Nachpro-
grammieren sehe, ist dieses: wir wissen, daß das EPROM langsam Daten
verliert. Einige Zellen sind normal schon nicht mehr lesbar. Andere
hingegen schon. Der Algo wird jetzt nur die Zellen brennen, die
derzeit falsche Daten liefern. Die schwachen Zellen (die gerade noch
richtige Daten liefern) wird er nur mit minimaler Zeit brennen,
oder gar ganz ignorieren. Und die vergessen dann als nächstes.
Der Eprommer hier basiert auch einem 8749 (OTP, mal sehen wie lange der
noch mitmacht) und redet mit dem PC über eine RS232. Da denke ich mal,
dass der nicht allzu intelligent vorgeht. Also einfach Daten reinhauen
und erst dann nachsehen. Ergibt bei Zellen die noch lesbar sind also 1ms
plus 2ms Nachprogrammierzeit bei INTeL-Algo. Wenn ich das zweimal mache
müsste das ne Weile halten.
Ich hab allerdings noch nicht nachgemessen ob und wie weit er dabei Vcc
anhebt.
Post by Axel Schwenke
- entweder mit einem dummen Algo brennen: 50ms pro Adresse und gut
Den kann er auch noch. Bleibt die Frage ob das das EPROM mitmacht oder
ob die das schon nicht mehr mögen.
Gerrit
Dieser Epromer ist ein Kotzbrocken der Firma Auerswald auch wenn er von
der 4ma Unrad vertrieben wurde.
Ich habe in den Ding schon viel herumgesucht und auch repariert. Holger
hat seinen übrigens von mir.

Das Hauptproblem ist, das der 8749 die RS232 in Software machen muß und
einfach zu langsam ist um rechtzeitig an den Modemcontrolsignalen Halt zu
brüllen wenn er ein Zeichen empfangen hat. Auf einem 286er mit GWBasic
lief das Sample Steuerprogramm anstandslos, bei schnelleren Rechnern gibt
es Probleme weil keine Pausen zwischen den Zeichen mehr eingelegt werden.
Das resultiert regelmäßig in Receiver Overflows.
Ich hatte einen Reserver 8749 an Holger mitgeschickt, hatte mir von Auerswald
mal einen neuen kommen lassen da ich einen Defekt vermutete, Nö, muß so sein.
Die 8749 sind nicht auslesegeschützt, Du kannst Deine Daten in Sicherheit
bringen in dem Du das Teil auslötest und ausliest.
Das restliche Design ist aber auch so naja.. schon die RS232 Treiber und
Empfänger geben deutlich zu denken...

Gruß,

Holm
Holger
2011-04-21 09:26:20 UTC
Permalink
Post by Holm Tiffe
Das Hauptproblem ist, das der 8749 die RS232 in Software machen muß und
einfach zu langsam ist um rechtzeitig an den Modemcontrolsignalen Halt zu
brüllen wenn er ein Zeichen empfangen hat.
Meine Software habe ich unter Freepascal geschreiben. Die Ansteuerung
der seriellen Schnittstelle funktioniert auch an schnellen Rechnern,
wenn man mit der Prozedur sleep(n) an allen neuralgischen Punkten die
Datenübertragung verzögert. Der Wert für n mußte jeweils ausprobiert
werden. Zweitens hat es sich als glücklicher erwiesen, wenn man als
Baudrate den Wert 2400 Bd verwendete, anstelle der technisch möglichen
9600 Bd, um das Gerät nicht zu überfordern.

Das eigentliche Problem bei diesem Prommer ist die Zuverlässigkeit der
Programmierspannung, deren Stabilität. Die Progammierspannung kann in
viel zu weiten Bereichen mit einem simplen Trimmer eingestellt werden,
und wenn du dem Trimmer mal ein wenig Kältespray gönnst, rutscht dir der
Spannungswert auf und davon. Das Teil erfordert unendlich viel Geduld
bei der Justage. Das wäre mit einem Wendeltrimmer leicht vermeidbar
gewesen. Außerdem habe ich den Verdacht, der Innenwiderstand der
Programmierspannungsquelle könnte zu hoch sein. Und drittens werden die
verschiedenen Programmierspannungen für die EPROMs mit einem TTL-IC
(74LS273) eingestellt, dessen Ausgänge einfach Spannungsteiler schalten.
Schon tricky, es kann eben nicht jedes 74LS273 verwendet werden.
Post by Holm Tiffe
Die 8749 sind nicht auslesegeschützt, Du kannst Deine Daten in Sicherheit
bringen in dem Du das Teil auslötest und ausliest.
Ist das Ding nicht voll kompatibel zum 8748? Das Binärfile würde mich
schon interessieren.
Post by Holm Tiffe
Das restliche Design ist aber auch so naja.. schon die RS232 Treiber und
Empfänger geben deutlich zu denken...
Ja. Aber meist funktioniert er ja.

Holger
--
Alzheimer ist ganz toll. Man lernt ständig neue Leute kennen.
Gerrit Heitsch
2011-04-23 16:26:15 UTC
Permalink
Post by Holger
Post by Holm Tiffe
Das Hauptproblem ist, das der 8749 die RS232 in Software machen muß und
einfach zu langsam ist um rechtzeitig an den Modemcontrolsignalen Halt zu
brüllen wenn er ein Zeichen empfangen hat.
Meine Software habe ich unter Freepascal geschreiben. Die Ansteuerung
der seriellen Schnittstelle funktioniert auch an schnellen Rechnern,
wenn man mit der Prozedur sleep(n) an allen neuralgischen Punkten die
Datenübertragung verzögert. Der Wert für n mußte jeweils ausprobiert
werden. Zweitens hat es sich als glücklicher erwiesen, wenn man als
Baudrate den Wert 2400 Bd verwendete, anstelle der technisch möglichen
9600 Bd, um das Gerät nicht zu überfordern.
Wobei ich zum Auslesen eines EPROMs die andere Software (das kleine
C-Programm) benutze, das liest mit 9600 zuverlässig und deutlich
schneller als deine Software aus. Kunststück, da bestimmt der 8749 das
Timing und jeder heutige Rechner langweilt sich bei 9600...

Zum Programmieren ist deine Software allerdings die bessere Lösung und
hat bisher noch keinen Ärger gemacht. Man muss sich eben etwas Zeit
nehmen...
Post by Holger
Post by Holm Tiffe
Das restliche Design ist aber auch so naja.. schon die RS232 Treiber und
Empfänger geben deutlich zu denken...
Ja. Aber meist funktioniert er ja.
Sieht so aus, ja, wenn das EPROM sauber programmiert wurde und den
Vergleich bestanden hat, dann bleiben die Daten auch drin. So zumindest
meine Erfahrung.

Gerrit
Hanno Foest
2011-04-23 17:11:06 UTC
Permalink
Post by Gerrit Heitsch
Sieht so aus, ja, wenn das EPROM sauber programmiert wurde und den
Vergleich bestanden hat, dann bleiben die Daten auch drin. So zumindest
meine Erfahrung.
Ich kann mich an mindestens eine gegenteilige Erfahrung erinnern.
BIOS-Update für ein 286-Board (2 EPROMs) gebrannt, ging nach zwei Tagen
nicht mehr, einer der Steine war vergeßlich geworden. War nicht kaputt,
nach Neuprogrammierung hielt das Jahre. Details, was da schief gelaufen
war, weiß ich leider nicht mehr. Auch nicht, ob ich damals das EPROM vor
dem Neuprogrammieren gelöscht hatte.

Hanno
Gerrit Heitsch
2011-04-23 17:22:15 UTC
Permalink
Post by Hanno Foest
Post by Gerrit Heitsch
Sieht so aus, ja, wenn das EPROM sauber programmiert wurde und den
Vergleich bestanden hat, dann bleiben die Daten auch drin. So zumindest
meine Erfahrung.
Ich kann mich an mindestens eine gegenteilige Erfahrung erinnern.
BIOS-Update für ein 286-Board (2 EPROMs) gebrannt, ging nach zwei Tagen
nicht mehr, einer der Steine war vergeßlich geworden.
Ich bezog mich hier auf meine Erfahrungen mit dem EPROG27011.

Gerrit
Holger
2011-04-24 19:39:28 UTC
Permalink
Post by Gerrit Heitsch
Wobei ich zum Auslesen eines EPROMs die andere Software (das kleine
C-Programm) benutze, das liest mit 9600 zuverlässig und deutlich
schneller als deine Software aus. Kunststück, da bestimmt der 8749 das
Timing und jeder heutige Rechner langweilt sich bei 9600...
Du kannst mit der Option -b9600 in der Kommandozeile dafür sorgen, daß
mit 9600 Bd. gearbeitet wird. Allerdings wirst du die DIP-Schalter im
EPROG auf 9600 setzen müssen, damit der dich überhaupt versteht. Die
Kiste kann sich nunmal nicht automatisch auf die passende Baudrate
einstellen.

Holger
--
Alzheimer ist ganz toll. Man lernt ständig neue Leute kennen.
Gerrit Heitsch
2011-04-24 19:44:50 UTC
Permalink
Post by Holger
Post by Gerrit Heitsch
Wobei ich zum Auslesen eines EPROMs die andere Software (das kleine
C-Programm) benutze, das liest mit 9600 zuverlässig und deutlich
schneller als deine Software aus. Kunststück, da bestimmt der 8749 das
Timing und jeder heutige Rechner langweilt sich bei 9600...
Du kannst mit der Option -b9600 in der Kommandozeile dafür sorgen, daß
mit 9600 Bd. gearbeitet wird. Allerdings wirst du die DIP-Schalter im
EPROG auf 9600 setzen müssen, damit der dich überhaupt versteht. Die
Kiste kann sich nunmal nicht automatisch auf die passende Baudrate
einstellen.
9600 benutze ich sowieso, auch mit deiner Software. Allerdings ist die
andere beim Auslesen trotzdem deutlich fixer. Dafuer kann ich damit
nicht programmieren, klappt nicht.

Gerrit
Holger
2011-04-24 21:10:59 UTC
Permalink
Post by Gerrit Heitsch
9600 benutze ich sowieso, auch mit deiner Software. Allerdings ist die
andere beim Auslesen trotzdem deutlich fixer. Dafuer kann ich damit
nicht programmieren, klappt nicht.
Naja, ich kann nur für meine Software sprechen. Die "Langsamkeit" beim
Auslesen hat, sweit ich das sehe, drei Gründe:

1. Es gibt die Möglichkeit eines Verboose-Modus. Damit kann man den
Datenverkehr vom und zum EPROG beobachten und mitschneiden.

2. Es wird ein Byte-Zähler hochgezählt und auf dem Bildschirm angezeigt.
Das kostet Rechenzeit und verlangsamt den Download.

3. Zwischen den einzelnen Lesezugriffen werden kurze Pausen eingelegt,
um die RS-232 vom EPROG nicht zu überfahren.

Ich halte diese Verzögerungen für vertretbar, weil ich Datenfehler
vermeiden will. Auch die Anzeige des Fortschritts halte ich für wichtig,
weil man so abschätzen kann, wie lange die Datenübertragung noch dauert.
In einer späteren Version wird der Datentransfer ggf. geringfügig
schneller sein, muß ich nochmal sehen. "Korrekt" ist mir allerdings
wichtiger als "schnell".

Grüße, Holger
--
Alzheimer ist ganz toll. Man lernt ständig neue Leute kennen.
Gerrit Heitsch
2011-04-24 21:38:20 UTC
Permalink
Post by Holger
Post by Gerrit Heitsch
9600 benutze ich sowieso, auch mit deiner Software. Allerdings ist die
andere beim Auslesen trotzdem deutlich fixer. Dafuer kann ich damit
nicht programmieren, klappt nicht.
Naja, ich kann nur für meine Software sprechen. Die "Langsamkeit" beim
1. Es gibt die Möglichkeit eines Verboose-Modus. Damit kann man den
Datenverkehr vom und zum EPROG beobachten und mitschneiden.
Kann die andere Software auch, statt 'r' ein 'rv' als Option und ich
bekomme einen Zähler im Format 'x von y Bytes' wobei das x hochzählt und
das y die Grösse angibt.
Post by Holger
3. Zwischen den einzelnen Lesezugriffen werden kurze Pausen eingelegt,
um die RS-232 vom EPROG nicht zu überfahren.
Scheint nicht so das Problem zu sein. Ich hab extra einiges an Tests
gemacht, und bisher gab es beim Auslesen eines korrekt programmierten
EPROMs (also nicht mein morsches OTP) nie einen Fehler.
Post by Holger
Ich halte diese Verzögerungen für vertretbar, weil ich Datenfehler
vermeiden will. Auch die Anzeige des Fortschritts halte ich für wichtig,
weil man so abschätzen kann, wie lange die Datenübertragung noch dauert.
In einer späteren Version wird der Datentransfer ggf. geringfügig
schneller sein, muß ich nochmal sehen. "Korrekt" ist mir allerdings
wichtiger als "schnell".
Klar, mir auch, es darf allerdings gerne so schnell wie ohne Fehler
machbar sein. Ich werde an meinem Setup hier erstmal nichts ändern,
deine Software erledigt das Programmieren und die andere das Auslesen.
Zumindest hier tun beide das zuverlässig.

Gerrit
Ingo Braune
2011-04-21 18:06:11 UTC
Permalink
Post by Holm Tiffe
Dieser Epromer ist ein Kotzbrocken der Firma Auerswald auch wenn er von
der 4ma Unrad vertrieben wurde.
Ich habe in den Ding schon viel herumgesucht und auch repariert. Holger
hat seinen übrigens von mir.
Das Hauptproblem ist, das der 8749 die RS232 in Software machen muß und
einfach zu langsam ist um rechtzeitig an den Modemcontrolsignalen Halt zu
brüllen wenn er ein Zeichen empfangen hat. Auf einem 286er mit GWBasic
lief das Sample Steuerprogramm anstandslos, bei schnelleren Rechnern gibt
es Probleme weil keine Pausen zwischen den Zeichen mehr eingelegt werden.
Das resultiert regelmäßig in Receiver Overflows.
Ich erinner mich dunkel. War damals ein echter Kampf den am Atari XL
ans Laufen zu bringen - der Atari war einfach viel zu schnell mit
seinen 1,79?MHz...


Ingo
Axel Schwenke
2011-04-21 10:53:12 UTC
Permalink
Post by Gerrit Heitsch
Der Eprommer hier basiert auch einem 8749 (OTP, mal sehen wie lange der
noch mitmacht) und redet mit dem PC über eine RS232. Da denke ich mal,
dass der nicht allzu intelligent vorgeht. Also einfach Daten reinhauen
und erst dann nachsehen. Ergibt bei Zellen die noch lesbar sind also 1ms
plus 2ms Nachprogrammierzeit bei INTeL-Algo. Wenn ich das zweimal mache
müsste das ne Weile halten.
Kommt auf den Chip an. Und ob er bei erhöhter Vcc programmiert wird
(vermutlich nicht und das ist eher schlecht für die Zuverlässigkeit)
Post by Gerrit Heitsch
... mit einem dummen Algo brennen: 50ms pro Adresse und gut
Den kann er auch noch. Bleibt die Frage ob das das EPROM mitmacht oder
ob die das schon nicht mehr mögen.
Ich habe hier noch das Datenblatt für den 27128 (also ohne C) von ST
aufgetan. Der will mit 1ms-Impulsen programmiert werden, bis er die
Daten gefressen hat und dann das dreifache nochmal drauf. Der Nach-
brenn-Impuls darf bis 78ms lang sein. Der könnte das also.

Die 27C128 Datenblätter die ich hier habe, spezifizieren alle nix
außer dem "Fast"-Modus mit 100µs Impulsen. Von Hersteller zu Hersteller
unterscheiden sich Vcc und maximale Pulszahl noch marginal. Ich kann
mich aber erinnern, daß ich früher(!) mit dem C64(!) Userport-Brenner
auch 27C256 und 27C512 gebrannt habe. Und der konnte sicher keine
100µs-Impulse und so. Hat trotzdem funktioniert.

Irnkwo habe ich noch ein paar OTP-27C256 rumfliegen. Sag Bescheid,
wenn du einen haben willst.


XL
Michael Schwingen
2011-04-21 19:44:47 UTC
Permalink
Post by Heinz Schmitz
Bisher bin ich der Meinung, daß man immer versucht hat, die Zeit
für die gesamte Programmierung kurz zu kriegen. Wenn man aber
Zeit hat, sollte man beliebig lange nachprogrammieren können,
auch wenn die Zelle schon begriffen hat was man von ihr will.
Nein. Ich hatte einen Fall mit einem EPROM, das eigentlich einen der neueren
Turbo-Algorithmen (IIRC 0.1ms) wollte, und das ich mit 50ms programmiert
habe. Da waren dann zuviele Bits auf 0 gekippt.

cu
Michael
Gerhard Hoffmann
2011-04-21 20:44:09 UTC
Permalink
Post by Michael Schwingen
Post by Heinz Schmitz
Bisher bin ich der Meinung, daß man immer versucht hat, die Zeit
für die gesamte Programmierung kurz zu kriegen. Wenn man aber
Zeit hat, sollte man beliebig lange nachprogrammieren können,
auch wenn die Zelle schon begriffen hat was man von ihr will.
Nein. Ich hatte einen Fall mit einem EPROM, das eigentlich einen der neueren
Turbo-Algorithmen (IIRC 0.1ms) wollte, und das ich mit 50ms programmiert
habe. Da waren dann zuviele Bits auf 0 gekippt.
Beim Programmieren eines Eproms werden Elektronen auf ein Gate
getunnelt, das ansonsten von SiO2 von astraler Reinheit umgeben
ist. Wenn man beliebig lange Elektronen nachschiebt, geht irgendwann
die Isolation kaputt weil die Gatespannung immer mehr ansteigt.

Das ist wie bei einer Schraube. Nach ganz fest kommt ganz ab.

Wenn ein Eprom schon soviel Elektronen von den Gates verloren
hat, dass Alzheimer auftritt, dann sind die Chancen aber gut,
dass es eine Neuprogrammierung mit dem gleichen Inhalt überlebt.

Weil es vermutlich weniger Pulse braucht bis der erwartete Output
wieder auftritt, fällt der Faktor "n-mal soviel wie zum Kippen des
Bits notwendig" möglicherweise zu klein aus. Aber das kann einen
ja trotzdem 10 Jahre weiterbringen.

Die OTPs sollen sich mit dem Röntgengerät beim Zahnarzt durchaus
löschen lassen. Es sind ja normale Eproms, man war nur für ein
Keramikgehäuse mit Quarzglasfenster zu geiz^w^w^w^w kostenbewusst.

Gruß, Gerhard
Axel Schwenke
2011-04-22 08:57:17 UTC
Permalink
Post by Gerhard Hoffmann
Post by Michael Schwingen
Ich hatte einen Fall mit einem EPROM, das eigentlich einen der neueren
Turbo-Algorithmen (IIRC 0.1ms) wollte, und das ich mit 50ms programmiert
habe. Da waren dann zuviele Bits auf 0 gekippt.
Beim Programmieren eines Eproms werden Elektronen auf ein Gate
getunnelt, das ansonsten von SiO2 von astraler Reinheit umgeben
ist. Wenn man beliebig lange Elektronen nachschiebt, geht irgendwann
die Isolation kaputt weil die Gatespannung immer mehr ansteigt.
Ähm. Jein. Das wäre so, wenn man denn wirklich Elektronen nach-
schieben würde. In Wirklichkeit tunneln die Elektronen aber nicht
ohne Potentialdifferenz. Größer als die Programmierspannung wird
die Spannung auf dem isolierten Gate also nicht werden. Und soviel
muß die Isolation eigentlich abkönnen.


XL
Gerhard Hoffmann
2011-04-22 09:39:02 UTC
Permalink
Post by Axel Schwenke
Ähm. Jein. Das wäre so, wenn man denn wirklich Elektronen nach-
schieben würde. In Wirklichkeit tunneln die Elektronen aber nicht
ohne Potentialdifferenz. Größer als die Programmierspannung wird
die Spannung auf dem isolierten Gate also nicht werden. Und soviel
muß die Isolation eigentlich abkönnen.
Schau Dir mal VGSmax bei einem PowerFET an, und die Minimalfets
in den Eproms sind deutlich zarter.
Dass die heutigen Flashes mit 3V3 oder 5V laufen können liegt
nur daran, dass sie eine Ladungspumpe eingebaut haben, wie man
sie auch aus MAX232 etc kennt.
Post by Axel Schwenke
XL
G.
Axel Schwenke
2011-04-22 17:17:04 UTC
Permalink
Post by Gerhard Hoffmann
Post by Axel Schwenke
Größer als die Programmierspannung wird
die Spannung auf dem isolierten Gate also nicht werden. Und soviel
muß die Isolation eigentlich abkönnen.
Schau Dir mal VGSmax bei einem PowerFET an, und die Minimalfets
in den Eproms sind deutlich zarter.
Dass die heutigen Flashes mit 3V3 oder 5V laufen können liegt
nur daran, dass sie eine Ladungspumpe eingebaut haben, wie man
sie auch aus MAX232 etc kennt.
Was hat das eine mit dem anderen zu tun? Fakt ist nun mal:

1. mit einer Programmierspannung von z.B. 12V wirst du nicht mehr
als diese 12V auf das Floating Gate raufbekommen. Ich rechne
eher mit 1-2V. Die Ladung auf dem F.G. soll ja nur die Schwell-
spannung des FETs verschieben.

2. für besagte 12V ist der ganze Aufbau aber ausgelegt. Denn die
liegen ja beim Programmieren an, ohne daß die Zelle kaputt geht.

Deswegen ist deine Theorie "bei zu langen Programmierimpulsen wird
die Spannung auf dem Floating Gate zu hoch" nicht tragfähig. Ich
zweifle nicht daran, daß EPROMs mit zu langen Programmierimpulsen
kaputt zu kriegen sind. Aber der Mechanismus ist ein anderer.


XL
Michael Schwingen
2011-04-22 14:10:38 UTC
Permalink
Post by Axel Schwenke
Ähm. Jein. Das wäre so, wenn man denn wirklich Elektronen nach-
schieben würde. In Wirklichkeit tunneln die Elektronen aber nicht
ohne Potentialdifferenz. Größer als die Programmierspannung wird
die Spannung auf dem isolierten Gate also nicht werden. Und soviel
muß die Isolation eigentlich abkönnen.
Aber nicht beliebig lange - es gibt z.B. 3.3V-Flashs, die man optional zur
beschleunigten Programmierung mit 12V Vpp versorgen kann - das Datenblatt
nennt da Maximalzeiten.

Außerdem stellt sich die Frage, ob nicht durch Leckströme o.ä. auch Ladungen
auf die Nachbar-Gates kommen.

cu
Michael
Axel Schwenke
2011-04-22 17:28:33 UTC
Permalink
Post by Michael Schwingen
Post by Axel Schwenke
Ähm. Jein. Das wäre so, wenn man denn wirklich Elektronen nach-
schieben würde. In Wirklichkeit tunneln die Elektronen aber nicht
ohne Potentialdifferenz. Größer als die Programmierspannung wird
die Spannung auf dem isolierten Gate also nicht werden. Und soviel
muß die Isolation eigentlich abkönnen.
Aber nicht beliebig lange - es gibt z.B. 3.3V-Flashs, die man optional zur
beschleunigten Programmierung mit 12V Vpp versorgen kann - das Datenblatt
nennt da Maximalzeiten.
Außerdem stellt sich die Frage, ob nicht durch Leckströme o.ä. auch Ladungen
auf die Nachbar-Gates kommen.
Wir reden hier über EPROMs. Also Technik von vor 20-30 Jahren. Mit
Programmierspannungen von 12.5 - 25V. Nix Ladungspumpe. Und auch
ohne Zeitbeschränkung, wie lange Vpp am Chip anliegen darf.
Und mit 3.3V geht da noch gar nix.


XL
Gerrit Heitsch
2011-04-23 16:30:20 UTC
Permalink
Post by Gerhard Hoffmann
Post by Michael Schwingen
Post by Heinz Schmitz
Bisher bin ich der Meinung, daß man immer versucht hat, die Zeit
für die gesamte Programmierung kurz zu kriegen. Wenn man aber
Zeit hat, sollte man beliebig lange nachprogrammieren können,
auch wenn die Zelle schon begriffen hat was man von ihr will.
Nein. Ich hatte einen Fall mit einem EPROM, das eigentlich einen der neueren
Turbo-Algorithmen (IIRC 0.1ms) wollte, und das ich mit 50ms programmiert
habe. Da waren dann zuviele Bits auf 0 gekippt.
Beim Programmieren eines Eproms werden Elektronen auf ein Gate
getunnelt, das ansonsten von SiO2 von astraler Reinheit umgeben
ist. Wenn man beliebig lange Elektronen nachschiebt, geht irgendwann
die Isolation kaputt weil die Gatespannung immer mehr ansteigt.
Dann wären diese Bits aber wieder 1 weil sich die Elektronen wieder
verkrümeln. Bei einem EPROM sind nach dem Löschen alle Bits gesetzt, du
liest '$FF'.
Post by Gerhard Hoffmann
Die OTPs sollen sich mit dem Röntgengerät beim Zahnarzt durchaus
löschen lassen. Es sind ja normale Eproms, man war nur für ein
Keramikgehäuse mit Quarzglasfenster zu geiz^w^w^w^w kostenbewusst.
Die OTPs kamen als Ersatz für die teuren PROMs bzw. Masken-ROMs, ein
EPROM sollten sie eigentlich nicht ersetzen.

Zumindest Commodore hat sie damals nie verwendet. Entweder war ein
echtes EPROM in der Kiste (C128 mit DIN-Keyboard z.B.) oder es waren
echte Masken-ROMs. Letztere vergessen eher selten. :)

Gerrit
Bjoern Wieck
2011-04-23 18:39:10 UTC
Permalink
Post by Gerrit Heitsch
Zumindest Commodore hat sie damals nie verwendet. Entweder war ein
echtes EPROM in der Kiste (C128 mit DIN-Keyboard z.B.) oder es waren
echte Masken-ROMs. Letztere vergessen eher selten. :)
Gerrit
Masken-ROMs waren bei den Stückzahlen billiger als Eproms.
Meiner Erfahrung nach gehen die ROMs von Commodore recht häufig
oder schneller kaputt als EProms. Kann aber auch daran liegen
das die Masken-ROMs in NMOS gefertigt waren und im Betrieb
sehr warm wurden.
Gerrit Heitsch
2011-04-23 19:23:31 UTC
Permalink
Post by Bjoern Wieck
Post by Gerrit Heitsch
Zumindest Commodore hat sie damals nie verwendet. Entweder war ein
echtes EPROM in der Kiste (C128 mit DIN-Keyboard z.B.) oder es waren
echte Masken-ROMs. Letztere vergessen eher selten. :)
Gerrit
Masken-ROMs waren bei den Stückzahlen billiger als Eproms.
Meiner Erfahrung nach gehen die ROMs von Commodore recht häufig
oder schneller kaputt als EProms.
Ich hatte noch kein defektes. Allerdings ersetze ich die Masken-ROMs
gerne durch CMOS-EPROMs, so möglich. Beim gerne verbauten 2364 ist ohne
Adapter aber nichts zu machen und beim 2332 bräuchte man ein 2532 EPROM
als direkten Ersatz. Die gibts auch nicht in CMOS. Lohnt also erst ab
dem 23128, da kann man einfach ein 27C128 für verwenden.

Leider ist die Belegung des Sockels meist falsch. Das EPROM wird so über
_OE gesteuert, _CS liegt fest auf GND. Steuerung über _CS würde noch ein
paar mA mehr sparen. _CS fest auf GND und _OE als Freigabe macht man
doch nur wenn es bei der Zugriffszeit knapp ist.
Post by Bjoern Wieck
Kann aber auch daran liegen
das die Masken-ROMs in NMOS gefertigt waren und im Betrieb
sehr warm wurden.
Das 'sehr' stimmt so nicht. Sie wurden warm, ja. Aber mehr auch nicht.
Keine Spur von der Hitze eines SID 6581 oder VIC 6569 (diese Chips
wollten zusätzlich zu +5V noch +12V).

Gerrit
Bjoern Wieck
2011-04-23 22:41:40 UTC
Permalink
Post by Gerrit Heitsch
Das 'sehr' stimmt so nicht. Sie wurden warm, ja. Aber mehr auch nicht.
Keine Spur von der Hitze eines SID 6581 oder VIC 6569 (diese Chips
wollten zusätzlich zu +5V noch +12V).
Gerrit
Ok, für mich ist >45 Grad schon viel.
Die VIC, SID, PLA sowie die CPU wurden auch immer
gut warm.. VIC und SID auch ohne die 12V.
Meistens ist zuerst die PLA (ein 82S100) gestorben, der VIC sogut wie
nie obwohl er Temperaturmässig an der Spitzenposition ist.

Aber mal aus der Nähkiste:
Ich habe so gefühlte 160 C64 Boards repariert und versuch mal ne
Hitliste der kaputten Chips wagen:

1. CIA wegen ESD (die alten C64 Boards hatten genau garkeinen Schutz)
2. PLA wegen Überhitzung
3. SID auch wegen ESD
4. MaskenROMs, hier sehr gerne das Basic-ROM
5. TTL-Chips die von Commodore in Lizenz gefertigt wurden (77xx mit MOS
Logo drauf)
6. RAM-Multiplexer (74LS257)
7. RAM selbst, aber meistens erst dann wenn Das Netzteil versagt und
Überspannung raushaut.


Bei dem bekannten Disklaufwerk 1541 gab es sehr oft diese Fehler:

1. Gleichrichter defekt > Dauerlauf
2. DOS-ROM defekt > Dauerlauf
3. Liest schlecht und schreibt nicht > Regeltransistor für die
analoge Schreib-Lese Elektronik defekt oder Kopf selbst.

Es gab natürlich auch noch jede Menge andere Fehler, aber das sind
die mit Abstand häufigsten vorgekommenen.
Gerrit Heitsch
2011-04-24 07:15:27 UTC
Permalink
Post by Bjoern Wieck
Post by Gerrit Heitsch
Das 'sehr' stimmt so nicht. Sie wurden warm, ja. Aber mehr auch nicht.
Keine Spur von der Hitze eines SID 6581 oder VIC 6569 (diese Chips
wollten zusätzlich zu +5V noch +12V).
Gerrit
Ok, für mich ist >45 Grad schon viel.
Die VIC, SID, PLA sowie die CPU wurden auch immer
gut warm.. VIC und SID auch ohne die 12V.
Meistens ist zuerst die PLA (ein 82S100) gestorben, der VIC sogut wie
nie obwohl er Temperaturmässig an der Spitzenposition ist.
Die PLA war im Original ein 82S100 und konnt auch später durch ein
solchen, korrekt programmierten ersetzt werden. Die Frage ist aber, was
war in dem Chip mit dem Aufdruck 906114-01 wirklich drin? Ein echter
PLA-Chip oder ein Custom-Chip der gar nicht erst programmiert werden
musste? Letzteres müsste bei den beim C64 vorgekommenen Auflagen
billiger gewesen sein wenn man, wie C=, die Fertigung solcher Chips in
house hatte.
Post by Bjoern Wieck
Ich habe so gefühlte 160 C64 Boards repariert und versuch mal ne
1. CIA wegen ESD (die alten C64 Boards hatten genau garkeinen Schutz)
2. PLA wegen Überhitzung
Die kam mir gar nicht so heiss vor. Ist wohl im Gegensatz zum VIC nicht
besonders hitzefest.
Post by Bjoern Wieck
3. SID auch wegen ESD
4. MaskenROMs, hier sehr gerne das Basic-ROM
Komisch... Wegen der Belastung durch den VIC hätte ich eher an das
Character-ROM gedacht.
Post by Bjoern Wieck
7. RAM selbst, aber meistens erst dann wenn Das Netzteil versagt und
Überspannung raushaut.
Wobei das Netzteil ein interessantes Beispiel von 'auf Kante genäht'
ist. Ein Gleichrichter aus 1N4001, aber 1.5A Strom liefern. Bei den
ersten noch der Schaltungsfehler dass der Spannungsteiler, der den
GND-Pin des 7805 um 0,2V anheben soll nicht funktioniert (Widerstand
zwecklos :))

Defekte RAMs hab ich allerdings bei solch alten Rechnern inzwischen
deutlich häufiger. 4164 oder 41464, manchmal sterben nur Teile (Wirre
Zeichen auf dem Monitor), manchmal ist der Chip einfach tot und manchmal
hat er Kernschmelze (wird extrem heiss). Das ohne weitere Fehler im
Rechner, RAM gewechselt, alles geht wieder.
Post by Bjoern Wieck
1. Gleichrichter defekt > Dauerlauf
2. DOS-ROM defekt > Dauerlauf
3. Liest schlecht und schreibt nicht > Regeltransistor für die
analoge Schreib-Lese Elektronik defekt oder Kopf selbst.
Das mit dem defekten Kopf scheint bei den Laufwerken von Mitsumi
haeufiger vorzukommen als bei denen von Alps.

Gerrit
Gernot Fink
2011-04-23 19:28:01 UTC
Permalink
Post by Bjoern Wieck
oder schneller kaputt als EProms. Kann aber auch daran liegen
das die Masken-ROMs in NMOS gefertigt waren und im Betrieb
sehr warm wurden.
Ich denk eher es lag am auf der Rückseite offenliegenden Bus. Ich erinner
mich dass die RAMs die häufigste Ausfallursache war.
--
MFG Gernot
Bjoern Wieck
2011-04-23 23:11:49 UTC
Permalink
Post by Gernot Fink
Ich denk eher es lag am auf der Rückseite offenliegenden Bus. Ich erinner
mich dass die RAMs die häufigste Ausfallursache war.
Der offenliegende Bus namens Expansionsport ist eine unsaubere Sache für
sich, spielt aber erst dann eine Rolle wenn versucht wird per Abzweiger
das ganze nochmals zu erweitern.
Da gab es abenteuerliche Konstruktionen die das ganze auf 3-4 Ports
hochgejubelt haben und letztendlich nur VCC an/aus schalten konnten.

Bessere konnten dann den Takt, IO-Melder und einiges anderes noch
umschalten aber krankten daran das man nicht beliebig die Daten
und Adressleitungen länger machen kann ohne ein Problem mit
Signalrelexion zu bekommen.

Deswegen sind diese Portweichen ein NO-GO und auch hartgesottene
C64-User können bestätigen das Ungereihmtheiten im Betrieb direkt
durch entfernen der besagten Weiche sofort aufhören.

Und das mit dem kaputten RAM, das liegt hauptsächlich daran
das die beigelegten Netzteile leider im Fehlerfall eher dazu neigten
auf der 5V Schiene mehr Spannung rauszugeben als sie sollten.
Das RAM war da früher deutlich empfindlicher als die 74LSxx.
Loading...