Hallo, aktuell habe ich einige Probleme, die Fuses auf einem ATmega168 und ATmega328 zu flashen. Leider habe ich mir jetzt schon ein paar verfused und ich kann mir überhaupt nicht erklären, was ich falsch mache. Die Fuses habe ich zunächst mit dem burn-o-mat berechnet, dann irgendwann auch mit dem Engbedded AVR Fuse calculator. Als ISP Controller habe ich zunächst einen avrispmkii clone genutzt, dann auch einen usbasp, bei beiden erscheint das gleiche Problem (verification error nach dem setzen der fuses (auslesen funktioniert zunächst problemlos), es wird immer der efuse falsch gesetzt)... Ich benutze Ubuntu 14.04. Im Anhang einfach mal meine komplette Konsolenausgabe. Benutze ich die avrdude Komandos falsch? Zwischendurch habe ich zum testen einfach mal immer -n mit angegeben, damit nicht noch ein AVR verfused wird. Dabei kam dann auch der verification Fehler, dann habe ich aber gedacht, dass das daran liegt, dass eben mit dem -n Operator nichts geflasht wird, hab den dann weggelassen und den nächsten AVR verfused. Vielleicht kann mir ja jemand helfen. Danke und Grüße Jan
Dir ist schon klar, dass du den Reset Pin mit deinen Einstellungen abgeschaltet hast? Und warum nimmst du die Warnung nicht ernst, dass avrdude mit der Firmware deines Programmers Probleme hat und den Takt nicht einstellen kann?
Ne, das war mir nicht klar und auch nicht beabsichtigt. Hab' die Fuses so mit dem burn-o-mat bestimmt, offensichtlich ist dabei etwas schief gelaufen. Ich habe aber auch seltsames Verhalten der Software beobachtet (teilweise keine Reaktion bei Druck auf „Apply“ Button), habe das aber zu dem Zeitpunkt nicht so ernst genommen (da die Software früher immer super funktioniert hat). Na ja, dann versuche ich mal, mir einen HV Programmer zu basteln... Danke auf jeden Fall!
Ich habe das Ganze jetzt noch einmal ausprobiert. Ich wollte jetzt einfach mal zum Test die Standard Fuses für den ATmega168 flashen (die ich mir vom engbedded fuse calculator geholt habe). Das wäre dann ja:
1 | sudo avrdude -c avrispmkii -P usb -p m168 -B 100 -U lfuse:w:0xe2:m -U hfuse:w:0xc7:m -U efuse:w:0xf9:m |
(siehe Anhang Zeile 13). Beim efuse bekomme ich dann aber erneut einen verification error:
1 | avrdude: verifying ... |
2 | avrdude: verification error, first mismatch at byte 0x0000 |
3 | 0x01 != 0xf9 |
4 | avrdude: verification error; content mismatch |
(siehe Anhang Zeile 64ff.) Da kann doch irgendwas nicht stimmen?! Was ist das Problem? Stimmt etwas mit dem ISP Programmer nicht?
Hi, Da efuse beim Mega168 nur die ersten drei Bits belegt hat, führt F9 eben nur zum gesetzten ersten Bit. Was versuchst Du mit F9 auf dem efuse zu bewirken? Gruß Andreas
Hi Andreas, das wusste ich nicht, ergibt aber Sinn. Ich habe mich jetzt mal einfach auf den Fuse calculator (http://www.engbedded.com/fusecalc/) verlassen. Wenn man da den ATmega168 auswählt und unten auf default geht, wird als avrdude arguments angezeigt
1 | -U lfuse:w:0x62:m -U hfuse:w:0xdf:m -U efuse:w:0xf9:m |
Und beim burn-o-mat genau das gleiche?! Irgendwas mache ich doch falsch, oder? :D
Hi, das einzige, was Du falsch machst, ist das zurückgelesene richtig zu interpretieren. Das Bit 3-7 nicht definiert sind, ist auch nicht definiert, was zurückgelesen wird. Also: Alles ist gut. ;-) Gruß Andreas
Es kann gut sein, dass ich da irgendwas falsch interpretiere, aber wie kann eine Falschinterpretation zu sowas führen? Entschuldige, ich verstehe gerade überhaupt nicht, was genau das Problem ist... Hier lese ich die Fuses eines neuen ATmegas168 zurück (Fuses OK (H:01, E:DF, L:62)). Danach flashe ich zum Testen die Fuses genau so zurück (sudo avrdude -c avrispmkii -P usb -p m168 -B 100 -U lfuse:w:0x62:m -U hfuse:w:0x01:m -U efuse:w:0xdf:m), Ergebnis ist ein verification Error und diese Fuses: (H:07, E:01, L:62)........ Was genau fehlinterpretiere ich da? :/
1 | jan@jan-ubuntu:~$ sudo avrdude -c avrispmkii -P usb -p m168 -B 100 |
2 | |
3 | avrdude: AVR device initialized and ready to accept instructions |
4 | |
5 | Reading | ################################################## | 100% 0.04s |
6 | |
7 | avrdude: Device signature = 0x1e9406 |
8 | |
9 | avrdude: safemode: Fuses OK (H:01, E:DF, L:62) |
10 | |
11 | avrdude done. Thank you. |
12 | |
13 | jan@jan-ubuntu:~$ sudo avrdude -c avrispmkii -P usb -p m168 -B 100 -U lfuse:w:0x62:m -U hfuse:w:0x01:m -U efuse:w:0xdf:m |
14 | [sudo] password for jan: |
15 | |
16 | avrdude: AVR device initialized and ready to accept instructions |
17 | |
18 | Reading | ################################################## | 100% 0.04s |
19 | |
20 | avrdude: Device signature = 0x1e9406 |
21 | avrdude: reading input file "0x62" |
22 | avrdude: writing lfuse (1 bytes): |
23 | |
24 | Writing | ################################################## | 100% 0.01s |
25 | |
26 | avrdude: 1 bytes of lfuse written |
27 | avrdude: verifying lfuse memory against 0x62: |
28 | avrdude: load data lfuse data from input file 0x62: |
29 | avrdude: input file 0x62 contains 1 bytes |
30 | avrdude: reading on-chip lfuse data: |
31 | |
32 | Reading | ################################################## | 100% 0.01s |
33 | |
34 | avrdude: verifying ... |
35 | avrdude: 1 bytes of lfuse verified |
36 | avrdude: reading input file "0x01" |
37 | avrdude: writing hfuse (1 bytes): |
38 | |
39 | Writing | ################################################## | 100% 0.06s |
40 | |
41 | avrdude: 1 bytes of hfuse written |
42 | avrdude: verifying hfuse memory against 0x01: |
43 | avrdude: load data hfuse data from input file 0x01: |
44 | avrdude: input file 0x01 contains 1 bytes |
45 | avrdude: reading on-chip hfuse data: |
46 | |
47 | Reading | ################################################## | 100% 0.01s |
48 | |
49 | avrdude: verifying ... |
50 | avrdude: 1 bytes of hfuse verified |
51 | avrdude: reading input file "0xdf" |
52 | avrdude: writing efuse (1 bytes): |
53 | |
54 | Writing | | 0% 0.00s ***failed; |
55 | Writing | ################################################## | 100% 0.12s |
56 | |
57 | avrdude: 1 bytes of efuse written |
58 | avrdude: verifying efuse memory against 0xdf: |
59 | avrdude: load data efuse data from input file 0xdf: |
60 | avrdude: input file 0xdf contains 1 bytes |
61 | avrdude: reading on-chip efuse data: |
62 | |
63 | Reading | ################################################## | 100% 0.01s |
64 | |
65 | avrdude: verifying ... |
66 | avrdude: verification error, first mismatch at byte 0x0000 |
67 | 0x07 != 0xdf |
68 | avrdude: verification error; content mismatch |
69 | |
70 | avrdude: safemode: efuse changed! Was df, and is now 7 |
71 | Would you like this fuse to be changed back? [y/n] y |
72 | ^Cjan@jan-ubuntu:~$ sudo avrdude -c avrispmkii -P usb -p m168 -B 100 |
73 | |
74 | avrdude: AVR device initialized and ready to accept instructions |
75 | |
76 | Reading | ################################################## | 100% 0.11s |
77 | |
78 | avrdude: Device signature = 0x1e9406 |
79 | |
80 | avrdude: safemode: Fuses OK (H:07, E:01, L:62) |
81 | |
82 | avrdude done. Thank you. |
Hi, Du schreibst efuse auf DF, das heißt 1101 1111. Da nur die ersten 3 Bits relevant sind, mußt Du also wieder auslesen: efuse = xxxx x111. D.h. jede beliebige Zahl, die so aussieht ist ein korrekt zurückgelesenes Ergebnis, in diesem Fall also 07. Die führenden Bits werden hier als 0 zurückgelesen. Das könnte aber auch anders sein, da wie schon erwähnt, die Bits 3-7 nicht definiert sind. Gruß Andreas
Sagt dir eigentlich "safemode" irgendwas, in Verbindung mit avrdude? Und wozu mag wohl die "-u" Kommandozeilenoption gut sein?
Hi, da erschließt sich mir jetzt der Zusammenhang nicht. Gruß Andreas
Hi Andreas, alles klar, danke, das verstehe ich soweit. Aber Deine Aussage bezieht sich ja nur auf die efuse. Nochmal kurz mein Vorgehen: 1) Ich habe ausgelesen: Fuses Werkszustand: (H:01, E:DF, L:62) 2) Ich habe zum Test geschrieben: sudo avrdude -c avrispmkii -P usb -p m168 -B 100 -U lfuse:w:0x62:m -U hfuse:w:0x01:m -U efuse:w:0xdf:m 3) Ergebnis: (H:07, E:01, L:62) (zumindest laut der avrdude Ausgabe), also verfused (Fuses lassen sich jetzt wieder nich auslesen), weil jetzt wieder PC6 als IO konfiguriert ist... Das sieht so aus, als ob hfuse und efuse vertauscht sind?! Aber warum? Grüße Jan
Hi, das ist ein vermutlich der gleiche Bug in Deiner avrdude Version (<6.1.2) wie hier: Beitrag "avrdude Anzeige der fuses" Lade Dir mal die aktuelle Version herunter. Gruß Andreas
Jan B. schrieb: > Ich habe mich jetzt mal einfach auf den Fuse calculator > (http://www.engbedded.com/fusecalc/) verlassen. Manchmal kann es sinnvoll sein, sich lieber aufs Datenblatt zu verlassen … So schwierig sind die paar Bits ja nun auch nicht zu verstehen, und die Erfahrung zeigt, dass sich diejenigen, die sich die Fuse-Werte selbst aus dem Datenblatt zusammentragen, in aller Regel viel weniger dabei vertun als die, die sich auf ein Tool dabei verlassen.
Andreas B. schrieb: > da erschließt sich mir jetzt der Zusammenhang nicht. Du mußt den Safemode abschalten, wenn du Fuses ändern willst.
Axel Schwenke schrieb: > Du mußt den Safemode abschalten, wenn du Fuses ändern willst. Nö. Der notiert sich intern, welche Änderungen vorsätzlich an den Fuses vorgenommen werden sollen. Nur, wenn beim Programmende die zurückgelesenen Fuses nicht mit seiner (aktualisierten) Idee übereinstimmen, warnt er. Ist eigentlich ein Fietscher, das aus Zeiten der altertümlichen und nicht immer sehr zuverlässigen Primitivprogrammiergeräte stammt; vor allem die an einer seriellen Schnittstelle vor sich hin klappernden Bit-Banger waren manchmal recht fragil und neigten dazu, mal ein Bit falsch auszugeben. Blöd halt, wenn es gerade eins war, welches bei Wirksamwerden dann die Taktquelle auf eine nicht vorhandene gedreht hat. Der ganze Safemode funktioniert sowieso nur deshalb, weil die Änderungen an den Fuses erst nach dem Verlassen des ISP-Modus wirksam werden. Daher kann man innerhalb einer Sitzung die neuen Fuse-Werte schon lesen, arbeitet aber noch mit den bisherigen Einstellungen.
Hallo, also, ich hatte tatsächlich noch avrdude 6.0.2 installiert. Nach dem Update funktioniert alles und ich konnte die Fuses problemlos schreiben. Die Bugbeschreibung sagt ja, dass nur bei der Ausgabe E und H vertauscht sind, aber anscheinend ist das auch beim Flashen so. Bei dem Datenblatt stimme ich Dir zu, ich habe mich allerdings bei den fuses jetzt darauf verlassen, dass die hier im Wiki verlinkten Seiten halbwegs seriös sind und wenn man sich über so ein Tool 3 Minuten Arbeit spart, nehme ich die mit ;) Danke auf jeden Fall und Grüße Jan
Jan B. schrieb: > Die Bugbeschreibung sagt ja, dass nur bei der Ausgabe E und H vertauscht > sind, aber anscheinend ist das auch beim Flashen so. > Nein, das ist wirklich nur die Anzeige in der letzten Zeile. Schau Dir mal Dein log genauer an: Erst schreibt er lfuse mit x062 und liest sie korrekt zurück. Dann schreibt er hlfuse mit x001 und liest sie auch korrekt zurück. Erst beim efuse kommen die nicht ausgeblendeten Bits zum tragen. Es wäre also alles ok gewesen. Gruß Andreas
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte 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.