Hi, Folgendes Problem. Ich habe einen Atmega bei dem das EESAVE Fuse gesetzt ist. Nun möchte ich per Avrdude ein neues eeprom file flashen. Blöderweise führt das bei gesetztem EESAVE Fuse zu einem verification missmatch error. Klar bei einem normalen Chip Erase bleibt das eeprom erhalten aber wieso lässt sich bei gesetztem Fuse keine neue eeprom Datei flashen ?
eeprom schrieb: > Klar bei einem normalen Chip Erase bleibt das eeprom erhalten aber wieso > lässt sich bei gesetztem Fuse keine neue eeprom Datei flashen ? Aus dem eben von dir genannten Grunde: wenn du den EEPROM im Ganzen beschreiben willst (seitenweise), dann erfolgt (anders als beim byteweisen Schreiben) zuvor kein implizites Löschen durch den AVR selbst. Eine separat herausgeführte Löschfunktion, die AVRDUDE zuvor aufrufen könnte (page erase) gibt es — zumindest bei den nicht-Xmegas — ebenfalls nicht. Daher bleibt nur ein chip erase mit nicht gesetzter EESAVE-Fuse. Hängt dummerweise auch noch von der Zugriffsmethode ab. ISP löscht meines Wissens immer implizit den EEPROM, JTAG oder HV-Programmierung jedoch nicht. (Müsste eigentlich auch im Datenblatt stehen.) EEPROM-Schreiben über den Terminal-Modus benutzt byteweises Schreiben. Das ist ineffektiv, hat aber eine größere Chance, vorher implizit zu löschen. Hat aber teilweise andere Eier, geht beispielsweise bei JTAG nur, wenn die OCDEN-Fuse gesetzt ist, da offensichtlich die Bearbeitung dort der CPU selbst überlassen wird (EEPROM-Zugriff wie aus dem Programm heraus). Wirklich zufrieden bin ich mit der Situation auch nicht, sie ist einfach ein Kompromiss.
:
Bearbeitet durch Moderator
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 ?
eeprom schrieb: > Jemand eine Idee was da schief geht ? Ja: das Setzen der Fuse wirkt erst nach dem Ende der aktuellen Sitzung. Die Fuses werden vom AVR gecachet, während programmiert wird. Damit ist dein Löschen von EESAVE für den von dir beabsichtigten Zweck wirkungslos geblieben.
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.
Micha schrieb: > Sollte da mal ein Bug-Fix gemacht werden? --> Jörg? Wie wäre es erstmal mit einem Bugreport? ;-) Allerdings müsste ich es schon auf einem richtigen STK500v2 nachvollziehen können, bevor ich es als AVRDUDE-Bug anerkenne. Im ISP-Modus sollte das Programmieren des EEPROM (auch byteweise) eigentlich immer funktionieren.
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
Micha schrieb: > Wäre gern bereit einen Bugreport zu machen (wie, wohin?), Dahin bitte: https://savannah.nongnu.org/bugs/?group=avrdude > aber könntest > du das auch wie gesagt nachvollziehen? Das würde ich dann schon probieren, habe aber im Moment gerade andere Dinge um die Ohren. > Kann natürlich sein, dass der Fehler beim programmer liegt, aber mit der > 5.11 hat's ja noch funktioniert. Das ist natürlich ein gutes Zeichen, dass es tatsächlich ein Bug im AVRDUDE ist. > Wie kann man nachvollziehen warum das schief läuft? Wenn du avrdude mit -vvvv aufrufst (viermal die Option "v"), dann bekommst du auf stderr ein Log der Kommunikation. Damit könntest du beide Varianten vergleichen. > Und kann man das > durch verändern des conf-Files beheben? Das kann ich dir auch erst sagen, wenn der Bug analysiert ist. ;-) Vermutlich wird's aber nicht am Configfile liegen.
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.