Hallo zusammen,
ich habe ein Mega2560 Board.
Wenn ich Sketches/Apps in das Gerät lade, funktioniert alles
einwandfrei. Auch kann mit AvrDude den EEPROM schreiben.
=> Schreiben funktioniert fehlerfrei.
Anfangs bin ich über den "sync error" beim verifizieren gestolpert und
hatte auch das Phänomen, das er fehlerfrei geschrieben hat, aber beim
Vergleichen die Sync Fehler auftraten.
=> Ich hatte das erstmal auf Prio B zur Seite gelegt.....
Dann wollte ich den EEPROM schreiben und auch wieder lesen. Schreiben
kann ich mit "AVRDUDE ... -D:w:eeprom:...:r". (r benutze ich, weil ich
"raw" am besten mit einem HEX Editor lesen und schreiben kann ;)).
Gebe ich mir den Inhalt des EEPROM per Sketch aus, sehe ich, das alles
ordnungsgemäß geschrieben wurde.
Versuche ich nun per AVRDUDE das Ganze zu lesen, sieht die erzeugte
Datei merkwürdig aus. - Wenn ich die runterschreiben will, kommt die
auch 1:1 so im Proz an.
LESEN: avrdude -v -patmega2560 -cwiring -PCOM3 -b115200 -D
"-Ueeprom:r:test01.eep:r"
SCHREIBEN: avrdude -v -patmega2560 -cwiring -PCOM3 -b115200 -D
"-Ueeprom:w:test01.eep:r"
Wie gesagt, schreiben funktioniert zu 100%
Wenn ich lese, passiert folgendes:
Geschrieben:
Byte1 Byte2 Byte3 ..... Rest der 4k FF
Gelesen:
Byte1 Byte3 FF.....
bei 2k
Byte1 Byte3 FF bis Ende.
Der Fehler ist mit den verschiedensten Konstellationen reproduzierbar.
Ist da ein Fehler in der AVRDUDE.conf (habe verschiedene Versionen
ausprobiert, auch Win/Linux)?
als Bootloader wird der Stk500 verwendet (ob v2 weis ich nicht genau).
Danke schonmal Allen.
PS: Falls ich was vergessen habe zu erwähnen, einfach nachfragen.
Woran es in dem Fall liegt, weiß ich auch nicht. Aber mögliche
Testansätze:
- Schreib mal in einem anderen Format
- es gibt eine Option bei AVRDude um langsamer zu schreiben, probier
doch mal
- Hast Du wirklich die gesamten 4K durchgesehen? evtl. steht jedes 2.
Byte auf einer anderen Seite (wär zwar ungewöhnlich, aber nicht
unmöglich) ODer die Bytes werden allgemein anders abgelegt, als Du es
erwartest
- gibt es eine Verify-Option (prüflesen nach Schreiben?)
"Wiring" ist im Wesentlichen ein STK500v2-Protokoll, nur um die
"Snoozetime" erweitert.
Ich bin mir eigentlich ziemlich sicher, dass das EEPROM-Handling in
AVRDUDE's STK500v2-Implementierung funktioniert, auch für ATMega2560.
Probieren kann ich's aber erst heute abend.
Das könnte allerdings gut und gern auch ein Bug im Bootloader sein,
der da benutzt wird.
Hallo,
vielen Dank schonmal für die Antworten.
Ja, es ist eine stk500v2 FW drin.
Die fehlenden Daten sind nirgendwo in der eep Datei zu finden. Ich habe
mir auch schon sowas gedacht, aber die Daten sind nicht vorhanden.
Ich hatte vorher Intel HEX (i) verwendet. Konnte da aber nicht direkt
reinschauen und habe dann raw genommen. Der Effekt ist der gleiche.
Gruß
Rainer U. schrieb:> wieso bist Du dann der Meinung, dass das Schreiben funktioniert?
Schrieb er doch: die Firmware liest die korrekten Werte aus.
Daher ja auch meine Vermutung, dass der benutzte Bootloader kaputt ist.
Sorry, bin erst jetzt dazu gekommen, dem Problem nachzugehen.
Ich habe den original Bootloader ("stk500v2" aus ..Arduino..Tools..)
getestet.
Das Ergebnis bleibt das Gleiche.
Hier einmal mein Vorgehen:
1. Übersetzen des Bootloader aus Version 1.8.2 mit "make mega2560"
(WinAVR 20100110).
2. Überspielen via ISP
3. Schreiben des EEPROM mit "avrdude -v -patmega2560 -cwiring -PCOM3
-b115200 -D "-Ueeprom:w:test.eep:r""
4. Auslesen des EEPROM via ISP: "avrdude -v -patmega2560 -cavrispmkii -D
"-Ueeprom:r:testreadisp.eep:r"
=> der gelesene EEPROM ist identisch mit dem aus Punkt 3 geschriebenen
EEPROM.
5. Auslesen des EEPROM "avrdude -v -v -patmega2560 -cwiring -PCOM3
-b115200 -D "-Ueeprom:r:eetest.eep:r""
=> der gelesene EEPROM entspricht dem "alten" Fehler.
Anbei noch ein paar Ausgaben:
* Avrdude Ausgabe von Punkt 5:
1
avrdude: Version 6.3, compiled on Jan 17 2017 at 12:00:53
2
Copyright (c) 2000-2005 Brian Dean, http://www.bdmicro.com/
3
Copyright (c) 2007-2014 Joerg Wunsch
4
5
System wide configuration file is "C:\WinAVR20100110\bin\avrdude.conf"
EEPROM (Anfang) der geschriebenen Version (aus 3):
1
00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15
2
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
3
32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47
4
48 49 50 51 52 53 54 55 56 57 58 59 ff ff ff ff
EEPROM (Anfang) der gelesenen Version (aus 5):
1
00 01 02 03 04 05 06 07 16 17 18 19 20 21 22 23
2
32 33 34 35 36 37 38 39 48 49 50 51 52 53 54 55
3
64 65 66 67 68 69 ff ff ff ff ff ff ff ff ff ff
Ab Offset 2048 wiederholt sich exakt der gleiche Output.
Wie gesagt, der Bootloader sollte nun passen, da ich direkt den benutzt
habe, der mit der ArduinoIDE mitinstalliert wurde.
Avrdude und Co sind auch die Versionen, die mit der ArduinoIDE
mitgeliefert wurden (also nicht die, aus WINAVR).
Danke schonmal im Voraus,
Gruß, Heron.
Das ist ja mal ein interessantes Phänomen..
Also wie oben gesagt, ich würde versuchen langsamer zu agieren
(AVRDude-Option -b oder -B, je nachdem siehe Beschreibung) und auch mal
einen anderen Chip verwenden..
OK, ich glaube ich habe das Problem gefunden.
Es scheint ein Bug im Bootloader zu sein !!
Ich habe ein kleines Programm geschrieben, um den STK500v2 direkt
auszulesen.
Dabei habe ich anfangs aber in den Bootloader geschaut und gesehen, das
der Sende Buffer eine Größe von 285 Byte hat. Daher habe ich meinen
Eingangsbuffer auf 256 gelegt.
Damit werden die (ersten) 256 Byte auch korrekt eingelesen. Aber das
Phänomen, das sich der Inhalt ab Adresse 2048 wiederholte, war noch
vorhanden.
Also.....bissel nachgedacht.... Wenn AvrDude nun statt den 256, wie bei
mir, 8 Byte in den Eingangsbuffer liest...
Ich habe meinen Eingangsbuffer also auch auf die 8 Byte gelegt, und
voila: Absolut der gleiche Fehler.
Der Fehler liegt ergo im Bootloader. Auf der Suche bin ich dann auf
Folgendes gestossen:
Im CMD_LOAD_ADDRESS steht:
1
address = (((msgBuffer[3])<<8)|(msgBuffer[4]))<<1; //convert word to byte address
Das ist es..... Die Adresse wird *2 genommen.....
Daher werden von "0*8 = 0 *2 = 0" die ersten Byte korrekt ausgelesen;
bei
"1 * 8 = 8 *2 = 16" wird also von Adresse 16 weitergelesen......
Also immer die ungeraden 8*Byte übersprungen.
Eine Änderung ist an dieser Stelle aber nicht gut ;)
Die Adresse wird auch beim Schreiben von EEPROM und FLASH benutzt. Das
funktioniert aber prima.
Mein Vorschlag wäre hier, das direkt nach dem
1
case CMD_READ_FLASH_ISP:
2
case CMD_READ_EEPROM_ISP:
3
{
die Änderung (halt nur beim Lesen) rückgängig gemacht wird:
1
address_t myAddress = address >> 1;
um dann mit "myAddress" den Lesevorgang auszuführen.
Was sagt Ihr dazu? Oder gibt es eine geschicktere Variante?
Gruß,
Heron
meine Lösung:
wenn man sich den stk500v2 Bootloader genauer ansieht, dann erkennt man,
das für das Schreiben des EEPROM der Bug als "issue 543" bereits behoben
wurde, auch wenn dort "not testet" steht, es funktioniert.
Leider wurde der Bug beim Einlesen des EEPROM nicht behoben.
letztendlich sieht meine Lösung wie folgt aus:
1
....
2
case CMD_READ_FLASH_ISP:
3
case CMD_READ_EEPROM_ISP:
4
....
5
else // Read EEPROM ***************************
6
{
7
uint16_t ii = address >> 1;
8
9
while (size)
10
{
11
*p++ = eeprom_read_byte((uint8_t*)ii);
12
address += 2; // Select next EEPROM byte
13
ii++;
14
size--;
15
}
16
}
17
...
Es ist letztlich ähnlicher Code, wie beim Schreiben des EEPROM. Auf
meinen Controllern funktioniert das Ganze nun prima.
Gruß,
Heron
Thread beobachten
Seitenaufteilung abschalten