Avrdude und EESAVE Fuse

Okay dachte das es da eventuell einen versteckten Befehl gibt.
Jetzt wollte ich es testen indem ich vor dem flashen die Fuses 
zurücksetze und zwar so das EESAVE nicht gesetzt ist und anschließend 
dann flash und eeprom flashe.

-c stk500v2 -p m1281 -e -PCOM7 -U lfuse:w:0xFE:m -U hfuse:w:0xD9:m -U 
efuse:w:0xFC:m -e -U flash:w:test.hex:i -U eeprom:w:test.eep:a

Das führt zu folgendem Resultat:

1

-c: Device signature = 0x1e9704

2

-c: erasing chip

3

-c: reading input file "0xFE"

4

-c: writing lfuse (1 bytes):

5

-c: 1 bytes of lfuse written

6

-c: verifying lfuse memory against 0xFE:

7

-c: load data lfuse data from input file 0xFE:

8

-c: input file 0xFE contains 1 bytes

9

-c: reading on-chip lfuse data:

10

-c: verifying ...

11

-c: 1 bytes of lfuse verified

12

-c: reading input file "0xD9"

13

-c: writing hfuse (1 bytes):

14

-c: 1 bytes of hfuse written

15

-c: verifying hfuse memory against 0xD9:

16

-c: load data hfuse data from input file 0xD9:

17

-c: input file 0xD9 contains 1 bytes

18

-c: reading on-chip hfuse data:

19

-c: verifying ...

20

-c: 1 bytes of hfuse verified

21

-c: reading input file "0xFC"

22

-c: writing efuse (1 bytes):

23

-c: 1 bytes of efuse written

24

-c: verifying efuse memory against 0xFC:

25

-c: load data efuse data from input file 0xFC:

26

-c: input file 0xFC contains 1 bytes

27

-c: reading on-chip efuse data:

28

-c: verifying ...

29

-c: 1 bytes of efuse verified

30

-c: reading input file "test.hex"

31

-c: writing flash (8770 bytes):

32

-c: 8770 bytes of flash written

33

-c: verifying flash memory against test.hex:

34

-c: load data flash data from input file test.hex:

35

-c: input file test.hex contains 8770 bytes

36

-c: reading on-chip flash data:

37

-c: verifying ...

38

-c: 8770 bytes of flash verified

39

-c: reading input file "test.eep"

40

-c: input file test.eep auto detected as Intel Hex

41

-c: writing eeprom (11 bytes):

42

-c: 11 bytes of eeprom written

43

-c: verifying eeprom memory against test.eep:

44

-c: load data eeprom data from input file test.eep:

45

-c: input file test.eep auto detected as Intel Hex

46

-c: input file test.eep contains 11 bytes

47

-c: reading on-chip eeprom data:

48

-c: verifying ...

49

-c: verification error, first mismatch at byte 0x0008

50

    0x01 != 0xff

51

-c: verification error; content mismatch

52

53

-c done.  Thank you.

EESAVE Fuse ist wirklich nicht mehr gesetzt das habe ich durch manuelles 
auslesen der Fuses nochmal überprüft.

Jemand eine Idee was da schief geht ?

Hm das war auch meine Vermutung. Habe die Kommandozeile daher mehrfach 
ausgeführt und zwischenzeitlich nochmal die Fuses ausgelesen und das 
EESAVE bit geprüft der Fehler blieb bestehen.

Dann habe ich mal eine neuere Avrdude Version probiert. Die alt war 5.x 
die neue jetzt die wie ich gerade gesehen habe von die compilierte 
avrdude-6.0rc2.zip

Mit der Version läuft Avrdude durch sprich schreibt und verifiziert 
eeprom erfolgreich.

Allerdings zeigte mein Programm jetzt auffälliges Verhalten beim 
starten. Kurze Prüfung ergab nicht die gewünschten default eeprom Werte.

Als Programmer verwende ich einen my smart usb light da ist das Progtool 
"my Avr ProgTool" dabei. Wenn ich damit exakt die gleich eeprom Datei 
flashe funktioniert das Programm uns die Startwerte passen. Mit dem Tool 
habe ich das eeprom jetzt auch ausgelesen. Einmal mit dem von Avrdude 
geflashten file und einmal mit dem über das Avr ProgTool. In beiden 
Fällen andere Werte. (Die genauen kann ich morgen nochmal posten)

Wie gesagt wurde in beiden fällen die exakt gleich von Atmel Studio 
erzeugte .eep Dateu geflasht und von Avrdude auch erfolgreich 
verifiziert.

Sehr merkwürdig gerade.

So ein paar Updates. Es wird immer komischer.

Die Original eep Datei die ich flashe sieht so aus: (leerzeichen zur 
besseren Übersicht)

1

: 0B 0000 00 0100010101010101010101 EB

Jetzt das ganze nach dem flashen mit Avrdude einmal ausgelesen mit 
Avrdude:

1

:200000000100010101010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEB

2

:200800000100010101010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3

Jetzt das ganze nach dem flashen mit MyAvr einmal ausgelesen mit 
Avrdude:

1

:200000000100010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF1

2

:200800000100010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE9

Jetzt das ganze nach dem flashen mit Avrdude einmal ausgelesen mit 
MyAvr:

1

00 01 00 01 01 01 01 01 01  ........

2

08 FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿ

3

10 01 01 01                 ...

Jetzt das ganze nach dem flashen mit MyAvr einmal ausgelesen mit MyAvr:

1

0 01 00 01 01 01 01 01 01  ........

2

8 01 01 01                 ...

Interessanterweise sehen hier die eeprom Werte die mit Avrdude geflasht 
wurden richtiger aus als die die mit myAvr geflasht wurden !?

Damit es noch kurioser wird. Mit Avrdude habe ich über die im obigen 
Post angegebene Kommandozeile geflasht. Resultat der geflashten Software 
eeprom liest falsche Startwerte. (Es ist die einfache Darstellung einer 
zweistelligen Zahl auf einer zweistelligen Segmentanzeige. Nach dem 
flashen sollte der Anfangswert 1 sein. Die Software zur Anzeige auf der 
Segmentanzeige gibt lediglich bei zahlen >= 0 und <= 99 etwas aus bei 
abweichenden Werten bleibt sie aus) Im Falle von Avrdude bleibt Sie aus.

Jetzt mit Avrdude in einem zweiten Kommando sprich nicht eine 
zusammenhängende Zeile nur die eep Datei geflasht ohne vorher die 
Firmware zu flashen. Resultat der Richtige Startwert wird übernommen und 
auf der Segmentanzeige wird "01" angezeigt.

Damit es jetzt noch spaßiger wird. Ich kann über einen Taste die Zahl 
auf der Segmentanzeige verstellen und der neue Wert wird ins eeprom 
geschrieben. Also die Zahl auf "11" gestellt. Zum testen schaltung 
einmal aus und wieder ein. Reusltat Segmentanzeige zeigt "11" an Wert 
muss also korrekt im eeprom liegen.

Also das eeprom mit dem aktuellen Wert "11" nochmal auslesen.

Ausgelesen mit Avrdude:

1

:200000000100010101010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEB

2

:200800000100010101010101010101FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFE3

Ausgelesen mit MyAvr:

1

00 01 00 01 01 01 01 01 01  ........

2

08 01 01 0B FF FF FF FF FF  ...ÿÿÿÿÿ

3

10 01 01 01                 ...

Avrdude erkennt die 0B die aktuell definitiv im eeprom stehen müssen 
nicht. myAvr hingegen schon.

Okay meine Nachforschungen sind soweit beendet.
Es muss an den aktuellen Versionen der STK 500 Implementierung liegen 
bei der sich mit der Zeit irgendwas relevantes verändert haben muss.

Hier sieht man das auch nochmal gut:

1

00 01 00 01 01 01 01 01 01  ........

2

08 FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿ

3

10 01 01 01                 ...

Aus irgendeinem Grund passiert ab Adresse 0x08 mist und die Daten die 
eigentlich da hingehören landen auf Adresse 0x10. Erklärt auch das 
Problem mit der Segmentanzeige den die dafür vorgesehene eeprom Adresse 
liegt genau auf einem der 3 verrutschten Byte und liest ab 0x08 als Wert 
0xFF anstelle von 0x01.

Fazit:
- myAvr ProgTool beschreibt und verifiziert das eeprom richtig
- Atmelstudio STK500.exe beschreibt und verifiziert das eeprom richtig
- Atmelstudio 6 beschreibt das eeprom falsch und die Verifikation geht 
schief
- Avrdude in der "alten Version" beschreibt das eeprom falsch und die 
Verifikation geht schief
- Avrdude in der "neuen Version" beschreibt das eeprom falsch bestätigt 
aber die Verifikation als erfolgreich

Ich vermute das eigentlich Problem daher in der mySmart USB light 
Firmware die scheinbar mit den aktuelleren Tools nicht läuft. (Eventuell 
ein Timingproblem ?) Ich benutze jetzt erstmal die STK500.exe die hat 
soweit alle Funktionen die ich benötige und funktioniert soweit ich das 
gerade überblicke perfekt.

Hallo,

da kann ich noch einen Erfahrungsbericht anhängen. Und zwar hab ich 
einen Tiny13 mit Avrdude über einen mySmartUSB light (der soll lt. 
Techn. Beschreibung für Avrdude als "stk500v2" kompatibel sein) 
programmiert und beim EEPROM ähnliches fehlerhaftes Verhalten 
festgestellt.

Zu schreibender Datensatz (beispielhaft):
00: 09 C0 16 C0 16 C0 14 C0  .À.À.À.À
08: 13 C0 12 C0 28 C0 10 C0  .À.À(À.À
10: 0F C0 4C C0 11 24 1F BE  .ÀLÀ.$.¾
18: CF E9 CD BF 10 E0 A0 E6  ÏéÍ¿.à æ
20: B0 E0 01 C0 1D 92 A6 36  °à.À.’¦6
28: B1 07 E1 F7 A8 D1 CD C1  ±.á÷¨ÑÍÁ
30: E7 CF 1F 92 0F 92 0F B6  çÏ.’.’.¶
38: 0F 92 11 24 8F 93 10 92  .’.$“.’

Verwendete Kommandozeile:
avrdude -p t13 -c stk500v2 -P com18 -e -U eeprom:w:"test.hex":i

und das, was danach im EEPROM stand (mit myAVR Prog Tool gelesen):
00: B0 E0 01 C0 FF FF FF FF  °à.Àÿÿÿÿ
08: 1D 92 A6 36 FF FF FF FF  .’¦6ÿÿÿÿ
10: B1 07 E1 F7 FF FF FF FF  ±.á÷ÿÿÿÿ
18: A8 D1 CD C1 FF FF FF FF  ¨ÑÍÁÿÿÿÿ
20: E7 CF 1F 92 FF FF FF FF  çÏ.’ÿÿÿÿ
28: 0F 92 0F B6 FF FF FF FF  .’.¶ÿÿÿÿ
30: 0F 92 11 24 FF FF FF FF  .’.$ÿÿÿÿ
38: 8F 93 10 92              “.’

Avrdude ist dabei auch richtigerweise mit einem Verify-Error 
ausgestiegen (0x0B != 0x09).
Das habe ich mit den Avrdude-Versionen 6.0.1 und 6.1 ausprobiert und 
auch die verschiedenen Programmer durchprobiert, mit denen Avrdude auf 
den mySmartUSB light zugreifen konnte. Ohne Erfolg, alle Ergebnisse 
gleichermaßen fehlerhaft.

Normal und richtig funktioniert hat die ganze Sache mit der Version 5.11

Jetzt ist die Frage: woran liegt's? Ganz falsch kann ich es ja nicht 
gemacht haben, wenn es mit der 5.11 funktioniert. Sollte da mal ein 
Bug-Fix gemacht werden? --> Jörg?
Kann ich was "schrauben", damit es mit den höheren Versionen 
funktioniert?

Schönen Abend noch!
Micha.

Wäre gern bereit einen Bugreport zu machen (wie, wohin?), aber könntest 
du das auch wie gesagt nachvollziehen?

Kann natürlich sein, dass der Fehler beim programmer liegt, aber mit der 
5.11 hat's ja noch funktioniert.

Wie kann man nachvollziehen warum das schief läuft?  Und kann man das 
durch verändern des conf-Files beheben?

Grüße, 73 de Micha dl1mpe

Und - gibt es schon belastbare Ergebnisse zum Thema?