Hallo, ich habe gerade ein Problem mit dem E-fuse eines Atmega1281 unter Verwendung von Avrdude. Bei dem Atmega1281 sind sowohl im E-fuse Byte als auch im Lock-fuse Byte Bits nicht verwendet. (laut Datenblatt) Jetzt wollte ich die Brown Out Detection auf 4,3V setzen. Das würde normalerweise 0xFC entsprechen. Nun habe ich schon etwas gesucht und rausgefunden das es wohl unter Avrdude "fehler" beim rücklesen der nicht genutzten Bits kommt und daher die Verifizierung der Fuses fehlschlägt. Für die Lock Bits war das auch kein Problem anstelle von 0xFC musste dort 0x3C gesetzt werden, sprich die beiden nicht genutzten Bits auf 0. Bei den Lock Bits funktioniert anschließend sowohl das Setzen als auch verifizieren ohne Probleme. Sprich mit Avrdude 0x3C gesetzt, anschließend mit dem "myAvr Prog Tool" für den MySmartUSB light die Fuses ausgelesen und als Ergebnis 0xFC erhalten. Bei dem E-Fuse wird es jetzt allerdings etwas komisch. Versucht man es analog zum Lock-Fuse so müsste aus 0xFC -> 0x04 werden (ungenutzte Bit 3..7 auf 0). (Das ist auch der Vorschlag des Fusecalc http://www.engbedded.com/fusecalc) Setzte ich jetzt mit Avrdude 0x04 als E-Fuse so bekomme ich einen Fehler bei der Verifizierung 0x04 gegen 0xF4. Hier funktioniert es also scheinbar nicht so leicht wie bei den Lockbits. Also dachte ich mir gebe ich Avrdude halt das was es verlangt. Setzte also 0xF4 nun gibt es seitens Avrdude keine Fehlermeldung mehr. Lese ich jetzt allerdings mit dem "myAvr Prog Tool" die Fuses aus, so erhalte ich auch 0xF4. Sprich es wurde wirklich 0xF4 gesetzt (und somit das ungenutzte Bit4 beschrieben) Jetzt die eigentliche Frage wieso kann Avrdude im Falle der E-Fuses wirklich in die ungenutzten Bits schreiben im Falle von den Lock-Bits aber nicht ? Und ist es als problematisch anzushen wenn jetzt das "ungenutzte" Bit4 gesetzt ist ?
Der sicherste Fuse calculator ist immer noch Papier und Bleistift und das genaue Studium der Datenblattseiten 335 und folgende, inbesondere die Definition Programmiert/Unprogrammiert und der Defaultwerte der unbenutzten Bits. H. P:
Ja das stimmt wohl aber in diesem Fall liegt das Problem offenbar an einer ganz anderen Stelle. Avrdude bringt es fertig Bit3 im EFuse zu verändern, obwohl es laut Datenblatt nicht genutzt wird. Daher war die Frage ob es schädlich ist eins der "gesperrten" Bits zu verändern oder nicht. Wie gesagt geht es nicht darum welche Fuses gesetzt werden sollen, sondern viel mehr darum das Avrdude scheinbar Probleme mit dem setzen hat und ich jetzt einen Workaround suche.
Hier vielleicht nochmal eine besseres Beispiel. Der Atmega1281 ist auf Originalzustand eingestellt sprich E-Fuse 0xFF. Nun versuche ich mit Avrdude 0x04 zu setzen. Es kommt die Meldung das die Verifizierung fehlgeschlagen ist 0x04 != 0xF4 Nun setze ich E-Fuse wieder zurück auf 0xFF. Anstelle von 0x04 versuche ich 0xFC und es kommt wieder der Fehler 0xFC != 0xF4
Okay ich habe den Fehler jetzt behoben. Den Original Config Eintrag:
1 | memory "efuse" |
2 | size = 1; |
3 | write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0", |
4 | "x x x x x x x x x x x x x i i i"; |
5 | |
6 | read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0", |
7 | "x x x x x x x x o o o o o o o o"; |
8 | min_write_delay = 9000; |
9 | max_write_delay = 9000; |
10 | ; |
habe ich jetzt durch diesen ersetzt:
1 | memory "efuse" |
2 | size = 1; |
3 | write = "1 0 1 0 1 1 0 0 1 0 1 0 0 1 0 0", |
4 | "x x x x x x x x i i i i i i i i"; |
5 | |
6 | read = "0 1 0 1 0 0 0 0 0 0 0 0 1 0 0 0", |
7 | "x x x x x x x x o o o o o o o o"; |
8 | min_write_delay = 9000; |
9 | max_write_delay = 9000; |
10 | ; |
Das war jetzt einfach mal spontan ausprobiert ich kann daher auch nicht genau sagen was die Änderung bewirkt. Ich vermute mal das nun sowohl alle Bits gelesen als auch geschrieben werden. Wenn ich per Avrdude nun 0xFC setze gibt es keine Fehler mehr und wenn ich das E-Fuse mit anderen Programmen auslese wird auch 0xFC als gesetzt angezeigt.
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.