Hallo!
Habe ein Problem:
Ich kann auf mein ATmega8 keine Fuses schreiben. Habe 2 verschiedene
ATmega8 (eine Fabrikneu, eine bereits in Benutzung) verwendet, bei
keinem geht es.
Zuerst probierte ich es mit dem AVR-burn-o-mat, der konnte die Fuses
zwar auslesen, meldete jedoch einen Fehler, als ich die neuen Fuses
schreiben wollte.
Wenn ich die Fuses gleich lasse, und auf schreiben klicke, meldet er
Erfolg.
Habe dann auch den avrdude aus der Kommandozeile ausprobiert, auch der
konnte es nicht beschreiben.
Verwende eine Experimentierplatine von myAVR.de und den Programmer MK2.
Ein normales Programm kann man problemlos übertragen. (Ebenfalls mit
avrdude)
Was kann da nicht stimmen?
Danke im Voraus!
Hallo!
Es steht
ATMEL 0803I
ATMEGA8L-8PU
auf dem Chip.
avrdude habe ich mit dem Befehl
avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U lfuse:w:0x3F:m -U
hfuse:w:0xD9:m
aufgerufen.
uC schrieb:> Habe dann auch den avrdude aus der Kommandozeile ausprobiert, auch der> konnte es nicht beschreiben.uC schrieb:> avrdude habe ich mit dem Befehl>> avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U lfuse:w:0x3F:m -U> hfuse:w:0xD9:m
Und die genaue Ausgabe von avrdude war wie? Besser noch ein -vv
anhängen, für mehr Infos.
Ich habe am Anfang auch probiert bei
"Would you like this fuse to be changed back? [y/n]" y einzugeben. Dann
hat er gar nichts mehr gemacht. Ist einfach hängengeblieben. Musste mit
Strg+C abbrechen.
Probiere evtl. auch mal die Option -B mit verschiedenen Werten:
-B bitclock
Specify the bit clock period for the JTAG interface or the ISP clock
(JTAG ICE only). The value is a floating-point number in
microseconds.
Mit welchem Takt läuft der Atmega8?
Laut fuse calculator entspricht
lfuse 0xFF Brown-out detection level at VCC = 2.7 V
lfuse 0x3F Brown-out detection level at VCC = 4.0 V
Welches Vtarget liegt an?
Hallo!
Danke für die vielen Antworten!
Marc V. schrieb:> Und so: "avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U hfuse:w:0xD9:m -U> lfuse:w:0x3F:m">> ?
geht auch nicht.
grundschüler schrieb:> uC schrieb:>> [y/n]>> probier mal 'z' ->englische Tastatur
geht auch nicht. (Außerdem ist meine Tastatur Deutsch)
Alexander S. schrieb:> Probiere evtl. auch mal die Option -B mit verschiedenen Werten:>> -B bitclock> Specify the bit clock period for the JTAG interface or the ISP clock> (JTAG ICE only). The value is a floating-point number in> microseconds.
Habe 1, 4, 8, 10 und 50 probiert. Geht alles nicht.
Alexander S. schrieb:> Mit welchem Takt läuft der Atmega8?
3,6864MHz
Alexander S. schrieb:> Laut fuse calculator entspricht>> lfuse 0xFF Brown-out detection level at VCC = 2.7 V> lfuse 0x3F Brown-out detection level at VCC = 4.0 V>> Welches Vtarget liegt an?
Die Betriebsspannung ist 5V.
Danke für alle weiteren Tipps im Voraus!
Alexander S. schrieb:> Laut fuse calculator entspricht>> lfuse 0xFF Brown-out detection level at VCC = 2.7 V> lfuse 0x3F Brown-out detection level at VCC = 4.0 V>> Welches Vtarget liegt an?
Weder noch, bei 0xff oder 0xf3 ist BODEN = 1 also disabled.
Schonmal die ISP Geschwindigkeit runtergesetzt? Externer HF Crystal/Oszi
sitzt?
Draco schrieb:> Externer HF Crystal/Oszi> sitzt?
Nehme schon an, immerhin funktioniert ja das eingespielte Programm
tadellos.
Draco schrieb:> Schonmal die ISP Geschwindigkeit runtergesetzt?
Was meinst du damit? Wie geht das?
Draco schrieb:> Und eventuell mal den Safemode ausschalten: -s
Geht auch nicht...
Draco schrieb:> Alexander S. schrieb:>> Laut fuse calculator entspricht>>>> lfuse 0xFF Brown-out detection level at VCC = 2.7 V>> lfuse 0x3F Brown-out detection level at VCC = 4.0 V>>>> Welches Vtarget liegt an?>> Weder noch, bei 0xff oder 0xf3 ist BODEN = 1 also disabled.
Wenn man unter http://www.engbedded.com/fusecalc
den ATmega8 auswählt und unten
low 0xFF high 0xD9 eingibt und "Apply values" anklickt sagt er
Brown-out detection enabled; [BODEN=0]
Brown-out detection level at VCC = 2.7 V;[BODLEVEL=1]
bei
low 0x3F high 0xD9 sagt er
Brown-out detection enabled; [BODEN=0]
Brown-out detection level at VCC = 4.0 V;[BODLEVEL=0]
0x3F, nicht 0xF3 (s.o.)
Ahh... Ja, ich hab 0xf3 gerechnet :-D Aber bei 0xff is die Brown-Out
aber deaktiviert (BODEN = 1) weil ja das ganze Register auf 0b11111111
steht. Muss ja dann.
@uC:
Aber normal beschreiben kann, also Flash und EEPROM, kannst du ihn?!
Dann bleibt ja eigentlich bloß der Safemode noch übrig, weil er schreibt
ja dann auf "Heck oder Verreck" die Fuses ins Register. Sehr komisch.
Draco schrieb:> Aber normal beschreiben kann, also Flash und EEPROM, kannst du ihn?!> Dann bleibt ja eigentlich bloß der Safemode noch übrig, weil er schreibt> ja dann auf "Heck oder Verreck" die Fuses ins Register. Sehr komisch.
Ja, man kann normal ins Flash schreiben und man kann die Fuses auch
auslesen.
Den Safemode habe ich auch probiert auszuschalten, indem ich ein -s
angefügt habe. (Ist das richtig so?)
Ich habe auch schon an das Mäuseklavier am MK2 gedacht.
Soweit ich weiß, muss der aber einfach in der selben Stellung sein, wie
beim Flash-Programmieren. Und so ist er ja auch eingestellt.
uC schrieb:>> Und so: "avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U hfuse:w:0xD9:m -U>> lfuse:w:0x3F:m">>>> ?>> geht auch nicht.Alexander S. schrieb:> $> avrdude -p m8 -c stk500v2 -B 8 -vv -U lfuse:w:0x24:m -U> hfuse:w:0xD9:m
???
Mal ist es avr911, mal stk500v2.
Probiere ganz einfach die Reihenfolge der Fuses umzudrehen, also zuerst
die hfuse und dann die lfuse.
Mit den AVR PRogrammern kenne ich mich nicht aus wegen den avrdude
optionen, Schon probiert?
Beitrag "ATMEGA8 mit avrdude flashen macht Probleme"
Zitat:
hab jetzt mal versucht die Delays sukzessive zu vergrößern und siehe da:
bei -i [50..70] läuft die Kiste.
Leider brachte auch -i nichts. Habe mehrere Werte probiert, von klein
bis groß.
Wie schon Alexander S. schrieb, stammt das Beispiel von ihm. Ich habe
nur diesen einen Programmer, den MKII.
bei bascom ist der flash-Teil sehr komfortabel. Man kann damit fuses
sehr gut auslesen wie auch setzen. ich hatte neulich ein Problem mit
fuses. ging dann aber auch mit avrdude:
Beitrag "avrdude fuse-bits"
Hi, habe genau den gleichen Fehler mit dem USBasp und arduino Uno
(328p).
Das flashen deines Programmes geht noch, aber Fuses setzen bzw den
Bootloader neu schreiben geht nicht. Das ganze Elend fing an nachdem ich
Avrdude von 6.1 auf Version 6.3 und die Arduino IDE von 1.6.8 auf
Version 1.6.10 geupdated habe. Ich bekomme folgende Fehlermeldung:
"avrdude: verification error, first mismatch at byte 0x0000
0xfd != 0x05" Im Internet hab ich die Ursache gefunden. Bei der efuse
werden nur 3 Bits geschrieben, aber anschliessend wird das ganze Byte
ausgelesen und mit dem zu schreibenden Wert verglichen. Abhilfe soll ein
patch für die avrdude.conf schaffen. Leider hat das patchen auf meinem
Ubunturechner nicht richtig geklappt.
Hoffe ich habe euch ein bisschen helfen können und den Fehler etwas
eingrenzen können. Wenn einer von euch es zum laufen bekommt, sagt doch
bitte hier bescheit.
liebe Grüsse Elena
uC schrieb:> avrdude: Version 6.1, compiled on Nov 23 2014 at 21:15:32Elena schrieb:> Das ganze Elend fing an nachdem ich> Avrdude von 6.1 auf Version 6.3 und die Arduino IDE von 1.6.8 auf> Version 1.6.10 geupdated habe.
Interessant. Allerdings hat uC die Version 6.1 von avrdude verwendet.
Da ist irgendwie auch kein Zusammenhang.
0xff= 1111 1111
0x3f= 0011 1111
Dann müsste der Progger allerdings eine 0x38 00111000 oder ein ähnliches
Muster als Mismatch zurückgeben.
EDIT: Ich habe mit Fuses und dem Atmega8 übrigens null Probleme.
Hallo!
Habe nun von myAVR das myAVR-ProgTool heruntergeladen und auf Windows 7
versucht die Fusebits zu schreiben. Es hat tatsächlich geklappt.
Das Programm kann die Fusebits aber nicht auslesen, deshalb wollte ich
mit Burn-o-mat überprüfen, ob sie wirklich übernommen wurde. Auslesen
hat ja bislang immer geklappt.
Jedoch siehe da: nun kann Burn-o-mat, aber auch avrdude selbst per
Kommandozeile die Fusebits nicht mal mehr lesen.
Ich weiß nun wirklich nicht mehr, was da los ist....
Noch ein UPDATE:
Ich habe versucht, die Firmware vom MK2 upzudaten. Hat (von Win 7 aus)
auch geklappt. Die Fusebits können leider dennoch nach wie vor nicht
gelesen und nicht geschrieben werden.
uC schrieb:> Habe nun von myAVR das myAVR-ProgTool heruntergeladen und auf Windows 7> versucht die Fusebits zu schreiben. Es hat tatsächlich geklappt.
Das ist eine sehr mutige Annahme. Mur weil du keine Fehlermeldung
bekommen hast (sagst du zwar nicht, nehme ich aber an) heißt das nicht,
daß es auch geklappt hat. Denn:
> Das Programm kann die Fusebits aber nicht auslesen
du hast das Ergebnis ja nicht kontrolliert.
> deshalb wollte ich> mit Burn-o-mat überprüfen, ob sie wirklich übernommen wurde. Auslesen> hat ja bislang immer geklappt.>> Jedoch siehe da: nun kann Burn-o-mat, aber auch avrdude selbst per> Kommandozeile die Fusebits nicht mal mehr lesen.>> Ich weiß nun wirklich nicht mehr, was da los ist....
Es gibt einige Fuse-Einstellungen, bei denen anschließend der Zugriff
über ISP nicht mehr funktioniert. Z.B. wenn du den Reset-Pin deaktivert
hast oder wenn eine nicht vorhandene Taktquelle eingestellt ist.
Höchstwahrscheinlich hat das komische Tool deine Fuses in einen solchen
Zustand versetzt. Jetzt brauchst du erstmal einen HV-Programmer ...
Axel S. schrieb:> Es gibt einige Fuse-Einstellungen, bei denen anschließend der Zugriff> über ISP nicht mehr funktioniert. Z.B. wenn du den Reset-Pin deaktivert> hast oder wenn eine nicht vorhandene Taktquelle eingestellt ist.> Höchstwahrscheinlich hat das komische Tool deine Fuses in einen solchen> Zustand versetzt. Jetzt brauchst du erstmal einen HV-Programmer ...
Den Flash und das EEPROM kann er ja beschreiben und lesen. Also so war
der letzte Stand :-D
Hallo!
Genau. Flashen geht auch nach dem myAVR-Prog-Ausflug problemlos.
Dass es geklappt hat, schließe ich daraus, dass der fabrikneue ATmega8
nun mit dem externen Quarz läuft und nicht mehr mit dem internen
RC-Oszillator.
