Forum: Mikrocontroller und Digitale Elektronik avrdude schreibt keine Fuses bei ATmega8


von uC (Gast)


Lesenswert?

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!

von Rene H. (Gast)


Lesenswert?

Wie ist die genaue Bezeichnung des AtMega (was steht auf dem Chip) und 
wie rufst Du avrdude auf?

von uC (Gast)


Lesenswert?

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.

von Alexander S. (alesi)


Lesenswert?

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.

von uC (Gast)


Lesenswert?

avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U lfuse:w:0x3F:m -U 
hfuse:w:0xD9:m -vv

avrdude: Version 6.1, compiled on Nov 23 2014 at 21:15:32
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is 
"/home/USERNAMEANONYMISIERT/.avrduderc"
         User configuration file does not exist or is not a regular 
file, skipping

         Using Port                    : /dev/ttyUSB0
         Using Programmer              : avr911
         AVR Part                      : ATmega8
         Chip Erase delay              : 10000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page 
Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages 
MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ 
----- ----- ---------
           eeprom         4    20   128    0 no        512    4      0 
9000  9000 0xff 0xff
           flash         33    10    64    0 yes      8192   64    128 
4500  4500 0xff 0x00
           lfuse          0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           lock           0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           calibration    0     0     0    0 no          4    0      0 
0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0 
0     0 0x00 0x00

         Programmer Type : butterfly
         Description     : Atmel AppNote AVR911 AVROSP

Connecting to programmer: .
Found programmer: Id = "AVR ISP"; type = S
    Software Version = 2.5; Hardware Version = 2.0
Programmer supports auto addr increment.
Programmer supports buffered memory access with buffersize=512 bytes.

Programmer supports the following devices:
    Device code: 0x01
    Device code: 0x02
    Device code: 0x03
    Device code: 0x04
    Device code: 0x05
    Device code: 0x06
    Device code: 0x07
    Device code: 0x08
    Device code: 0x09
    Device code: 0x0a
    Device code: 0x0b
    Device code: 0x0c
    Device code: 0x0d
    Device code: 0x0e
    Device code: 0x0f
    Device code: 0x10
    Device code: 0x11
    Device code: 0x12
    Device code: 0x13
    Device code: 0x14
    Device code: 0x15
    Device code: 0x16
    Device code: 0x17
    Device code: 0x18
    Device code: 0x19
    Device code: 0x1a
    Device code: 0x1b
    Device code: 0x1c
    Device code: 0x1d
    Device code: 0x1e
    Device code: 0x1f
    Device code: 0x20
    Device code: 0x21
    Device code: 0x22
    Device code: 0x23
    Device code: 0x24
    Device code: 0x25
    Device code: 0x26
    Device code: 0x27
    Device code: 0x28
    Device code: 0x29
    Device code: 0x2a
    Device code: 0x2b
    Device code: 0x2c
    Device code: 0x2d
    Device code: 0x2e
    Device code: 0x2f
    Device code: 0x30
    Device code: 0x31
    Device code: 0x32
    Device code: 0x33
    Device code: 0x34
    Device code: 0x35
    Device code: 0x36
    Device code: 0x37
    Device code: 0x38
    Device code: 0x39
    Device code: 0x3a
    Device code: 0x3b
    Device code: 0x3c
    Device code: 0x3d
    Device code: 0x3e
    Device code: 0x3f
    Device code: 0x40
    Device code: 0x41
    Device code: 0x42
    Device code: 0x43
    Device code: 0x44
    Device code: 0x45
    Device code: 0x46
    Device code: 0x47
    Device code: 0x48
    Device code: 0x49
    Device code: 0x4a
    Device code: 0x4b
    Device code: 0x4c
    Device code: 0x4d
    Device code: 0x4e
    Device code: 0x4f
    Device code: 0x50
    Device code: 0x51
    Device code: 0x52
    Device code: 0x53
    Device code: 0x54
    Device code: 0x55
    Device code: 0x56
    Device code: 0x57
    Device code: 0x58
    Device code: 0x59
    Device code: 0x5a
    Device code: 0x5b
    Device code: 0x5c
    Device code: 0x5d
    Device code: 0x5e
    Device code: 0x5f
    Device code: 0x60
    Device code: 0x61
    Device code: 0x62
    Device code: 0x63
    Device code: 0x64
    Device code: 0x65
    Device code: 0x66
    Device code: 0x67
    Device code: 0x68
    Device code: 0x69
    Device code: 0x6a
    Device code: 0x6b
    Device code: 0x6c
    Device code: 0x6d
    Device code: 0x6e
    Device code: 0x6f
    Device code: 0x70
    Device code: 0x71
    Device code: 0x72
    Device code: 0x73
    Device code: 0x74
    Device code: 0x75
    Device code: 0x76
    Device code: 0x77
    Device code: 0x78
    Device code: 0x79
    Device code: 0x7a
    Device code: 0x7b
    Device code: 0x7c
    Device code: 0x7d
    Device code: 0x7e
    Device code: 0x7f

avrdude: devcode selected: 0x01
avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 
0.05s

avrdude: Device signature = 0x1e9307
avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D9
avrdude: reading input file "0x3F"
avrdude: writing lfuse (1 bytes):

Writing |                                                    | 0% 0.00s 
***failed;
Writing | ################################################## | 100% 
0.00s

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

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

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

avrdude: safemode: lfuse reads as FF
avrdude: safemode: hfuse reads as D9
avrdude: safemode: lfuse changed! Was 3f, and is now ff
Would you like this fuse to be changed back? [y/n] n
avrdude: safemode: Fuses OK (E:FF, H:D9, L:3F)

avrdude done.  Thank you.

von uC (Gast)


Lesenswert?

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.

von grundschüler (Gast)


Lesenswert?

uC schrieb:
> [y/n]

probier mal 'z' ->englische Tastatur

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

Und so:
1
 "avrdude -c avr911 -P/dev/ttyUSB0 -p m8 -U hfuse:w:0xD9:m -U lfuse:w:0x3F:m"

 ?

: Bearbeitet durch User
von Alexander S. (alesi)


Lesenswert?

Hallo,

nur zum Vergleich als Referenz habe ich gerade bei einem Atmega8-16PU
mit dem STK500 die eingestellten Fuses noch einmal geschrieben:

$> avrdude -p m8 -c stk500v2 -B 8 -vv -U lfuse:w:0x24:m -U 
hfuse:w:0xD9:m

avrdude: Version 6.1, compiled on Sep 11 2014 at 20:00:34
         Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
         Copyright (c) 2007-2014 Joerg Wunsch

         System wide configuration file is "/etc/avrdude.conf"
         User configuration file is "/home/xxx/.avrduderc"
         User configuration file does not exist or is not a regular 
file, skipping

         Using Port                    : /dev/ttyS0
         Using Programmer              : stk500v2
         Setting bit clk period        : 8.0
         AVR Part                      : ATmega8
         Chip Erase delay              : 10000 us
         PAGEL                         : PD7
         BS2                           : PC2
         RESET disposition             : dedicated
         RETRY pulse                   : SCK
         serial program mode           : yes
         parallel program mode         : yes
         Timeout                       : 200
         StabDelay                     : 100
         CmdexeDelay                   : 25
         SyncLoops                     : 32
         ByteDelay                     : 0
         PollIndex                     : 3
         PollValue                     : 0x53
         Memory Detail                 :

                                  Block Poll               Page 
Polled
           Memory Type Mode Delay Size  Indx Paged  Size   Size #Pages 
MinW  MaxW   ReadBack
           ----------- ---- ----- ----- ---- ------ ------ ---- ------ 
----- ----- ---------
           eeprom         4    20   128    0 no        512    4      0 
9000  9000 0xff 0xff
           flash         33    10    64    0 yes      8192   64    128 
4500  4500 0xff 0x00
           lfuse          0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           hfuse          0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           lock           0     0     0    0 no          1    0      0 
2000  2000 0x00 0x00
           calibration    0     0     0    0 no          4    0      0 
0     0 0x00 0x00
           signature      0     0     0    0 no          3    0      0 
0     0 0x00 0x00

         Programmer Type : STK500V2
         Description     : Atmel STK500 Version 2.x firmware
         Programmer Model: STK500
         Hardware Version: 2
         Firmware Version Master : 2.10
         Topcard         : Unknown
         Vtarget         : 5.1 V
         SCK period      : 8.7 us
         Varef           : 5.0 V
         Oscillator      : 14.400 kHz

avrdude: AVR device initialized and ready to accept instructions

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

avrdude: Device signature = 0x1e9307
avrdude: safemode: lfuse reads as 24
avrdude: safemode: hfuse reads as D9
avrdude: reading input file "0x24"
avrdude: writing lfuse (1 bytes):

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

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

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

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

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

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

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

avrdude: verifying ...
avrdude: 1 bytes of hfuse verified

avrdude: safemode: lfuse reads as 24
avrdude: safemode: hfuse reads as D9
avrdude: safemode: Fuses OK (E:FF, H:D9, L:24)

avrdude done.  Thank you.

von Alexander S. (alesi)


Lesenswert?

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?

von Alexander S. (alesi)


Lesenswert?

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?

von uC (Gast)


Lesenswert?

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!

von Draco (Gast)


Lesenswert?

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?

von Draco (Gast)


Lesenswert?

Und eventuell mal den Safemode ausschalten: -s

von uC (Gast)


Lesenswert?

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

von Alexander S. (alesi)


Lesenswert?

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

von Draco (Gast)


Lesenswert?

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.

von Philipp K. (philipp_k59)


Lesenswert?

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

Irgendwas am Bootloader geändert, Falsche Bootloader Size in den Fuses?

von uC (Gast)


Lesenswert?

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.

von Marc V. (Firma: Vescomp) (logarithmus)


Lesenswert?

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.

von Philipp K. (philipp_k59)


Lesenswert?

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.

von Alexander S. (alesi)


Lesenswert?

Marc V. schrieb:
> Mal ist es avr911, mal stk500v2.
>  Probiere ganz einfach die Reihenfolge der Fuses umzudrehen, also zuerst
>  die hfuse und dann die lfuse.

Das mit dem stk500v2 war zum Vergleich ein Beispiel von mir, nicht von
uC. Habe ich auch deutlich geschrieben:
"nur zum Vergleich als Referenz habe ich gerade bei einem Atmega8-16PU
mit dem STK500 die eingestellten Fuses noch einmal geschrieben:"
Beitrag "Re: avrdude schreibt keine Fuses bei ATmega8"

Die Reihenfolge der Fuses umzudrehen wurde hier
Beitrag "Re: avrdude schreibt keine Fuses bei ATmega8"
schon vorgeschlagen und hier
Beitrag "Re: avrdude schreibt keine Fuses bei ATmega8"
beantwortet.

von uC (Gast)


Lesenswert?

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.

von uC (Gast)


Lesenswert?

P.S.: Habe auch die Option -u probiert, also den Safemode komplett 
ausgeschalten. Funktioniert leider auch nicht.

von Philipp K. (philipp_k59)


Lesenswert?

schonmal nen -e angehängt?

von grundschüler (Gast)


Lesenswert?

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"

von Elena (Gast)


Lesenswert?

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

von Alexander S. (alesi)


Lesenswert?

uC schrieb:
> avrdude: Version 6.1, compiled on Nov 23 2014 at 21:15:32

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

von Philipp K. (philipp_k59)


Lesenswert?

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.

: Bearbeitet durch User
von uC (Gast)


Lesenswert?

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

von uC (Gast)


Lesenswert?

P.S.: -e hat auch nicht geklappt

von uC (Gast)


Lesenswert?

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.

von uC (Gast)


Lesenswert?

Sind euch auch die Ideen ausgegangen? :(

von Axel S. (a-za-z0-9)


Lesenswert?

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

von Draco (Gast)


Lesenswert?

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

von uC (Gast)


Lesenswert?

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.

von uC (Gast)


Lesenswert?

UPDATE:

Leider besteht mein Problem immer noch. Bin weiterhin für eure Ideen 
dankbar!

von Philipp K. (philipp_k59)


Lesenswert?

Einfach mal nen 3€ USBasp als vergleich kaufen?

Bzw. schonmal als Test versucht einen Bootloader mit den Fuses und 
Lockbits zu flashen?

: Bearbeitet durch User
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
Noch kein Account? Hier anmelden.