ATmega64 vergist seine Signature-Bytes

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?

"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.

@Benedikt:
Wie bist Du vorgegangen?

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)
2490I–AVR–11/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.

@Bernd, @Benedikt,

gibts was neues mit den ID Bytes?

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?

Hi Tester,

gibt es irgendwelche Neuigkeiten???

Bisher nicht, habe jetzt etwa 30% der Möglichkeiten mit 3 Byte durch.

Hi,

bin jetzt durch, aber ohne Erfolg.

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?

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.