ATmega168, AVRDude, efuse fehler

[gast (Gast)]

Hallo,

ich hab ein kleines Problem beim flashen eines ATmega168 mit AVRDude.

Der von mir verwendete Programmieradapter funktioniert sonst mit 
ATmega16 einwandfrei, nur beim ATmega168 macht er beim efuse 
Schwierigkeiten.

Ich hoffe Ihr könnt mir helfen.

Vielen Dank für euere Bemühungen.

WindowsXP auf der Komandozeile:

C:\avrdude -c stk200 -P lpt1 -p m168 -e -U lfuse
:w:0xE2:m -U hfuse:w:0xDC:m -U efuse:w:0xF8:m -E reset

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.00s

avrdude: Device signature = 0x1e9406
avrdude: erasing chip
avrdude: reading input file "0xE2"
avrdude: writing lfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of lfuse written
avrdude: verifying lfuse memory against 0xE2:
avrdude: load data lfuse data from input file 0xE2:
avrdude: input file 0xE2 contains 1 bytes
avrdude: reading on-chip lfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of lfuse verified
avrdude: reading input file "0xDC"
avrdude: writing hfuse (1 bytes):

Writing | ################################################## | 100% 0.00s

avrdude: 1 bytes of hfuse written
avrdude: verifying hfuse memory against 0xDC:
avrdude: load data hfuse data from input file 0xDC:
avrdude: input file 0xDC contains 1 bytes
avrdude: reading on-chip hfuse data:

Reading | ################################################## | 100% 0.01s

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified
avrdude: reading input file "0xF8"
avrdude: writing efuse (1 bytes):

Writing |                                                    | 0% 0.00s ***faile
d;
Writing | ################################################## | 100% 0.06s

avrdude: 1 bytes of efuse written
avrdude: verifying efuse memory against 0xF8:
avrdude: load data efuse data from input file 0xF8:
avrdude: input file 0xF8 contains 1 bytes
avrdude: reading on-chip efuse data:

Reading | ################################################## | 100% 0.00s

avrdude: verifying ...
avrdude: verification error, first mismatch at byte 0x0000
         0xf8 != 0x00
avrdude: verification error; content mismatch

avrdude: safemode: efuse changed! Was f8, and is now 0
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK

avrdude done.  Thank you.

C:\

[Stefan B. (stefan)]

Möglicherweise ein zu altes AVRDUDE (avrdude.conf). Du kannst die 
AVRDUDE Version herausfinden, wenn du -v oder -vv oder -vvv in der 
Kommandozeile angibst.

http://www.mail-archive.com/[e-mail]/msg01597.html
http://www.mail-archive.com/[e-mail]/msg01561.html

[gast (Gast)]

Auf den ersten blick sieht es so aus als ob meine version neuer als in 
dem link genannte zu sein. Aber das genaue Build wird mit -v nicht 
ausgegeben.

Ist das bei WinAVR-20081205 mitgelieferte AvrDude.

avrdude: Version 5.6cvs, compiled on Nov 10 2008 at 17:15:38
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/

[Stefan B. (stefan)]

Die Lösung steht hier
http://tinker.it/now/2007/02/24/the-tale-of-avrdude-atmega168-and-extended-bits-fuses/

Und wenn ich etwas genauer auf deine Kommandozeile und den Bugreport 
gesehen hätte, hätte ich es auch merken müssen ;-)

Kurzfassung: Du kannst keine 0xF8 in die efuse des Atmega168 schreiben!

Bei dem Atmega168 sind nur die untersten 3 Bits der efuse beschreibbar, 
d.h. der Wert 0xF8 (11111000) ist eigentlich ein 0x00 (00000000) und 
genau das bekommst du beim Verify zurück!

Kontrolliere die Quelle aus der du die 0xF8 hast und was damit bezweckt 
werden sollte. Wenn es darum geht, einen 1024 Word Bootloader zu 
schützen und den per Reset anzuspringen, dann ändere die Kommandozeile 
und alles wird gut.

C:\avrdude -c stk200 -P lpt1 -p m168 -e -U lfuse
:w:0xE2:m -U hfuse:w:0xDC:m -U efuse:w:0x0:m -E reset

[gast (Gast)]

Stimmt, 0xF8 sollte den Bootloaderbereich mit 1024 Word aktivieren.

Hier ein Link zu meiner Quelle.
Den Administrator hab ich über diesen Fehler benachrichtigt.
http://www.engbedded.com/fusecalc/
http://www.engbedded.com/cgi-bin/fc.cgi

Vielen Dank für Deine Hilfe.

[Mark Hämmerling (Gast)]

Hallo,

ist lange her, dass ich hier mal was geschrieben habe. :)

Habe den Fehler behoben. Ich habe mich durch die Default-Werte in der 
Tabelle irritieren lassen, die ja trotz undefinierter Fuse-Bits auf 
"unprogrammed" ('1') stehen. Jetzt habe ich die Randnotiz (werden als 
'0' gelesen) auch gesehen. :)

Im Calculator werden jetzt global alle nicht-definierten Bits auf '0' 
ausmaskiert. Also auch aus Pseudo-Werten, die man über die 
Hex-Direkteingabe übertragen hat.

Danke für den Hinweis.

Viel Spaß weiterhin mit dem Tool!

Mark

[Mark Hämmerling (Gast)]

Hallo nochmal,

also ganz so einfach ist es offensichtlich doch nicht. Dass undefinierte 
Fuse-Bits als '0' gelesen werden, trifft offensichtlich nur auf einen 
Teil der AVRs zu. Seit ich die Änderung (s.o.) gemacht habe, häufen sich 
die Bugreports, dass die Bits auf '1' stehen müssten. Und tatsächlich 
trifft das auf diese Targets zu (z.B. m644, t*4). Nun hab ich mir 
nochmal das XML-File vom m168 angesehen und selbst Atmel schreibt dort 
als Default-Wert für die "ExtendedFuse" einen Wert von 0xf9, also mit 
'1' in den undefinierten Bits.

Wer hat eine gute Idee, wie ich die Bits nun behandeln soll? Meiner 
Meinung nach sollten sie doch wieder als '1' angezeigt werden. Wenn es 
selbst Atmel so schreibt. Man darf halt den Verify-Error von avrdude 
nicht so ernst nehmen.

Ich tendiere dazu, die Bits wieder als '1' anzuzeigen und einen 
Hinweistext bzgl. evtl. auftretender Verify-Errors dazu zu schreiben. 
Was meint Ihr?

Grüße,
Mark

[Stefan B. (stefan)]

Mark Hämmerling wrote:

> Ich tendiere dazu, die Bits wieder als '1' anzuzeigen und einen
> Hinweistext bzgl. evtl. auftretender Verify-Errors dazu zu schreiben.
> Was meint Ihr?

An der offiziellen Doku bleiben plus die Idee mit dem Hinweistext finde 
ich gut.

[Mark Hämmerling (Gast)]

Hallo,

also auch eine '1' als zu programmierenden Wert ausweisen, auch wenn die 
undefinierten Bits bei dem Device als '0' gelesen werden? Es sollte ja 
nicht schaden, eine '1' in ein undef. Bit zu schreiben. Ich will halt 
nur die Verwunderung der User bei Verify-Fehlern begrenzen.

Mark

[Mark Hämmerling (Gast)]

Hallo,

http://www.engbedded.com/fusecalc/

Version 0.8.0 beinhaltet nun diese Warnmeldungen, sobald sich die Werte 
unterscheiden.

Mark

[alex (Gast)]

Hallo zusammen.

Versuche gerade mit avrdude einen atmega168p zu programmieren.
In der avrdude.conf gibt es aber keine configuration von diesem chip.
kann mir jemand helfen wie ich eine configuration von diesem chip machen 
kann.

[Jörg W. (dl8dtl) (Moderator)]

alex schrieb:

> kann mir jemand helfen wie ich eine configuration von diesem chip machen
> kann.

Es sollte genügen, die Konfiguration des ATmega168 zu clonen und
die device ID darin zu ersetzen.