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.
Gast
#3895203
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.")
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
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.
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
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.
Gast
#3895236
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.
Gast
#3895246
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.
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
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?
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
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..
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
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...
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
PS:
bitte ersetzen:
> hat nämlich die die Schaltungsteile verbaut, die zum Beschreiben von
^^^
nicht
Ich denke schneller, als ich schreibe.
fchk
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.
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
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
Gast
#3895309
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?
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
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 ?
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
Gast
#3895347
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.
Gast
#3895352
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.
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
Gast
#3895417
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.
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
Gast
#3895431
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.
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
Gast
#3895445
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.
Gast
#3895448
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.
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
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
Gast
#3896101
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
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
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.
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.
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
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?
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.
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.
Angehängte Dateien:
-
AM_succ.jpg
(180 KB)
-
IMG_0156.jpg
(68 KB)
-
PLCC_DIL.jpg
(28 KB)
Gast
#3896514
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.
> 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.
Gast
#3896543
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.
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.
Gast
#3896795
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.
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 ;-)
Gast
#3896948
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
Gast
#3896949
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.
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.
Gast
#3897135
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... ;-)
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 :-)
Gast
#3897248
>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...
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.
Gast
#3897378
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
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...
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.
Angehängte Dateien:
-
ded.jpg
(170 KB)
Gast
#3897461
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.
soul eye schrieb: > Die OTPs sind überhaupt nicht löschbar. Wofuer habe ich denn oben das Bild angehangen ?! Der ist doch eindeutig geloescht !
Unbestätigten Gerüchten zufolge gibt es dann auch noch WOM - write only memory - mit unbegrenzter Kapazität! ;-)
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.
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
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.
Gast
#3897590
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
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.
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.
Angehängte Dateien:
-
AMD.jpg
(440 KB)
Gast
#3897616
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).
Gast
#3897620
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
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.
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
Gast
#3897632
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.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.