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.
:
Bearbeitet durch Moderator
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ß
Sorry, hatte ich übersehen: ja, -v habe ich immer mit an. Schlägt aber auch immer ab Byte 8 fehl.. Gruß, Heron
Also wenn der Vergleich fehlschlägt und Du seltsame Werte ausliest - wieso bist Du dann der Meinung, dass das Schreiben funktioniert?
:
Bearbeitet durch User
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" |
6 | |
7 | Using Port : COM3 |
8 | Using Programmer : wiring |
9 | Overriding Baud Rate : 115200 |
10 | AVR Part : ATmega2560 |
11 | Chip Erase delay : 9000 us |
12 | PAGEL : PD7 |
13 | BS2 : PA0 |
14 | RESET disposition : dedicated |
15 | RETRY pulse : SCK |
16 | serial program mode : yes |
17 | parallel program mode : yes |
18 | Timeout : 200 |
19 | StabDelay : 100 |
20 | CmdexeDelay : 25 |
21 | SyncLoops : 32 |
22 | ByteDelay : 0 |
23 | PollIndex : 3 |
24 | PollValue : 0x53 |
25 | Memory Detail : |
26 | |
27 | Block Poll Page Polled |
28 | Memory Type Mode Delay Size Indx Paged Size Size #Pages MinW MaxW ReadBack |
29 | ----------- ---- ----- ----- ---- ------ ------ ---- ------ ----- ----- --------- |
30 | eeprom 65 10 8 0 no 4096 8 0 9000 9000 0x00 0x00 |
31 | flash 65 10 256 0 yes 262144 256 1024 4500 4500 0x00 0x00 |
32 | lfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
33 | hfuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
34 | efuse 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
35 | lock 0 0 0 0 no 1 0 0 9000 9000 0x00 0x00 |
36 | calibration 0 0 0 0 no 1 0 0 0 0 0x00 0x00 |
37 | signature 0 0 0 0 no 3 0 0 0 0 0x00 0x00 |
38 | |
39 | Programmer Type : Wiring |
40 | Description : Wiring |
41 | Programmer Model: AVRISP |
42 | Hardware Version: 15 |
43 | Firmware Version Master : 2.10 |
44 | Vtarget : 0.0 V |
45 | SCK period : 0.1 us |
46 | |
47 | avrdude: AVR device initialized and ready to accept instructions |
48 | |
49 | Reading | ################################################## | 100% 0.05s |
50 | |
51 | avrdude: Device signature = 0x1e9801 (probably m2560) |
52 | avrdude: safemode: hfuse reads as D8 |
53 | avrdude: safemode: efuse reads as FD |
54 | avrdude: reading eeprom memory: |
55 | |
56 | Reading | ################################################## | 100% 10.47s |
57 | |
58 | avrdude: writing output file "eetest.eep" |
59 | |
60 | avrdude: safemode: hfuse reads as D8 |
61 | avrdude: safemode: efuse reads as FD |
62 | avrdude: safemode: Fuses OK (E:FD, H:D8, L:FF) |
63 | |
64 | avrdude done. Thank you. |
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 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.