Forum: Mikrocontroller und Digitale Elektronik OTP "E"EPROM programmieren amd 27c010


von Barney G. (fuzzel)


Angehängte Dateien:

Lesenswert?

Hi alle,

ich habe zwei HP/Agilent 53131A Zaehler, als defekt, geschnappt. gehen 
wieder.

ABER:

Bei einem ist das "E"EPROM U8 durch, fehlte. Nun habe ich das aus dem 
anderen Zaehler genommen, geht. Selbe Firmware.

Ergo, habe ich ersatz "E"EPROMs bestellt. 150er (Original) waren schwer 
zu bekommen, leider nur 2 Stk.  Aber neu, eben weil es OTP sind.

Dazu habe ich 120er im 10er Pack gekauft. Laut Datenblatt kompatibel. 
Seite 3

(Siehe Anhang)

Diese 120er habe ich mit der Kopie des funktionierenden U8 programmiert. 
Geht aber nicht !
Fehlermeldung "Wrong ROM" oder sowas.

Also bin ich hingegangen und habe alle 4 "E"EPROMs auf die 120er 
programmiert. Da ging dann garnichts mehr.

Das Programmiergeraet ist ein "MiniPro TL866"
https://www.youtube.com/watch?v=FLG03f_ua5g

Tut es auch ganz gut. Jedenfalls konnte ich bisher alles programmieren 
was ich wollte. Nur hier nicht.
Wenn ich die amd 27c010 programmiere, sind die Werte identisch. Trotzdem 
sagt mir das Geraet "ROM Error" oder sowas, weiss ich jetzt nicht so 
genau.

Wenn ich die "E"EPROMs aber vergleiche, haben beide die selbe 
Checksumme.

Gibt es da vielleicht irgendwas was ich nicht bedenke bzw nicht weiss ?

Auch unnuetze Ideen willkommen, vielleicht kann man darauf ja aufbauen.

Warum ich "E"EPROM in Klammern geschrieben habe.
Ein EEPROM ist elektronisch loeschbar. Das erste "E". Ein OTP ist aber 
angeblich nur einmal beschreibbar, was aber nicht stimmt. denn man kann 
es nochmal loeschen, also mit FF ueberschreiben. Daher passt weder 
EEPROM noch EPROM zu dem Ding. Meine Meinung.

Okay, genug gelabert, wie bekomme ich ein "E"EPROM beschrieben das es 
auch funktioniert ?

Ich kann gerne ein Video machen was es fuer Einstellmoeglichkeiten in 
diesen Programm gibt. Ich habe Kopien als BIN und iHEX. Das Original 
kann ich gerade nicht auslesen weil das geraet in einem 
Langzeitexperiment steckt. Rubidium vs GPS Normal.

Ja, ich weiss, ich schreibe immer ellenlange Texte, es faellt mir halt 
schwer mich praezise in Kurzform auszudruecken.

von B.P. (Gast)


Lesenswert?

Barney Geroellheimer schrieb:
> Ja, ich weiss, ich schreibe immer ellenlange Texte, es faellt mir halt
> schwer mich praezise in Kurzform auszudruecken.

Wie wusste der französischer Mathematiker und Physiker Blaise Pascal das 
so treffend zu formulieren: "Entschuldigen Sie, dass ich Ihnen einen 
langen Brief schreibe, für einen kurzen habe ich keine Zeit." - Lettres 
Provinciales, SEIZIÈME LETTRE

(Original franz.: "Mes révérends pères, mes lettres n'a voient pas 
accoutumé de se suivre de si près, ni d'être si étendues. Le peu de 
temps que j'ai eu a été cause de l'un et de l'autre. Je n'ai fait 
celle-ci plus longue que parceque je n'ai pas eu le loisir de la faire 
plus courte.")

von Frank K. (fchk)


Lesenswert?

Wenn es wirklich OTP sind, wirst Du sie nicht neu programmieren können. 
EPROMs haben Speicherzellen, die im unprogrammierten Zustand auf 1 sind. 
Du kannst eine 1 nur in eine 0 ändern, aber eine 0 nicht wieder in eine 
1. Wenn Du also FF (alles 1-Bits) in jedes Byte reinschreibst, passiert 
also genau gar nichts. Beim Verify solltest Du jedoch einen Fehler 
bekommen. Bekommst Du das nicht, ist Deine Programmierhardware im Eimer.

Welche Speicherbausteine sind im Originalzustand drin? Bitte GENAUE 
Typenbezeichnung und Hersteller! Notfalls lesbares Foto, dann kannst Du 
nichts unterschlagen.

fchk

von Barney G. (fuzzel)


Lesenswert?

Frank K. schrieb:
> Wenn es wirklich OTP sind, wirst Du sie nicht neu programmieren können.

Das weiss ich, denn das ist mein Problem. Die OTPs sind ja nun nicht 
gerade einfach zu bekommen und wenn es "Normale UV Eproms" waeren haette 
ich keine Probleme, denn da kann ich 10000x ausprobieren. Die haette ich 
sogar hier, nur brauche ich einen Adapter PLLCC zu DIL, die ersta mal 
sau teuer sind, zweitens mechanisch garnicht passen und drittens mag ich 
solch ein Gefummel garnicht.

Verify laeuft durch, ohne Fehler.

Original sind es AM27C010-150 siehe Beschreibung und Datenblatt. Nur 
funktioniert das nicht.

Wie schon geschrieben. Die "E"EPROMs sind 1:1 programmiert. sagt mir der 
hex Vergleich und auch das Brennertool. Nur das Geraet weigert sich 
diesen oder alle 4 EEPROMs zu erkennen.

Das es am Toaster liegt bezweifle ich, wenn dann am Programm selbst.

Wie gesagt, ich kann ein Video machen, dass es 1:1 durch laeuft, aber 
das kostet mich wieder einen 5.- Chip. Muss nicht sein.

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Welche Teilenummer hat das Board, wo die EPROMs drin stecken?
Müsste irgendwas in der Richtung 53131-xxxxx sein.

Welche Bauform? PLCC oder DIL?

fchk

von Ro V. (robyn)


Lesenswert?

Barney Geroellheimer schrieb:
> Das weiss ich, denn das ist mein Problem. Die OTPs sind ja nun nicht
> gerade einfach zu bekommen und wenn es "Normale UV Eproms" waeren haette
> ich keine Probleme, denn da kann ich 10000x ausprobieren.

Warum nimmst du die normalen dann nicht? IMHO Sind die OTP versionen nur 
die billig Versionen bei denen das teure Quarzfenster weggelassen wurde.

von eprom (Gast)


Lesenswert?

Billige Eproms scheinen in letzter Zeit gefälscht zu sein. Z.B. Aufdruck 
mit Aceton abwischbar und solche Scherze ...
Wenn du es nicht hinkriegst kann ich dir ein Eprom zu Portokosten 
brennen und zusenden.

von AlsGasthier (Gast)


Lesenswert?

Vielleich kann es sein, daß den Programmer die Adressen nicht wirklich 
vollständig anlegt, und es so dazu kommt, daß es z.B. eine 
Adressbereichshälfte quasi 2 mal dargestellt wird. Dann ist es immer 
möglich, daß der Vergleich sauber durchläuft, aber trotzdem nichts geht.

Vielleicht hast du die Möglichkeit auf einen anderen Programmer 
zuzugreifen um das auszuschließen.

Alternativ schaust du dir das Hexfile einmal an und suchst am Anfang, 
bei einem viertel, und einem halben Adressbereich einmal nach 
identischen Folgen.

Das was du beschreibst, habe ich so noch nicht erlebt, und egal ob 
EEprom, Rom oder OTP, das sollte auf jeden Fall laufen. Es gibt imho 
auch noch die Möglichkeit, daß die Pinbelegung womöglich nicht ganz 
identisch ist...
Das kann man ja auch mal leicht kontrollieren durch studieren des 
Datenblattes...

Viel Erfolg.

von Frank K. (fchk)


Lesenswert?

So. Du kannst mal anstelle Deiner EPROMs Flashes ausprobieren.
Und zwar Microchip/SST   SST39SF010A-70-4C-NHE.
Teilenummer bei Farnell: 1368661
Teilenummer bei RS: 823-4490
81 Cent pro Stück (netto) bei Farnell, und 4 Stück brauchst Du. Es sind 
über 700 Stück auf Lager.

Ich habe den Verdacht, dass Dein Programmiergerät nicht richtig 
programmiert. Mit den Flashes sollte es weitaus weniger Probleme haben, 
weil die ganz einfach mit 5V beschrieben werden, ohne Erhöhung der 
Betriebsspannung auf 6V und zusätzlicher Programmierspannung.

fchk

von Barney G. (fuzzel)


Lesenswert?

Frank K. schrieb:
> Welche Teilenummer hat das Board, wo die EPROMs drin stecken?
> Müsste irgendwas in der Richtung 53131-xxxxx sein.
>
> Welche Bauform? PLCC oder DIL?
>
> fchk

Steht doch oben, ich dachte ich haette mich einigermassen ausgedrueckt.

Es geht um U8 die Nummer die da drauf steht ist doch furz egal, so lange 
die Firmware gleich ist.. Der andere Chip tut es ja.

Ro V. schrieb:
> Warum nimmst du die normalen dann nicht? IMHO Sind die OTP versionen nur
> die billig Versionen bei denen das teure Quarzfenster weggelassen wurde.

Verstehe ich nicht. Ich nehme doch die Originalen, extra drauf geachtet, 
keine China replikate zu bekommen. Datecode muesste ich nachsehen, aber 
irgendwas vor 2000.

AlsGasthier schrieb:
> Das was du beschreibst, habe ich so noch nicht erlebt, und egal ob
> EEprom, Rom oder OTP, das sollte auf jeden Fall laufen

Leider eben nicht. Ist auch das erste Mal das ich das erlebe.

Die Checksumme ist gleich. Die ausgelesenen Daten vor und nach dem 
Programmieren sind gleich. Kann man ja mit diff vergleichen.

AlsGasthier schrieb:
> daß die Pinbelegung womöglich nicht ganz
> identisch ist...

Muss ja, sind ja neue ORIGINALE Chips. Das ist ja mein Problem.

Eeprom schrieb:
> Billige Eproms scheinen in letzter Zeit gefälscht zu sein.

Ja, ich weiss, aber die die ich bekommen habe sind wirklich "Original"

AlsGasthier schrieb:
> Vielleicht hast du die Möglichkeit auf einen anderen Programmer
> zuzugreifen um das auszuschließen.

Leider nicht, denn der naechste Brauchbare kostet mal eben 300.-

Frank K. schrieb:
> So. Du kannst mal anstelle Deiner EPROMs Flashes ausprobieren.
> Und zwar Microchip/SST   SST39SF010A-70-4C-NHE.
> Teilenummer bei Farnell: 1368661
> Teilenummer bei RS: 823-4490
> 81 Cent pro Stück (netto) bei Farnell, und 4 Stück brauchst Du. Es sind
> über 700 Stück auf Lager.

Nicht kompatibel, siehe Datenblatt.

Frank K. schrieb:
> weil die ganz einfach mit 5V beschrieben werden, ohne Erhöhung der
> Betriebsspannung auf 6V und zusätzlicher Programmierspannung.

weil die ganz einfach mit 5V beschrieben werden, ohne Erhöhung der
Betriebsspannung auf 6V und zusätzlicher Programmierspannung.

Warum immer Tipps von jemandem der nicht mal in's Dateblatt geguckt hat?

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Barney Geroellheimer schrieb:
> Frank K. schrieb:
>> Welche Teilenummer hat das Board, wo die EPROMs drin stecken?
>> Müsste irgendwas in der Richtung 53131-xxxxx sein.
>>
>> Welche Bauform? PLCC oder DIL?
>>
>> fchk
>
> Steht doch oben, ich dachte ich haette mich einigermassen ausgedrueckt.
>
> Es geht um U8 die Nummer die da drauf steht ist doch furz egal, so lange
> die Firmware gleich ist.. Der andere Chip tut es ja.

Ich habe Dein Gerät nicht hier. Und es gibt die Dinger mit verschiedenen 
Boards, und da ich selber nicht nachschauen kann, welches Du nun gerade 
hast, solltest Du mir das sagen, wenn Du willst, das ich Dir helfe.

fchk

von Barney G. (fuzzel)


Lesenswert?

Frank K. schrieb:
> Ich habe Dein Gerät nicht hier. Und es gibt die Dinger mit verschiedenen
> Boards, und da ich selber nicht nachschauen kann, welches Du nun gerade
> hast, solltest Du mir das sagen, wenn Du willst, das ich Dir helfe.

Teilenummer ist 53131-80022 (eben U8) Board Version ist wohl Schnuppe, 
da die Firmware eh die Selbe ist. Rev. 3427

Ser. Nr. passt auch nur dazu. Die 36xx laeuft nicht mehr.

Ich schraube es aber eben mal auf..

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Barney Geroellheimer schrieb:

> Frank K. schrieb:
>> So. Du kannst mal anstelle Deiner EPROMs Flashes ausprobieren.
>> Und zwar Microchip/SST   SST39SF010A-70-4C-NHE.
>> Teilenummer bei Farnell: 1368661
>> Teilenummer bei RS: 823-4490
>> 81 Cent pro Stück (netto) bei Farnell, und 4 Stück brauchst Du. Es sind
>> über 700 Stück auf Lager.
>
> Nicht kompatibel, siehe Datenblatt.
>
> Frank K. schrieb:
>> weil die ganz einfach mit 5V beschrieben werden, ohne Erhöhung der
>> Betriebsspannung auf 6V und zusätzlicher Programmierspannung.
>
> weil die ganz einfach mit 5V beschrieben werden, ohne Erhöhung der
> Betriebsspannung auf 6V und zusätzlicher Programmierspannung.
>
> Warum immer Tipps von jemandem der nicht mal in's Dateblatt geguckt hat?

Weil der vielleicht seit Ende der 70'er sich damit beschäftigt?
Dein Gerät verwendet die 4 EPROMs als ROMs, d.h. es liest die nur. Es 
hat nämlich die die Schaltungsteile verbaut, die zum Beschreiben von 
EPROMs erforderlich sind. Ich habe hier nämlich die Schaltpläne 
angeschaut. Und als ROMs arbeiten die SST Flashes genau so mit der 
gleichen Pinbelegung wie die originalen EPROMs. Und in der allerletzten 
Platinenversion hat HP nämlich auch Flash verbaut. Warum habe ich Dich 
nach der Teilenummer der Hauptplatine gefragt? Dämmert es jetzt?

Mein Verdacht ist, dass Dein Brenner nicht richtig brennt. Deswegen 
sollst Du auch Flashes reintun, weil die sich ihr Timing und ihre 
Programmierspannung intern selber erzeugen und damit der Brenner als 
Fehlerquelle weitgehend wegfällt.

Bei Deinem Gerät ist die Kalibrierung übrigens in einem extra EEPROM 
28C64 gespeichert. Da das ein reines 5V-EEPROM ist, kann das der 
Prozessor auch beschreiben.

Und jetzt tue Abbitte.

fchk

von Gerald B. (gerald_b)


Lesenswert?

Wenn die Dinger schon Device ID's, wie FLASH haben, wäre es denkbar, das 
die Dev. ID wärend des Betriebes überprüft wird. Und wenn die nicht 
stimmt, dann nutzt es dir nichts, wenn der Inhalt stimmt. Wäre zumindest 
eine Möglichkeit...

von Frank K. (fchk)


Lesenswert?

Gerald B. schrieb:
> Wenn die Dinger schon Device ID's, wie FLASH haben, wäre es denkbar, das
> die Dev. ID wärend des Betriebes überprüft wird. Und wenn die nicht
> stimmt, dann nutzt es dir nichts, wenn der Inhalt stimmt. Wäre zumindest
> eine Möglichkeit...

Nicht bei EPROMs. Die haben zwar möglicherweise eine Hersteller- und 
Devicekennung, aber an die kommt man nur im Programmiermodus ran. Und da 
Vpp im Gerät fest auf VCC liegt, entfällt diese Möglichkeit.

fchk

von Frank K. (fchk)


Lesenswert?

PS:

bitte ersetzen:

> hat nämlich die die Schaltungsteile verbaut, die zum Beschreiben von
              ^^^
             nicht

Ich denke schneller, als ich schreibe.

fchk

von Barney G. (fuzzel)


Lesenswert?

Gerald B. schrieb:
> Wenn die Dinger schon Device ID's, wie FLASH haben, wäre es denkbar, das
> die Dev. ID wärend des Betriebes überprüft wird. Und wenn die nicht
> stimmt, dann nutzt es dir nichts, wenn der Inhalt stimmt. Wäre zumindest
> eine Möglichkeit...

Dachte ich mir auch, aber die kann man ja aendern und widerspricht sich 
auch damit, das es mit dem U8 aus dem zweiten Geraet einwandfrei 
funktioniert.

@Frank K. (fchk)

Hier die Board Rev.

53131-60001
Rev. C
09M1

53131-60001-01-01-9633-01693

Frank K. schrieb:
> Ich denke schneller, als ich schreibe.

Ja nu, geht ja hier auch manchmal schneller als man schreiben kann.

: Bearbeitet durch User
von Guido C. (guidoanalog)


Lesenswert?

Hallo,

Barney Geroellheimer schrieb:
> Gibt es da vielleicht irgendwas was ich nicht bedenke bzw nicht weiss ?

ich kenne den von Dir verwendeten "Programmer" nicht. Ich vermute 
jedoch, dass Du beim Auslesen bzw. Beschreiben eines (E)Eproms den 
jeweiligen Typ einstellen musst. Vielleicht verstellt sich in diesem 
Fall auch die Einstellung für das Datenformat (Byte/Word/DWord). Es 
könnte aber auch sein, dass die Zuordnung der Bits zu den Datenleitungen 
bei einem (E)Epromtyp falsch eingestellt wird.

Mit freundlichen Grüßen
Guido

von Frank K. (fchk)


Lesenswert?

ok, der Plan hier ist für 53131-60004, also neuer. Aber bei den EPROMs 
sollte sich eigentlich nichts gegenüber der Vorgängerversion geändert 
haben.

Probiere es aus - die Flashes sind ja billig. Ich würde dann übrigens 
alle 4 tauschen.

fchk

von AlsGasthier (Gast)


Lesenswert?

Ich hatte auch angeraten, sich einmal die Hexfiles anzusehen. Daran 
müsste man erkennen können, wenn es der Programmer nicht richtig tut...
Hast das gemacht?

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

AlsGasthier schrieb:
> Ich hatte auch angeraten, sich einmal die Hexfiles anzusehen. Daran
> müsste man erkennen können, wenn es der Programmer nicht richtig tut...
> Hast das gemacht?

naja, das hat er eigentlich schon dadurch gemacht, indem er das alte 
(E)Eprom ausliest und die Daten in das neue (E)Eprom schreibt und 
anschließend vergleicht. Mit seinem Gerät wird er z.B. niemals 
feststellen können, ob beim zweiten Typ Bit 2 auf D3 und Bit 3 auf D2 
geschrieben wird. Beim Auslesen werden die Bits wieder zurückgedreht.

Mit freundlichen Grüßen
Guido

von Barney G. (fuzzel)


Lesenswert?

Guido C. schrieb:
> Mit seinem Gerät wird er z.B. niemals
> feststellen können, ob beim zweiten Typ Bit 2 auf D3 und Bit 3 auf D2
> geschrieben wird. Beim Auslesen werden die Bits wieder zurückgedreht.

Das klingt nach logisch "1". Aber wie genau kann ich das testen / 
ausprobieren ? Ich habe noch genug "schnellere" PLLCCss da, die man 
immer bekommt und kein Problem sind neue zu besorgen.

Frank K. schrieb:
> Probiere es aus - die Flashes sind ja billig. Ich würde dann übrigens
> alle 4 tauschen.

Sind schon bestellt.
Hast Du files ?

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

Barney Geroellheimer schrieb:
> Das klingt nach logisch "1". Aber wie genau kann ich das testen /
> ausprobieren ? Ich habe noch genug "schnellere" PLLCCss da, die man
> immer bekommt und kein Problem sind neue zu besorgen.

hast Du nicht die Möglichkeit über Pull-Up bzw. Pull-Down Widerstände 
eine feste Adresse an des (E)Eprom anzulegen und die Datenbits für diese 
Adresse mittels Multimeter zu bestimmen? Das ganze würde ich für acht 
ausgewählte Adressen bzw. Daten (1,2,4,8,16,32,...) machen. Ggf. 
empfiehlt es sich hier das Original mit der Kopie zu vergleichen.

Mit freundlichen Grüßen
Guido

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Ich denke, du mußt noch mal zurück auf Null.
Vermutlich ist etwas beim Auslesen des Original-ROM schiefgegangen.
Und es ist auch wurscht, ob du EPROM mit oder ohne Fenster nimmst.
Und 120ns sollten kein Problem sein. Bei 45ns kann es da schon Probleme 
geben.
Auch die genannte Daten-Bit-Dreherei macht beim direkten kopieren 
nichts.
Natürlich kann auch der Programmer defekt sein. Teste das mal an einem 
anderen Beispiel.
Da braucht nur eine Adresse nicht zu funktionieren.

von michael_ (Gast)


Lesenswert?

Da fällt mir noch was ein.
Du hast für den Programmer einen Adapter für PLCC?
Wenn ich mich richtig erinnere, braucht man für "kleine" und "große" 
EPROM verschiedene Adapter.
Einige PIN sind da unterschiedlich belegt.
Vielleicht hast du nur einen für "kleine" EPROM.

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

michael_ schrieb:
> Auch die genannte Daten-Bit-Dreherei macht beim direkten kopieren
> nichts.

das gilt nur, wenn beide (E)Eproms vom gleichen Typ sind und mit den 
gleichen Einstellungen im Programm des "Programmers" gebrannt werden.

Mit freundlichen Grüßen
Guido

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Quatsch!
Beim direkten Kopieren ist das egal!
Da wird eine 1:1 Kopie erstellt.

Guido C. schrieb:
> das gilt nur, wenn beide (E)Eproms vom gleichen Typ sind und mit den
> gleichen Einstellungen im Programm des "Programmers" gebrannt werden.

Das die EPROM in der Größe gleich sein müssen, ist doch 
selbstverständlich.
Aber die Einstellungen sind durchaus unterschiedlich.

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

michael_ schrieb:
> Quatsch!
> Beim direkten Kopieren ist das egal!
> Da wird eine 1:1 Kopie erstellt.

Du stellt am "Programmer" (E)EpromTypXXX ein und liest die Daten des 
alten (E)Eproms aus. Danach stellst im "Programmer" (E)EpromTypYYY ein 
und beschreibst das neue (E)Eprom. Wenn nun im Ansteuerprogramm des 
"Programmers" in der Typbeschreibung für eines der (E)Eproms die 
Zuordnung Bit zu Pin falsch hinterlegt ist hast Du Probleme. Ist das so 
schwer zu verstehen? Komm jetzt bitte nicht damit, dass Programme keine 
Fehler haben.

Wie dem auch sei, wie bereits von mir beschrieben ist es nicht 
sonderlich schwer zu testen, ob der o.g. Fehler vorhanden ist oder 
nicht.

michael_ schrieb:
> Das die EPROM in der Größe gleich sein müssen, ist doch
> selbstverständlich.

Darüber brauchen wir gar nicht zu diskutieren.

Mit freundlichen Grüßen
Guido

von michael_ (Gast)


Lesenswert?

Guido C. schrieb:
> Wenn nun im Ansteuerprogramm des
> "Programmers" in der Typbeschreibung für eines der (E)Eproms die
> Zuordnung Bit zu Pin falsch hinterlegt ist hast Du Probleme.

Das gibt es nicht!
Der einzige Baustein der mir bekannt ist, war der 2516 (?).
Oder der Programmer ist Schrott.

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

michael_ schrieb:
> Das gibt es nicht!
> Der einzige Baustein der mir bekannt ist, war der 2516 (?).
> Oder der Programmer ist Schrott.

hast Du Dir das vom TE verlinkte Video angeschaut?

Barney Geroellheimer schrieb:
> Das Programmiergeraet ist ein "MiniPro TL866"
> Youtube-Video "EEVblog #411 - MiniPro TL866 Universal Programmer Review"

Du kannst in der Software des "Programmers" das (E)Eprom ausgehend vom 
Hersteller auswählen. Nach der Auswahl des Herstellers kannst Du den 
(genauen) Typ auswählen. Und da der TE von kompatibel geschrieben hat...

Mit freundlichen Grüßen
Guido

von Soul E. (Gast)


Lesenswert?

Barney Geroellheimer schrieb:

> Ergo, habe ich ersatz "E"EPROMs bestellt. 150er (Original) waren schwer
> zu bekommen, leider nur 2 Stk.  Aber neu, eben weil es OTP sind.

Am27C010 sind EPROMs, keine EEPROMs. Die werden mit UV-Licht gelöscht. 
Die OTP-Variante hat ein Plastikgehäuse, da geht kein UV durch. Deshalb 
Einweg. Dafür sind sie billiger als die Keramik-Varianten mit 
Glasfenster.

In beiden Fällen ist der gleiche Chip drin.



Mit FF überschreiben funktioniert nicht. Man kann die Zellen nur nach 
Null hin brennen, nach FF geht es nur mit UV-Licht.

von michael_ (Gast)


Lesenswert?

Guido C. schrieb:
> hast Du Dir das vom TE verlinkte Video angeschaut?

Nein, will ich nicht!

Guido C. schrieb:
> Barney Geroellheimer schrieb:
>> Das Programmiergeraet ist ein "MiniPro TL866"
>> Youtube-Video "EEVblog #411 - MiniPro TL866 Universal Programmer Review"
>
> Du kannst in der Software des "Programmers" das (E)Eprom ausgehend vom
> Hersteller auswählen. Nach der Auswahl des Herstellers kannst Du den
> (genauen) Typ auswählen. Und da der TE von kompatibel geschrieben hat...

Hä, das macht jedes jeder moderne Programmer.

soul eye schrieb:
> Mit FF überschreiben funktioniert nicht. Man kann die Zellen nur nach
> Null hin brennen, nach FF geht es nur mit UV-Licht.

Zur Ergänzung, Eprom sind gelöscht mit FF, Flash sind gelöscht mit 00.

von Guido C. (guidoanalog)


Lesenswert?

Hallo,

michael_ schrieb:
> Hä, das macht jedes jeder moderne Programmer.

dann ist doch alles klar. Dass für einen (E)Epromtyp im Programm falsche 
Daten hinterlegt kannst Du Dir nicht vorstellen, oder?

Mit freundlichen Grüßen
Guido

von Frank K. (fchk)


Lesenswert?

Barney Geroellheimer schrieb:

> Frank K. schrieb:
>> Probiere es aus - die Flashes sind ja billig. Ich würde dann übrigens
>> alle 4 tauschen.
>
> Sind schon bestellt.
> Hast Du files ?

Leider nein.

fchk

von Georg (Gast)


Lesenswert?

Hallo,

um das ganze mal rein logisch anzugehen:

Wenn kompatible ROMs mit einer Hex- oder BIN-Datei programmiert werden 
und die Programmierung allen Prüfungen nach korrekt ist, das Gerät damit 
aber trotzdem nicht funktioniert, was bleibt dann übrig? Dass bereits 
die zum Programmieren verwendete Datei fehlerhaft ist. Jedenfalls würde 
Sherlock Holmes diesen Schluss ziehen.

Georg

von Christoph db1uq K. (christoph_kessler)


Lesenswert?

Bei ROMs könnte ich mir denken, dass irgendwelche Programmierpins eine 
andere Funktion haben, z.B. ein weiterer Chipselect-Eingang. Aber wenn 
das tatsächlich UV-Eprom-kompatible einmal-programmierbare Typen sind, 
weiß ich auch keine Erklärung.

Bei bitsavers.org und bama-edebris habe ich nichts gefunden, aber KO4BB 
hat zwei Eprom-Files allerdings für den 53132:
http://ko4bb.com/manuals/index.php?dir=HP_Agilent/HP_53131A_53132A_53181A_Universal_Counter

von Gerald B. (gerald_b)


Lesenswert?

Oder die original ROMs "kippeln" auch schon. Wenn es in der Schaltung 
gerade noch funktioniert, beim Kopieren aber schon ein  Bit falsch 
ausgelesen wird, dann hast du verloren. Es gibt doch noch die 
Möglichkeit, mit ein paar Zehntel Volt mehr oder weniger auszulesen, 
dann soll es funktionieren. Da gab es doch was...
Keine Ahnung, ob dein Programmiergerät das unterstützt.

von Barney G. (fuzzel)


Lesenswert?

Erst mal vielen Dank fuer die vielen Antworten. Das muss ich mir in Ruhe 
durchlesen.
Jetzt mache ich mich erst mal an das Programmiergeraet und check die 
Hardware, so weit es geht. Viele Chips habe ich damit schon 
programmiert, bisher ohne Probleme. Evtl. macht nur dieser eine Typ 
Probleme.

Die Files koennten natuerlich defekt sein, aber ich habe auch andere 
Firmwareversionen ausprobiert und auch die gingen nicht. Kann an der 
Board Revision liegen oder eben ein Hardwarefehler.

Sherlock Holmes mag ja ein schlaues Kerlchen sein, aber dagegen sprechen 
die Checksummen. Die werden mir ja beim Auslesen, beim Programmieren und 
auch wenn ich das File selber checke ausgegeben.
Das ich da einen Fehler habe, ist eher unwahrscheinlich.

Frank K. schrieb:
> Leider nein.

Was heisst "leider nein" ? Moechtest Du die haben ? Ich haette 
mindestens 3 verschiedene Versionen anzubieten, muesste ich nochmal 
nachsehen.

Wie wird die Firmware bei den HP/Agilent 53131A Countern eigentlich 
normalerweise geupdatet ? Per IEEE ?

Gerald B. schrieb:
> Es gibt doch noch die
> Möglichkeit, mit ein paar Zehntel Volt mehr oder weniger auszulesen,
> dann soll es funktionieren. Da gab es doch was...
> Keine Ahnung, ob dein Programmiergerät das unterstützt.

Nein, das Programmiergeraet liefert nicht einmal die passende Spannung 
fuer meinen PLCC. Der braucht zum programmieren eigentlich 12,75V +- 
0,25V Diese 12,75V kann ich nicht einstellen. Die naechste Stufe waere 
13,5V was zu viel ist und 12,5V welche noch innerhalb der Toleranz ist.
Mal sehen wie das funktioniert. Evtl. nehme ich externe Spannungen. Das 
gucke ich mir alles jetzt mal an.

: Bearbeitet durch User
von Frank K. (fchk)


Lesenswert?

Barney Geroellheimer schrieb:

> Frank K. schrieb:
>> Leider nein.
>
> Was heisst "leider nein" ? Moechtest Du die haben ? Ich haette
> mindestens 3 verschiedene Versionen anzubieten, muesste ich nochmal
> nachsehen.

Ich habe nicht einmal das passende Gerät dazu.

> Wie wird die Firmware bei den HP/Agilent 53131A Countern eigentlich
> normalerweise geupdatet ? Per IEEE ?

Bei den alten per EPROM-Wechsel. Erst die neueste Mainboardversion hat 
ein Flash (29F400) drauf, wie ich beim Blick auf die Schaltpläne 
feststelle.

Siehe
http://literature.cdn.keysight.com/litweb/pdf/5989-6307EN.pdf

fchk

von Bernd T. (bastelmensch)


Lesenswert?

michael_ schrieb:
> Zur Ergänzung, Eprom sind gelöscht mit FF, Flash sind gelöscht mit 00.

Also beim 29F040 bin ich sicher, der ist gelöscht mit FF.
Welcher Flash hat denn gelöscht 00?

von 🍅🍅 🍅. (tomate)


Lesenswert?

Organisier dir ein paar UV 27C010 oder 27010 EPROMs mit dem gleichen 
Timing und ein originales Image des ROMs.

 Meiner Erfahrung nach sind die alten UV-EPROMs die iodiotensichersten 
und langlebigsten ROMs, die man bekommt. Alle UV-EPROMs welche ich 
ausgelesen habe, waren bis jetzt immer in Ordung und ohne kippelige 
Bits. Bei den Plastikeproms hatte ich schon einige, welche kippelige 
Stellen im Speicher hatten, welche sich mit jedem Auslesevorgang 
verändert haben, im Gerät aber (noch?) gut funktioniert haben. Entweder 
hab ich da beim Willem-Programmer was falsch eingestellt, oder die Chips 
waren tatsächlich schon so alt, dass sie Ladungsverlust hatten.

Könnte aber eventuell auch am Timing liegen, ich hab vor einiger Zeit 
mal ein HP Multimeter mit 6800 CPU versucht zu reparieren und dabei 
einen zu schnellen EPROM verwendet, sodass der 6800 mit dem Timing 
durcheinandergekommen ist. Allerdings ist der Unterschied zwischen 120 
und 150ns schon klein,  bei mir waren es 250ns und ein schneller 
Ex-Bioschip mit 80ns. Hab das dazumals einfach nicht bedacht.

von Barney G. (fuzzel)


Angehängte Dateien:

Lesenswert?

Nette Idee, aber wie bekomme ich die DIL Version in den PLCC32 Sockel ? 
:o) Ja, ich weiss, da gibt es Adapter und das kann man sich zur Not auch 
selbst machen, aber direkt ueber den OTP EEPROMs, ich nenne sie jetzt 
so, das sie ja 2x beschreibbar sind, das Netzteil haengt. Also allein 
aus Platzmangel geht die DIL Version schlecht.
Ausserdem dauert es mir zu lange die Dinger zu loeschen. Ist aber 
Ansichtssache.

Also ich habe das jetzt hin bekommen. Der / mein Fehler war, das ich 
immer versucht habe das eine fehlende EEPROM (U8) zu kopieren. Gerade 
habe ich mich dazu entschlossen mal alle 4 neu zu programmieren. Die 
EEPROMs habe ich aus einer charge genommen.
So geht es nun, auch mit einer hoeheren Firmwareversion.

Ich habe noch immer nicht den blassesten Schimmer warum man alle 4 
EEPROMs neu machen muss und es dann geht und das einzelne (U8) selbst, 
nicht nachzumachen ist.
Das ganze EEPROM Spiel hat mich jetzt gute 60.- gekostet. Weil es die 
Dinger meist nur in den USA gibt und das kostet halt.

Gut, die Kiste funktioniert nun wieder.

Stutzig machen mich alerdings ein paar Dinge.

Beim ersten Start meckerte er EEPROM Fehler. Der war beim zweiten Start 
weg.
Danach kam direkt ein Fehler "Calibration". Das kann ich erst spaeter 
machen weil mein Rubidium gerade in Arbeit ist. Ist aber kein Akt.

Die Fehler machen nichts, sind jetzt auch verschwunden, aber woher weiss 
das OS, das die EEPROMs getauscht wurden ? Immerhin ist die Firmware ja 
die die vorher drin war und auch nicht beschreibbar !?
Da muss doch das OS die Chips irgendwie erkennen. Mir ist das jedenfalls 
ein Raetsel.

Da die Files also funktionieren, werde ich die hier hoch laden. Sowas 
braucht man immer mal.

Und dann noch einen riesen Dank an alle in diesem Thread. Ausnahmsweise 
ja mal ohne Trolls.
Vielen Dank an alle.

Und wenn jemand noch Fragen hat, beantworte ich natuerlich gern.

So, ich brat mir 'n Steak und kalibriere den Kram.

Nachtrag.

Besorgt euch dieses Programmiergeraet wenn ihr noch keins habt. Ich habe 
mit den wichtigsten Adaptern, die qualitativ recht gut sind, um die 60.- 
bezahlt.
Leider kann der keine 8051 aber sonst ein geniales Geraet, fuer die paar 
Euro.

Ach und Leute, ist es nicht furz egal ob ein EPROM mit 00 oder FF 
geleert wird ?! Leer ist leer.

: Bearbeitet durch User
von michael_ (Gast)


Lesenswert?

Barney Geroellheimer schrieb:
> Sherlock Holmes mag ja ein schlaues Kerlchen sein, aber dagegen sprechen
> die Checksummen. Die werden mir ja beim Auslesen, beim Programmieren und
> auch wenn ich das File selber checke ausgegeben.
> Das ich da einen Fehler habe, ist eher unwahrscheinlich.

Dann überlege mal. Du hast eine Checksumme von einem EPROM, wo der 
Programmer eine fehlerhafte Adresse hat.
Die Antwort kannst du dir selbst geben.
Also lese den EPROM noch mal mit einem anderen Programmer aus.

von Barney G. (fuzzel)


Lesenswert?

> Also lese den EPROM noch mal mit einem anderen Programmer aus.
Wozu ?

Siehe oben. Es lag weder am File, noch am Programmiergeraet. Zu 
ueberlegen gibt es da nichts. Es sei denn das ich alle 4 tauschen musste 
und es mit dem Einen nicht ging. Das gibt zu denken.

Aber ich kann Dir den Zaehler und das Programmiergeraet gerne zuschicken 
und Du "ueberlegst" dann mal fuer Dich selbst wo der Fehler liegt. MICH 
interessiert das nur noch wenig, da alles wieder so geht wie es soll.

: Bearbeitet durch User
von AlsGasthier (Gast)


Lesenswert?

Schade, daß es dich nicht interssiert, warum das mit nur einem Eprom 
nicht geklappt hat. Nun bleibt uns leider diese Erkenntnis verborgen.

Auf der anderen Seite hab ich schon sehr früh im Thread getippt, einmal 
die Hexfiles nach Doppelungen durchzuschauen. Denn wenn eine 
Adressleitung nicht richtig werkelt, dann sind Lese und Vergleichsfile 
zwar identisch, aber trotzdem falsch!
da hat der Michael nun mal recht.

von Barney G. (fuzzel)


Lesenswert?

AlsGasthier schrieb:
> Nun bleibt uns leider diese Erkenntnis verborgen.

Noe, Du kannst Dich ja schlau machen.

AlsGasthier schrieb:
> Auf der anderen Seite...

Die Files sind in Ordnung. Dafuer gibt es Checksummen.

Und da es nun geht, muss das File ja in Ordnung sein. Ergo liest und 
schreibt das Programmiergeraet einwandfrei. Somit sind auch die 
Checksummen in Ordnung und der Vorschlag das mit einem anderen 
Programmiergeraet nochmal auszulesen, unnoetig, bzw. Bloedsinn.

: Bearbeitet durch User
von Soul E. (Gast)


Lesenswert?

Barney Geroellheimer schrieb:

> (...) OTP EEPROMs, ich nenne sie jetzt
> so, das sie ja 2x beschreibbar sind,

OTP-EPROM, nicht EEPROM.

Wie kommst Du auf die Idee, dass sie zweimal beschreibbar wären? Im 
Neuzustand steht in jeder Zelle FF. Du kannst sie solange beschreiben, 
bis überall Nullen sind, aber Du kannst niemals aus einer Null wieder 
eine Eins machen. Das geht nur durch Löschen mit UV-Licht (was ein 
Keramik-Gehäuse voraussetzt.

von Gerald B. (gerald_b)


Lesenswert?

Hm, vielleicht haben die Dinger doch unterschiedliche Zugrifszeiten, so 
das da beim schnellen Auslesen Müll rauskommt. Wenn aus zweien parallel 
gelesen wird und nur einer gültige Daten liefert, wäre das möglich.
Das mit dem EEPROM Fehler könnte ich mir nur mit einer anderen FW 
Version erklären. Hatte ich mal bei Adaptec SCSI Controllern. Die hatten 
ein BIOS im Flash und die Einstellungen, die man im BIOS vorgenommen 
hat, in einem seriellen EEPROM. Flashte man ein neues BIOS, meckerte er 
da auch einen Prüfsummenfehler im EEPROM und bot an, die Default Werte 
zu schreiben. Wenn man das bestätigte, las er aus dem BIOS die Default 
Werte, überschrieb das EEPROM und alles war gut.
Es gab aber zum Schluss eine FW Version, die nach 2-3 Wochen wieder 
zurückgezogen wurde, weil sich die damit geflashten Controller 
"festfuhren". Ich konnte das mit einem nachräglich von mir gesockelten 
Flash verifizieren. Setzte man vor dem FW Update das EEPROM auf Default, 
war alles gut und er akzeptierte die neue FW. Tat man das nicht, fiel er 
ins "Wachkoma". Ich kann mir das nur so zusammenreimen: Die 
Prüfsummenberechnung der alten und neuen FW ist identisch - die 
Zuordnung der Werte im EEPROM aber nicht! Folglich geben ohne Default in 
der neuen FW die abgespeicherten Werte keinen Sinn - werden durch den 
Prüfsummenalorithmus aber nicht als falsch erkennt. Nachdem ich mir das 
so zusammengereimt hatte, fand ich einen für mich einfacheren 
Workaround: Ich kümmerte mich nicht um das Flash per Down- und Upgrade, 
sondern föhnte den 8 Pin EEPROM raus, löschte den und setzte ihn wieder 
ein. So griff dann der Selbstheilungsmechanismus über die Prüfsumme ;-)

von Georg (Gast)


Lesenswert?

soul eye schrieb:
> Wie kommst Du auf die Idee, dass sie zweimal beschreibbar wären?

Dann wären es ja TTP-EProms...

Irgendwie habe ich das Gefühl, dass sich Barney und mit ihm der ganze 
Thread im Nichts verlaufen haben. Jetzt erzählt er auf einmal, dass doch 
alles geht und daher alle hier geäusserten Vermutungen Blödsinn sind. 
Herzlichen Dank für die Unterhaltung.

Georg

von Michael W. (Gast)


Lesenswert?

Da das flashen einer neuen BIOS (oder Firmware oder was auch immer) im 
Normalfall Änderunugen an der Software sind, ergeben sich zwangsläufig 
auch neue (=andere) Prüfsummen. Deshalb 'meckern' viele Geräte auch beim 
ersten Hochfahren nach einem Update.
Die Default (Standard)-Werte sollte man immer vor einem Update laden - 
dann gibt's die wenigsten Probleme.

von Gerald B. (gerald_b)


Lesenswert?

Michael W. schrieb:
> Da das flashen einer neuen BIOS (oder Firmware oder was auch immer) im
> Normalfall Änderunugen an der Software sind, ergeben sich zwangsläufig
> auch neue (=andere) Prüfsummen. Deshalb 'meckern' viele Geräte auch beim
> ersten Hochfahren nach einem Update.
> Die Default (Standard)-Werte sollte man immer vor einem Update laden -
> dann gibt's die wenigsten Probleme.

Ja, das wissen wir beide.
Aber sowas gehört mindestens als Hinweis in die HowTo oder ReadMe! Der 
Hersteller muß davon ausgehen, das es auch DAUs hinkriegen müssen. (aber 
wer liest schon die ReadMe - zumindest vorher?)
Und in Fällen, wie Diesem, wo auf Grund eines HW Defektes keine normale 
Inberiebnahme mit einem Setzen auf Default möglich ist, hat man dann 
sowieso den "Max" gemacht.

von Michael W. (Gast)


Lesenswert?

Gerald B. schrieb:
> Aber sowas gehört mindestens als Hinweis in die HowTo oder ReadMe!

Jepp - da bin ich ganz bei Dir! Aber ich kann mich manchmal des Gefühls 
nicht so ganz erwehren, daß dieser Punkt von den Herstellern mehr oder 
weniger absichtlich 'keine Erwähnung' findet - ein Schelm, wer Böses 
dabei denkt... ;-)

von Gerald B. (gerald_b)


Lesenswert?

Michael W. schrieb:
> Gerald B. schrieb:
>> Aber sowas gehört mindestens als Hinweis in die HowTo oder ReadMe!
>
> Jepp - da bin ich ganz bei Dir! Aber ich kann mich manchmal des Gefühls
> nicht so ganz erwehren, daß dieser Punkt von den Herstellern mehr oder
> weniger absichtlich 'keine Erwähnung' findet - ein Schelm, wer Böses
> dabei denkt... ;-)

Ganz deiner Meinung. Entweder ist ein FW-Update/BIOS flashen etc. ein 
normaler Betriebszustand und wird durch die Garantie mit abgedeckt - 
oder er beseitigt einen Mangel und ist durch den Hersteller bzw. dessen 
Service kostenlos durchzuführen.
Aber das Ganze in ein "Vakuum" zu stellen und jegliches Risiko dafür dem 
Käufer aufzubürden ist schon etwas link.
Es geht in über 99% der Fälle gut, in bestimmten Konstellationen aber 
eben nicht!
Ich habe mal einen zerflashten SCSI Controller bekommen, der laut 
Aussage des Vorbesitzers sich beim BIOS Flash des Mainboards 
verabschiedete.
Ich habe dann den 29'er 5V Flash gegen einen 28'er mit 12V 
Programmierspannung ausgetauscht und zuvor das BIN File eingespielt, 
danach ging er wieder :-)

von uwe (Gast)


Lesenswert?

>Also ich habe das jetzt hin bekommen. Der / mein Fehler war, das ich
>immer versucht habe das eine fehlende EEPROM (U8) zu kopieren. Gerade
>habe ich mich dazu entschlossen mal alle 4 neu zu programmieren. Die
>EEPROMs habe ich aus einer charge genommen.
>So geht es nun, auch mit einer hoeheren Firmwareversion.
>
>Ich habe noch immer nicht den blassesten Schimmer warum man alle 4
>EEPROMs neu machen muss und es dann geht und das einzelne (U8) selbst,
>nicht nachzumachen ist.

Du kannst nicht ein einzelnes EPROM einer Firmwareversion austauschen 
gegen das einer anderen Firmwareversion! Wenn das nen 32Bit µC ist dann 
ist im 1. EPROM das erste Byte eines 32Bit Befehls gespeicher, im 2. 
EPROM das 2. Byte usw. Nun stell dir vor da wird eine Funktion um 10 
Bytes länger als in der anderen Firmwareversion...

von Barney G. (fuzzel)


Lesenswert?

Georg schrieb:
> Irgendwie habe ich das Gefühl, dass sich Barney und mit ihm der ganze
> Thread im Nichts verlaufen haben. Jetzt erzählt er auf einmal, dass doch
> alles geht und daher alle hier geäusserten Vermutungen Blödsinn sind.

Ich habe ja auch noch immer keine Loesung gefunden. Wenn ich alle 4 
programiere, geht es mit drei Firmwareversionen.
Eine einzelne Kopie, also das defekte EEPROM zu ersetzen geht aber 
nicht. Warum ?
Wenn ich aus den neuen 4 wieder das U8 zu den Alten stecke, geht es.
Wobei das auch egal ist, denn egal welches ich tausche, also z.B. U10. 
Auch das geht.
Komisch ist, wenn ich alle 4 neu gemacht habe, das Kalibrier - EEPROM 
meckert das die Kalibrierung nicht mehr stimmt.
Die neuen Chips muessen also irgendwie erkannt werden.

Bleibt aber jetzt auch nur noch Therorie. Denn ich moechte mir jetzt 
nicht noch die Sockel ruinieren. Die haben jetzt einiges mitgemacht. 
Geht ja nun.

uwe schrieb:
> Du kannst nicht ein einzelnes EPROM einer Firmwareversion austauschen
> gegen das einer anderen Firmwareversion!

Habe ich auch nicht.

soul eye schrieb:
> Wie kommst Du auf die Idee, dass sie zweimal beschreibbar wären?

EEPROM heisst doch uebersetzt Electrically Erasable. Die OTPs sind NUR 
auf diesem Weg loeschbar, also sind es doch wohl eindeutig EEPROMs. 
Oder? Die UV-Version ist natuerlich ein EPROM.

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

Barney Geroellheimer schrieb:
> Die OTPs sind NUR
> auf diesem Weg loeschbar, also sind es doch wohl eindeutig EEPROMs.

Da fehlt es doch schon an den primitivsten Grundlagen. OTP heisst One 
Time Programmable - was ist denn daran misszuverstehen? Wenn es OTP 
sind, können sie nicht gelöscht werden, können sie gelöscht werden, sind 
es keine OTPs. Logik kann ja so einfach sein, wenn man des Denkens fähig 
ist.

Georg

von Dietrich L. (dietrichl)


Lesenswert?

Georg schrieb:
> Wenn es OTP sind, können sie nicht gelöscht werden,

Es soll Leute geben, die es mal mit Röntgenstahlen versucht haben. Ob 
das gelungen ist, weiß ich aber nicht...

von Barney G. (fuzzel)


Angehängte Dateien:

Lesenswert?

Georg schrieb:
> Da fehlt es doch schon an den primitivsten Grundlagen.

Sieht so aus. Jedenfalls kann ICH die Daten mit FF ausfuellen. Damit ist 
das Teil zwar unbrauchbar aber es geht. Also elektronisch loeschbar. = 
EEPROM.

von Soul E. (Gast)


Lesenswert?

Barney Geroellheimer schrieb:

> EEPROM heisst doch uebersetzt Electrically Erasable. Die OTPs sind NUR
> auf diesem Weg loeschbar, also sind es doch wohl eindeutig EEPROMs.
> Oder? Die UV-Version ist natuerlich ein EPROM.

Die OTPs sind überhaupt nicht löschbar.

Im OTP mit Plastik-Gehäuse steckt ein 100%ig identischer Chip wie in der 
UV-löschbaren Keramikvariante mit Fenster. Durch das Plastik geht kein 
UV-Licht, daher ist löschen nicht möglich. OTPs sind halt um die Hälfte 
billiger als Keramikgehäuse mit Fenster, daher lohnt sich das für 
größere Stückzahlen, wo keine Neuprogrammierung erforderlich ist.


Wenn Du ein OTP-EPROM mit $FF überschreibst und dann wieder ausliest, 
steht exakt das gleiche drin wie vorher. Die Bits, die vorher Null 
waren, sind auch hinterher Null.

von Barney G. (fuzzel)


Lesenswert?

soul eye schrieb:
> Die OTPs sind überhaupt nicht löschbar.

Wofuer habe ich denn oben das Bild angehangen ?! Der ist doch eindeutig 
geloescht !

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?


von Gerald B. (gerald_b)


Lesenswert?

Unbestätigten Gerüchten zufolge gibt es dann auch noch WOM - write only 
memory - mit unbegrenzter Kapazität! ;-)

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Barney Geroellheimer schrieb:
> Wofuer habe ich denn oben das Bild angehangen ?! Der ist doch eindeutig
> geloescht !

Ein 27C010 ist ein EPROM. Kein EEPROM, und nicht per Software 
löschbar.

Dein Programm lügt, einerseits, indem es behauptet, ein 27C010 wäre ein 
EEPROM, und andererseits, indem es Dir vorgaukelt, irgendwas gelöscht zu 
haben.

Poste doch bitte mal ein Bild der Bausteine, mit denen Du da 
herumhantierst.

von Winfried J. (Firma: Nisch-Aufzüge) (winne) Benutzerseite


Lesenswert?

Du könntest genauso gut  Fenster-EPROM oder EEFPROM verwenden. EIN Gerät 
das EPROM oder OTP-PROM erwartet kann das nicht unterscheiden. Aber egal 
wie du die Dinger masakriert hast: ES ist nicht vorgesehen OTP-PROM zu 
löschen .... Allerdings kann es sein das EEPROM-Chargen welche die 
Kriterien als EEProm nicht einhalten als OTP EPROM gelabelt wurden. 
Obwohl das am Zwecke von OTP vorbeigehet.

Namaste

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Winfried J. schrieb:
> Allerdings kann es sein das EEPROM-Chargen welche die Kriterien als
> EEProm nicht einhalten als OTP EPROM gelabelt wurden.

Das ist äußerst unwahrscheinlich, haben doch die Programmieralgorithmen 
von EEPROMs und von EPROMs nur sehr, sehr wenig miteinander gemein.

von Georg (Gast)


Lesenswert?

Rufus Τ. Firefly schrieb:
> Dein Programm lügt, einerseits, indem es behauptet, ein 27C010 wäre ein
> EEPROM, und andererseits, indem es Dir vorgaukelt, irgendwas gelöscht zu
> haben.

Und ein AM27C010 hatte noch niemalsnienicht eine Programmierspannung von 
12,5V. Wenn man so arbeitet, können nur rauchende Trümmer übrigbleiben. 
Ist die ganze Schaltung im Chip erfolgreich vernichtet, ist es durchaus 
möglich, dass an allen Adressen FF ausgelesen wird...

Winfried J. schrieb:
> das EEPROM-Chargen welche die
> Kriterien als EEProm nicht einhalten als OTP EPROM gelabelt wurden

Viel zu kompliziert gedacht. Es ist einfach so dass Barney nicht die 
geringste Anhnung hat was er da macht.

Georg

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Georg schrieb:
> Und ein AM27C010 hatte noch niemalsnienicht eine Programmierspannung von
> 12,5V. Wenn man so arbeitet, können nur rauchende Trümmer übrigbleiben.

Damit wir wissen, wovon wir reden:

http://www.farnell.com/datasheets/305111.pdf

Das ist das Datenblatt des AM27C010.

Die Programmierspannung beträgt übrigens 12.75V ± 0.25V.

Das steht so im Datenblatt, Seite 5, Abschnitt "Device Programming".

In "rauchende Trümmer" geht da also nichts über.

von Barney G. (fuzzel)


Angehängte Dateien:

Lesenswert?

Georg schrieb:
> Und ein AM27C010 hatte noch niemalsnienicht eine Programmierspannung von
> 12,5V. Wenn man so arbeitet, können nur rauchende Trümmer übrigbleiben.

Seite 5 Device Programming

Georg schrieb:
> Es ist einfach so dass Barney nicht die geringste Anhnung hat was er da macht.

Aber Du ? Nicht mal das Datenblatt lesen, aber drauf los bruellen.

Rufus Τ. Firefly schrieb:
> Poste doch bitte mal ein Bild der Bausteine, mit denen Du da
> herumhantierst.

Poste doch bitte mal ein Bild der Bausteine, mit denen Du da
herumhantierst.

/Anhang

Damit kannst Du dieses Thread auch schliessen. Eine Loesung habe ich 
noch immer nicht und beim Thema sind wir schon lange nicht mehr.
Zudem funktioniert das Geraet ja nun.

von Soul E. (Gast)


Lesenswert?

Barney Geroellheimer schrieb:

>> Die OTPs sind überhaupt nicht löschbar.
>
> Wofuer habe ich denn oben das Bild angehangen ?! Der ist doch eindeutig
> geloescht !

Wo genau soll da irgendwas gelöscht sein? Du hast den Speicher Deines 
Programmiergerätes mit $FF gefüllt. Ob das EPROM dafür im Sockel steckt 
oder in der Schublade liegt ist völlig irrelevent.

Wenn Du nun versuchen solltest, diese $FF ins EPROM zu brennen, dann 
passiert exakt gar nichts. Ob das EPROM dafür im Sockel steckt oder in 
der Schublade liegt ist wieder irrelevent. Zumal Du ja eingestellt hast, 
das $FF beim Brennen übersprungen werden sollen (siehe Dein angehängter 
Screenshot).

von Georg (Gast)


Lesenswert?

Rufus Τ. Firefly schrieb:
> Die Programmierspannung beträgt übrigens 12.75V ± 0.25V.

Sorry, da habe ich nur gelesen "Single +5 V power supply". Eine ziemlich 
missverständliche Angabe.

Georg

von Rufus Τ. F. (rufus) Benutzerseite


Lesenswert?

Nun, das sind jedenfalls eindeutig OTP-EPROMS. Die können --wie der 
Name überraschenderweise auch besagt-- exakt einmal programmiert und 
nicht gelöscht werden.

> Eine Loesung habe ich noch immer nicht

In Anbetracht des Nebels, den Du geworfen hast, ist das jetzt nicht 
wirklich ein Wunder. Aber wenn Dein Gerät funktioniert, ist ja auch 
irgendwie gut.

von 🍅🍅 🍅. (tomate)


Lesenswert?

Mit 0xFF gefüllt ist das eine, das andere ist, den ROM nach dem 
programmieren nochmals zu lesen. Macht zumindest der Willem-Programmer 
standardmässig so. Wenn nachher nicht das gleiche gelesen wird, wie man 
reinschreiben wollte, kommt ein Error. Scheinbar machen das die neuen 
Chinadinger nicht mehr, komisch irgendwie

von Soul E. (Gast)


Lesenswert?

Wenn man einstellt, dass $FF nicht gebrannt werden sollen, dann werden 
die höchstwahrscheinlich hinterher auch nicht verifiziert. Und den 
Blankcheck vor dem Brennen hat er ja deaktiviert.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.