Hallo, ich habe hier ein sehr seltsames Problem, für das es bestimmt eine logische Erklärung gibt, die ich aber momentan beim besten Willen nicht finden kann. Daher wende ich mich in diesem Forum mal an die erfahrenen Denksportkünstler (G. König?). Ich benötige für ein Projekt ein paralleles EEPROM und da ich momentan gerade keine 500 Euro für einen handelsüblichen Programmierer übrig hatte, habe ich folgende, recht einfache und interessante Geschichte im Internet gefunden: http://www.chrisward.uklinux.net/6502/programmer.shtml Schaltplan: http://www.chrisward.uklinux.net/6502/schematics/eeprom-prog.gif Also habe ich mir die Bauteile besorgt und die Schaltung aufgebaut, alles kein Problem. Für den ersten Testlauf habe ich einfach mit einem Binäreditor einen kleinen Text in die zu programmierende Datei hineingeschrieben und habe beim Programmieren prompt einen Verify-Error erhalten. Beim Vergleich der Daten, die ich dann nochmal herausgelesen hatte, stellte ich einen systematischen Fehler fest, d.h. jeder Buchstabe ist systematisch durch ein anderes Zeichen ersetzt worden. Naja, da wird wohl in der Schaltung etwas im Datenbus vertauscht sein dachte ich und habe die Schaltung nochmals Verbindung für Verbindung geprüft, Fehlanzeige! Die Schaltung ist 100% ok. Naja, vielleicht ein Timing-Problem, nochmals alles getestet. Auch Fehlanzeige! Es treten immer Bitfehler auf und zwar immer verschiedene in unterschiedlicher Anzahl. Aber bei jedem Zeichen immer der selbe Fehler, z.B. jedes Blank wird zum Ausrufezeichen, unabhängig von seiner Adresse. Wenn ich die selbe Ausgangsdatei nochmals brenne und dann nochmals herauslese, sind die beiden gelesenen Dateien identisch! Es treten auch immer die selben Fehler an den selben Bitpositionen auf, jedoch bei jedem Zeichen andere Fehler mit Bitfehlern in unterschiedlicher Anzahl an den verschiedensten Positionen, jedoch bevorzugt im niederwertigen Bereich, hauptsächlich in den unteren 4 Bits. Die Bereiche, die im leeren Zustand 0xff enthalten, werden jedoch nicht verändert. Ich kann bei diesen Bitfehlern kein System erkennen. Tja, jetzt steh ich da und bin total ratlos. Wenn jemand von Euch eine Idee hat (ausgenommen, dass der Verfasser dieser Schaltung plus Software ein Scherzkeks ist), der soll mir doch bitte einen Hinweis geben! Danke! Gruss, Peter
Ach ja, ich habe nicht im Page-Mode programmiert und habe ein 28C17 von Atmel verwendet. Die Jumper waren alle korrekt gesetzt.
Glückauf Peter, hast du mal die Datenblätter vom Microchip Typen mit dem Vom ATMEL verglichen? Es gibt manchmal reichlich Unterschiede bei der Behandlung nicht belegter Pins und vor allem im Timing. Gruß, Günter
So, Problem gelöst, zumindest teilweise. Also an einem anderen PC läuft die Geschichte einwandfrei. Interessanterweise wurde das EEPROM an dem ersten PC auch richtig programmiert, nur das Herauslesen klappte dort wohl nicht richtig. Allerdings handelt es sich bei diesem (ersten) PC noch um einen alten Laptop mit Win95. Obwohl, so eine Programmiersoftware benötigt ja kaum Prozessorleistung. Seltsam ist das schon. @Günter Danke für den Hinweis, wenn es nochmal in der Richtung hakt, werde ich Deinen Rat mal beherzigen und eventuell ein anderes Fabrikat probieren. Obwohl eigentlich gerade aus diesem Grund doch dieser Ready/Busy-Anschluss als Verbesserung zu dem 28C16 entstanden ist (denk ich zumindest mal). Da weiss nämlich der Programmierer genau, wenn das EEPROM ein Datenbyte gefressen hat und er zur nächsten Adresse weiterschalten kann, ist doch so, oder? Jedenfalls vielen Dank für den Hinweis! Gruss, Peter
Hi Peter, es gab mal ein EEprom namens 95C06. Dieses Teil wurde von etlichen Herstellern gefertigt und feilgeboten. Und wenn man immer schön brav den FAIRCHILD Typen benutzt hat, war alles gut. Aber eines schönen Tages kamen die Erbsenzähler ins Land und sagten, du musst jetzt den 93C06 von dem anderen Hersteller nehmen, der ist viel schöner und zogen wieder ins Land. Die armen Techniker taten wie befohlen und bekamen fast graue Haare denn das Teil sah zwar schöner aus auf dem Papier. Im inneren war es aber ein garstiges Teil und wollte seinen Dienst nicht antreten........ Was will uns diese Geschichte sagen? Das neue EEprom hatte ein anderes Handling mit den NC Pins. Die mussten an tlws. an VCC / Masse gelegt werden. Das Programmieren ging zwar, aber das Lesen klappte nicht. In diesem Sinne Günter
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.