Hi, wie es aussieht, kann es hin und wieder mal vorkommen, dass die Megas ihr Signature-Bytes und Calibration-Bytes vergessen. Weiß jemand, ob man die wieder herstellen kann? Grüße, Bernd
Wie hast du das festgestellt? Normalerweise kann man die nicht schreiben und somit auch nicht verändern.
"Laß mich raten, du liest die Bytes mit Ponyprog aus?" Sind wir hier bei Günther Jauch oder was?
Ich habe ein ähnliches Problem (ATMEGA8) und bisher keine Lösung: http://www.mikrocontroller.net/forum/read-1-145906.html#145906
@Sebastian: "Wie hast du das festgestellt? Normalerweise kann man die nicht schreiben und somit auch nicht verändern." @Thorsten: "Laß mich raten, du liest die Bytes mit Ponyprog aus?" Nein, ich habe mir einen eigenen Programmer gebaut. Ganz einfach: Der Programmer gelangt in den Programmiermodus, aber wenn die Signature Bytes und Calibration Bytes ausgelesen werden, erhalte ich nur 0xFF zurück. Teilt man dem Programmer dann von Hand mit, dass es ein ATmega64 ist, kann man ihn ganz normal programieren. Einen anderen ATmega64 erkennt der Programmer problemlos, hier sind auch die Calibration Bytes noch o.k. Offensichtlich sind die Bytes doch programmierbar, nur keiner (auser Atmel) weiß wie. Die Bytes sind verschwunden, als ich mal mit dem Programmiertiming herumgespielt habe. Vorher wurde der Chip auch probelmlos erkannt. Übrigens habe ich auch schon anderweitig von dem Probelm gehört. Fazit: Wenn man zum Beispiel einen Wackelkontakt auf der Programmierleitung hat und zum falschen Zeitpunkt die Verbindung abbricht, ist es um den Chip geschähen. Grüße, Bernd
wenn ich mir die befehle so anschaue, kann es sein das man mit 0110 0000 aaaa aaaa bbbb bbbb iiii iiii die signature bytes schreiben kann? ich glaube nicht, dass Atmel die signature bytes nur lesbar macht, dann müssten die haufen chips wegschmeißen (wenn z.B. Speicher defekt) wenn man die signature bytes schreiben kann, dann könnten die evtl. den zugriff auf beschädigte flash segmente durch laser verhintern und dann den chip eine nummer kleiner verkaufen ->mega48, mega88, mega168
>Sind wir hier bei Günther Jauch oder was?
Nö das nicht, einen solchen Effekt hatte ich aber schon mit diesem Tool
und auch mit anderen, die den LPT benutzen.
@marcel Irgendeinen (nicht dokumentierten) Befehl gibt es sicher. Motorola hatte es beim HC11 (glaube ich) ähnlich gemacht: Es gab verschiedene Ausführungen, teils mit, und teils ohne EEPROM. Das EEPROM hatten zwar alle Ausführungen, nur bei der einen hatte das EEPROM höchst warscheinlich Fehler, weshalb der uC als EEPROMlos verkauft wurde. Die OSCAL Werte müssen ja auch irgendwie in den Speicher kommen, daher kann man sicher irgendwie diese Sachen schreiben. Allerdings bin ich ganz zufrieden damit, dass es nirgends steht wie das geht, denn sonst gäbe es bei Ebay oder sonst wo bestimmt schon gefälschte uC, bei denen lediglich der Aufdruck und die ID verändert wurden, und man sich am Ende wundert, wieso der mega168 ab Byte 512 im SRAM Fehler hat...
Atmel hat mir auf Anfrage mitgeteilt, dass sehrwohl die ID Bytes als auch die CAL Bytes über SPI bzw. JTAG geschrieben werden können. Nur wie, das haben sie nicht gesagt. Es ist sehr ärgerlich, wenn die ID verloren ist, und das kann definitiv passieren, 100%ig. Für interne Zwecke wärte es sicher hilfreich, wenn man die Sequenz wüsste, so dass man solche Chips reparieren kann. Vor allem wenn die CAL Bytes defekt sind. Atmel garantiert nämlich keine saubere RC-OSC Funktionalität, wenn das CAL Byte zu stark vom optimalen Wert abweicht.
Und nochwas, die Programmer Selbstbauer unter euch könnten doch mal mit dem trial-on-error Verfahren versuchen die richtige Sequenz für ID Bytes und CAL bytes schreiben herauszufinden :-)
Das hatte ich sowiso schon vor. Ich werde dann mal ein paar 90S1200 misbrauchen...
So, hab jetzt einen "Special Mode" in mein Programmiergerät eingebaut, der mir erlaubt die 4 Datenbytes des Befehls frei per PC einzustellen. Werde dann man heute nacht laufen lassen, es gibt ja nur 2^24 Möglichkeiten (3 Befehlbytes + 1Datenbyte). Vielleicht auch nur 65536, da Byte 3 meistens die Adresse angibt. @ggg Unterstützt das jeder AVR, also auch der AT90S1200 ?
Hi Benedikt, ja, jeder. Schon ab S1200 war das Problem der Zerstörung vorhanden. Habe einige solche Leichen von Programmier Unfällen hier rumliegen. :-( Wie gesagt, die falschen IDs sind nur ärgerlich. Böse wirds mit den CAL Bytes. Ich wäre sehr an der Sequenz interessiert. Bin auch bereit eine Hand voll AVRs zu spendieren.
aber wie wollt ohr die CAL Bytes wiederherstellen, die Software mag zwar dann ein neues reinschreiben können, aber woher solls das alte kennen? Man müsst ja erstmal ein Programm in den AVR schreiben das z.B. mittels Timer einen definierten Takt nach draußen bringt und diesen dann mit einer bekannten Taktquelle z.B. Quarzoszillator vergleichen. Aus dem Unterschied müsste man dann das neue CAL Byte berechnen und dann brauch man das aber auch nich mehr in die CAL Bytes schreiben, da würds ja auch schon das EEPROM tun.
Hi, vollkommen richtig. Statistisch gesehen liegen die CAL Bytes be ca. Hex80 +/- Hex20. Das müsste genügen, so dass der RC-Oszillator ohne Probleme läuft, wenn man in einem solchen Fall die Hex80 programmiert. Ein irregulärer Wert von Hex0 oder HexFF führt auf jeden fall zu Problemen. Wenn man eine Baudrate braucht oder sehr genaue Timer, dann hilft alles nichts, man muss dann wirklich neu kalibrieren.
Hi, ich habe mal alle Befehlskombinationen von 1. Befehl 0000 0000 0000 0000 0000 0001 0101 0101 1111 1111 0000 0000 0000 0001 0101 0101 < konstant > 2. Befehl 0000 0000 0000 0000 0000 0001 0101 0101 1111 1111 0000 0000 0000 0001 0101 0101 Hat aber so nichts gebracht.
Fragt mich nicht wie, aber ich habe gerade die ID eines AT90S1200 von 0, 144, 1 auf 0, 16, 1 umgeschrieben !!! Ich werde mal versuchen ob ich das reproduzieren kann.
Jetzt hat der uC die ID 0, 1, 2, aber ich weiß immer noch nicht wie ich das geschafft habe. Anscheinend werden die Änderungen erst nach einem Reset wirksam. Jetzt lasse ich aller nochmals durchlaufen mit den Befehlen Byte1, Byte2, Byte3, zu schreibender Wert wobei Byte1 und Byte 2 jeweils von 0 bis 255 laufen. Nach jedem Befehl wird der ISP Mode verlassen, neu gestartet und die ID ausgelesen. Da es so leicht ist die IDs zu ändern, ist der Befehl anscheinend auch nach dem 4Byte Schema aufgebaut, so dass nur max. 2Byte als Befehlscode dienen. Weiß zufällig jemand wie ISP funktioniert ? Ist ISP hardwaremäßig integriert, oder ist ISP nur ein ROM mit einer Art Software Bootloader, die der AVR ausführt ?
Hi Benedikt, ISP ist eine Status Maschine, also Hardware, die direkt an die SPI Hardware angeflanscht ist.
Denkt bitte mal darüber nach, was so alles passieren kann, wenn dieses Wissen in die falschen Hände gelangt. ...
Hi HanneS, nicht viel. Diejenigen, die genug kriminelle Energie besitzen, um hier z.B. einen mega48 zu einem mega168 umzutaufen, die müssen auch die Beschriftung entfernen und möglichst original getreu erneuern. Da sollte es doch dann ein leichtes sein, diese Telegramme selbst herauszufinden. Andererseits geht es hier nicht um Pentiums für mehrere 100 euros sondern um AVrs für 1..6 euros.
@...HanneS... Klar, das Wissen in falschen Händen könnte fatal sein. Aber aus meiner sicht ist es dafür jetzt schon zu spät. Die richtigen SPI Befehle zu finden wäre nur der letzte Schritt und wohl mit genügend Zeit von jedem durchführbar. Ich selbst habe hier einen ATMEGA8, der einmal den kompletten Flashinhalt verdrehte- das Programm konnte ich neu einspielen, die Fuses bleiben falsch.
Also signatur 0,1,2 bedeuted daß die lockbits gesetzt wurden und das auslesen verboden ist. (aus der doku...) Bei mir ist das umschreiben der id auf 0xff,0xff,0xff nur im high voltage parallel mode aufgetreten. Über die SPI noch bisher NICHT ein einziges mal. Olaf
@Olaf Stimmt, beim durchlaufen der 65536 Möglichkeiten kam ich leider auch zu Write Lock Bits. Nach einem Chip Erase bin ich wieder bei 0, 16, 1
@Olaf: Bei mir ist es bei der 5V seriel Programmierung passiert (ATmega64). Alle 0xFF. @Benedikt: Ich kenne den AT90S1200 zwar nicht, aber wieviel Zeit gibst Du dem Controller, damit er den Befehl ausführen kann? Beim Mega64 steht 9ms für einen EEPROM Schreibzugriff.
Ich gebe dem uC etwa 100ms Zeit, das sollte reichen. Bis heute Abend sollte ich den Befehl gefunden haben, wenn er nur von den ersten beiden Bytes abhängig ist.
Mit der Befehlssequenz 80, 0, Adresse, Wert wird die ID geschrieben. Allerdings lassen sich die Bits nur programmieren, aber nicht mehr löschen (also 1->0 geht, 0->1 nicht) ! Mein AT90S1200 hat jetzt die ID 0,0,0 Jetzt werde ich mal versuchen, ob ich die ID wieder löschen kann (also die Werte wieder auf 255 setzen).
Auf 1 programmieren geht nicht? Erstaunlich, da doch alle Fuses Read/Write sind........
Mit dem Befehl 80,0 zumindest nicht. Da kann man wirklich nur von 1 auf 0 setzen. Die Fuses sind zwar Read/Write, aber ist die ID auch eine Fuse oder vielleicht doch nur ein PROM ? Ich lasse jetzt einen zweiten Durchlauf laufen, bei dem ich versuche den Wert 255 zu schreiben. Vielleicht geht es ja. Ich finde es schon ziemlich leichtsinnig von Atmel 80, 0 als Befehl zum Schreiben der ID zu verwenden. Ich würde für solch ein wichtiges "Register" eine aufwendigere Prozedur verwenden. (um z.B. bei meinem ISP programmer in den Special Mode zu kommen, müssen 3 Befehle in der richtigen Reihenfolge gesendet werden. Im normalen Programmiermodus wird kein Befehl unterstützt, den dern AVR unbrauchbar machen könnte.)
Also bei meinem ATmega wurden die Bytes auf 0xFF gesetzt, als ich folgendes gemacht habe. Ist alledings keine Programmierseqzenz, sondern. In der Flash Doku steht: 308 ATmega64(L) 2490IAVR11/04 1. Power-up sequence: Apply power between VCC and GND while RESET and SCK are set to 0. In some systems, the programmer cannot guarantee that SCK is held low during Power-up. In this case, RESET must be given a positive pulse of at least two ATmega64(L) CPU clock cycles duration after SCK has been set to 0. As an alternative to using the RESET signal, PEN can be held low during Poweron Reset while SCK is set to 0. In this case, only the PEN value at Power-on Reset is important. If the programmer cannot guarantee that SCK is held low during Power-up, the PEN method cannot be used. The device must be powered down in order to commence normal operation when using this method. 2. Wait for at least 20 ms and enable SPI Serial Programming by sending the Programming Enable serial instruction to pin MOSI. 3. The SPI Serial Programming instructions will not work if the communication is out of synchronization. When in sync. the second byte (0x53), will echo back when issuing the third byte of the Programming Enable instruction. Whether the echo is correct or not, all four bytes of the instruction must be transmitted. If the 0x53 did not echo back, give RESET a positive pulse and issue a new Programming Enable command. Ich habe versuchsweise Step 2 übersprungen (also keine 20ms Gewartet). Danach waren die Bits 0xFF.
Dass die IDs ROM sind, widerspricht meiner Erfahrung dass nach einem Totalverlust des Fashinhalts auch die Fuses geändert wurden. Nach dem Hinweis dass sich diese nur von 1-> 0 programmieren lassen habe ich mal nachgesehen: Fuses laut Datenblatt des ATMEGA8: 0x1E 0x93 0x07 00011111 10010011 00000111 Fuses die jetzt ausgelesen werden: 0x3f 0xbf 0xbf 00111111 10111111 10111111 demnach passierte bei mir genau das Gegenteil. Es wurden nur Bits von 0-> 1 gesetzt. Aber bei dem Feature hindert ATMEL ja niemand daran für jeden AVR Typ eine Andere Methode zu verwenden. Nach dem was du schreibst, hätte ich reelle Chancen dass sich mein AVR wieder als AVR ausgibt. Aber ich befürchte mein ATMEL hat eventuell noch weitere interne Schäden abbekommen, da die oben genannten Fuses nicht immer ausgelesen. Ich habs mehrfach probiert: 29x: 0x3f 0xbf 0xbf 4x: 0x3f 0xff 0xbf 2x: 0x3f 0xbf 0x3f Das oben sieht zwar im erstem Moment nach einem Problem mit meinem LPT Programmer aus, diesen habe ich aber bisher mit mehreren anderen AVRs ohne jegliche Probleme verwendet.
@Malte Verwendest du einen fertigen Programmer, oder hast du die Möglichkeit den Befehl 80,0,1,85 zu senden ? Dann würden wir sehen, ob sich die ID beim mega8 nur von 0->1 oder auch umgekehrt schreiben lässt.
Ich verwende einen fertigen Programmer für mein einfaches LPT Interface. Für die Programmersoftware SP12 ist aber der Quellcode frei verfügbar. Eventuell kann ich versuchen den anzupassen - ob ich damit aber Erfolg hätte ist eine andere Frage. Was für eine Software verwendest du denn?
Ich verwende meine eigene, da bin ich flexibel, kann jederzeit neue AVRs einbauen und muss nicht warten bis irgendein Programmer diese unterstützt. Außerdem sind auch solche Sachen wie das hier problemlos möglich...
@Benedikt: Da Du die Bits nur auf Null setzen kannst, sieht es für mich ehr nach Flash-Speicher aus. Beim AT90S1200 ist nur eine Befehl notwendig, um Flashspeicher zu schrieben (Write Program Memory). Bei den Megas sind dafür aber zwei Befehle erforderlich. 1. Load Program Memory Page 2. Write Program Memory Page Da ist es nicht unwarscheinlich, dass das auch für die Signature Bytes gilt. Habe Deine Befehle mal beim Mega64 getestet (sowohl als hex, als auch als Dezimalzahl). Leider ohne Erfolg.
Ja, der S1200 ist als Testobjekt ungeeignet. Er hat beim Programmieren ein paar Schweinereien die ihn von allen anderen AVRs unterscheiden. Dass die ID und CAL Bytes zuerst separat mit einem anderen Befehl gelöscht werden müssen, klingt plausibel.
Wenn die Befehle für AT90S und ATMEGAS andere sind und bernd keinen Erfolg hat, so lass ich erstmal meine Anpassungsversuche für den Programmer sein. PS: Neue Typen sind bei dem Programmer auch kein Problem, da die einfach in einer Config Datei definiert werden.
Welcher (billige) uC eignet sich besser für die Tests ? mega8 ? Von den 90Sxxx wohl keiner, einen halb abgeschossenen 90S8535 (hat ein paar kaputte ADC Eingänge) hätte ich noch.
Ich denke, 2313, 8515 oder auch mega8 sind besser geeignet.
OK, ich habe jetzt einen mega8 dran. Ich werde auch noch einen 2313 ausprobieren, denn davon habe ich noch einen mit 19Pins...
@Benedikt: Hast Du nach jedem Schreibversuch den Programmiermodus verlassen?
Ja, habe ich. z.B. nach einem Chip Erase hängt der SPI Modus nämlich immer, ohne Reset.
Habe meinen Testprogramm jetzt so umgeschrieben, dass nach jedem Versuch der Programmiermodus verlassen wird. Allerdings bisher ohne Erfolg. Habe bisher mit zwei Variablen von 0 - 255 getestet. 1. Versuch iiii iiii eeee eeee 0000 0001 1011 1111 2. Versuch iiii iiii 0000 0000 0000 0001 1011 1111 gefolgt von eeee eeee 0000 0000 0000 0001 1011 1111 Das kombinieren von zwei Kommandos war naheliegent, da es offensichlich Flash-Zellen sind. Zumindest beim AT90S1200.
Meine letzten Versuche siehst Du zwei Posts höher. Wüste im Moment nicht, was ich noch probieren sollte, mit 3 und 4 unbekannten Bytes steigt die Testzeit explosionsartig an. Alleine für 3 Bytes bräuchte ich für einen Durchlauf 200 Stunden (wobei ich allerdings nach jedem Befehl den Programmiermodus verlasse). Und ich glaube kaum, dass das was bringt. Vielleicht sollten verschiedene Leute verschiedene Bereiche Test. Dann geht es etwas scheller. Und wenn die Vermutung mit den Flashzellen stimmen sollte, besteht auch noch die Möglichkeit, dass man mehrere Befehle kombinieren muss. Wenn Du Vorschläge hast, was man noch testen kann, nur her damit. Grüße, Bernd
Ich schaffe etwa 4 Versuche pro Sekunde, da bei vielen Schaltungen am Reset Pin ein 100nF Kondensator hängt, und mein Programmiergerät daher 100ms nach jeder Änderung am Reset Pin wartet. Für 2 Bytes benötige ich also rund 4,5 Stunden. Wenn ich alle 4 Bytes ändere, dann würde ich 34 Jahre benötigen... Aber dass das 4. Byte auch geändert werden muss, halte ich für unwarscheinlich, denn irgendwie muss ja auch das zu programmierende Byte übertragen werden. Wie kommt ihr eigentlich darauf, dass es getrennte Befehle zum Laden und zum Programmieren eines Bytes gibt ? Beim normalen Programmspeicher ist es nur so, da dieser im Page Mode programmiert wird um Zeit zu sparen. Die Fuse und Lock Bits lassen sich ja auch direkt schreiben, ohne dass vorher etwas geladen werden muss.
Hi Bernd, nun, man könnte "successive aproximation", d.h. schrittweise Annäherung anwenden. Nicht nach jedem Schreiben gleich Testen, sondern z.B. 256 Kombinationen durchorgeln, dann Testen. Hat sich nichts getan, dann die nächsten 256. Ansonsten jetzt Einzeltests mit den 256 Werten. Das müsste die notwendige Zeit gewaltig reduzieren :-)
Naja, vielleicht hat Benedikt ja recht. Den Test mit 3 Bytes könnte man ja doch noch zeitlich schaffen. Wenn es auch ein paar Wochen dauer, da ich meinen Rechner nicht durchlaufen lassen, wenn ich nicht zu Hause bin. @Benedikt: Testest Du noch weiter? Dann kann einer von uns ja am oberen Ende und der andere am unteren Ende beginnen. Sollte es noch mehr Leute geben die die Mögichkeit haben, bitte mal melden. Auch sollte wir zu beginn noch einmal darüber nachdenken, wieviel Zeit wir dem µC geben. Nach Spezifikation muss man nach dem Eintritt in den Programmiermodus erst einal 20ms warten. Dann Komando senden, dann entweder 4,5 oder 9ms warten und Programmiermodus wieder verlassen.
Wie wäre es wenn ihr einen zweiten AVR mit einem Programm ähnlich dem jetzt verwendeten PC Programm bespielt? Sobald der Code gefunden wurde leuchtet dann eine LED o.ä. 1. Vorteil: 24/7 Betrieb ohne PC 2. Vorteil: Jeder mit zwei AVRs und einem Steckbrett kann mitmachen unabhängig vom Betriebssystem und Programmer. 3. Vorteil: Eventuell kann dank der kürzeren Leitungen der Kondensator weggelassen und so schneller Befehle gesendet werden. Ansonsten wäre ich noch für die Verbesserung von 'ggg'.
@Malte: Dann müsste sich nur jemand finden, der die Schaltung entwirft und das Programm schreibt. Würde ich bei meinem jetzigen Aufbau das 3. Byte immer in einem Rutsch von 0-255 beschreiben, würde sich die Zeit auf ca. 65h verringern. Ist warscheinlich das Adressbyte also unkritisch in verbindung mit dem Chip Erase. Habe einfach mal angefangen. ii ee ff 0xBF Zähle ii von 255 an herunter und durchlaufe für jedes ii alle Kombinationen von ee und ff. Wenn alles klappt müßte ja irgendwann bit 6 gelöscht werden (ist das einige Bit beim Mega 64, dass bei allen drei Signature Bytes 0 ist)
Hi, testet eigentlich im Moment außer mir noch jemand die verschiedenen Kombinationen durch?
Bisher nicht, habe jetzt etwa 30% der Möglichkeiten mit 3 Byte durch.
Hallo Bernd, das hätte ich nicht erwartet :-(( Aus meiner Erfahrung ist es definitiv möglich jedem AVR seine Signatur per Unfall/Zufall zu überschreiben. Offensichtlich bedarf es dann dazu einer bestimmten komplexeren Sequenz ..................... Schade.
Vielleicht habe ich ja auch was falsch gemacht, aber ich werde es erst einmal nicht weiter versuchen.
also ich denke, das ist eine random-logic (fest-verdrahtet), desshalb mal das 3. byte (low teil der adresse) bei 00 lassen und den rest durchprobieren. die 20mS nach enter programming mode sind eher obligatorisch. mein opfer-2343 kann ich auch schon nach ca. 10mS schreiben. (wenn die versorgungspannung stabil hoch ist wahrscheinlich noch schneller) zu der funktion verschiedener speicher: sRAM: 6 Transsistoren (deswegen ist der so teuer), von denen 2 über kreuz den wert halten dRAM: - 4 Transistoren + Kondensator, Kondi speichert den wert, die transistoren refreshen den wert ab und zu (UV)EPROM: "hochgebauter" transistor mit spezieller schicht, die dotierung kann durch uv licht geändert werden. (unprogrammierter wert meistens 1) EEPROM: wie (UV)EPROM nur dass durch eine hohe spannung (über einen transistor geschaltet) die funktion des uv-lichtes übernimmt FLASH: wie EEPROM, nur das eine umgekehrte spannung verwendet wird und so der "transistor" zum löschen gespart wird
"die 20mS nach enter programming mode sind eher obligatorisch. mein opfer-2343 kann ich auch schon nach ca. 10mS schreiben. (wenn die versorgungspannung stabil hoch ist wahrscheinlich noch schneller)" Genau so habe ich bei meinem ATmega die Signature Zerstört. "zu der funktion verschiedener speicher:" ?Was willst Du uns damit sagen?
Ich bin gerade im Errata vom ATMEAG8 (doc2486) drüber gestolpert: Seite 296: Signature may be Erased in Serial Programming Mode.
Das Programmierprotokoll hat ja keinerlei Prüfbits oder ähnliche Fehlererkennung. Da kann es durchaus vorkommen, daß Bits falsch oder verschoben sind. Gerade beim direkten Anschluß an den PC kann es leicht Timingprobleme geben, da dessen Schnittstellen nicht für akkurates Timing ausgelegt sind. Ich benutze das STK500, welches einen extra MC hat, der garantiert alle Timings richtig einhält. Und damit ist noch kein einziger MC falsch programmiert worden. Wem das STK500 zu teuer ist, der kann ja den AN910 Programmer aufbauen und hat dann auch ein akkurates Timing. Der Vorteil der AN910/STK500 Programmer ist auch, daß sie über USB-RS23-Adapter funktionieren. Peter
vielleicht funktionierts nur in einem Pagewrite-Modus, also so das es garnicht möglich ist da einzelen Byte zu ändern sondern immer mehrere Schreiben muss. Vielleicht sollte man den Atmel Support mit konkreten Fragen ansprechen wie man z.B. das ID Byte für eine Versionskennugn benutzen kann. Könnte mir schon vorstellen das es wie oben beschrieben wird dazu genutzt wird um Typen mit Fehlern in bestimmten Datenbereichen zu kleineren Typen zu ändern. Ansonsten könnte man das ganze ja Rückgängig machen und auch den Speicherbereich nutzen der evtl. defekt ist.
@Thomas: "genutzt wird um Typen mit Fehlern in bestimmten Datenbereichen zu kleineren Typen zu ändern" Das hieße aber, dass man, wenn die Kennung fehlt, entweder zusätzlichen Flash speicher ansprechen könnte, bzw. RAM oder EEPROM. Ich habe es zwar nicht weiter getestet, aber mein Chip funktionniert auch ohne Signature weiterhin ganz normal, abgesehen davon, dass man dem Programmer beim Programmieren sagen muss, dass da jetzt ein ATmega64 dranhängt. Grüße, Bernd
vielleicht wird dann weiteres Zeug per Laser "deaktiviert" interne Adressleitungen, ADC..... aber bei einer Fehlerrate von wenigen ppm sollte das sich doch garnicht rechnen oder ist diese Rate auf die Ic bezogen die letzendlich ausgeleifert werden?
Eher Letzteres: Es ist ein alter Hut in der Chipherstellung erst zu produzieren und hinterher Aschenputtel zu spielen. Ich glaube kaum das sich daran schnell etwas ändern wird. Ist doch das Maskenendotieren immer noch ein Spiel mit den Wahrscheinlichkeiten. Mit mehr oder weniger Genauigkeit werden Fremdatome ins Gitter geschossen. Je kleiner die Strukturen desto gravierender kleinste Abweichungen. Je komplexer das anvisierte Produkt desto höher die Wahrscheilichkeit partieller Fehler. Solche Chips durch Sieben und Klassifizieren trotzdem verwenbar zu machen ist sowohl unter ökonomischem als auch ökologischem Aspekt sinnvol. Und so wird es gemacht.
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.