Eeprom Probleme beim Arduino-Uno Board

[Josef K. (zumlin)]

Hi,

ich versuche jetzt schon einige Zeit auf meinem Arudino-Uno Board 
(atmega328P) ein kleines Programm zum Beschreiben des Eeproms zum Laufen 
zu bekommen, aber leider ohne Erfolg.

Eigentlich lege ich nur ein Array im Eeprom an und flashe das dann mit:

uint8_t eeData[]  EEMEM = {[2] = 0x04, [3] = 0x00};

wird zu folgendem im eep-File

:0400000000000400F8

:00000001FF

Flashe ich das nun, so lese ich mittels avrdude das auch wieder aus 
(siehe Bild eeprom_01). Wundern tut mich dabei, dass der Rest des 
Speichers nicht einheitlich etwa mit "FF" beschrieben ist, so wie ich 
das von meinem atmega644 kenne, sondern teils mit "08" und teils mit 
irgendwelchem Kauderwelsch, ohne dass ich jemals was im Eeprom gemacht 
habe.
Daraufhin wollte ich das Eeprom ablöschen, jedoch ohne Erfolg. Da war 
mir klar, dass EESAVE evtl. nicht passen könnte. Leider kann ich aber 
weder über die GUI in Eclipse noch über die Konsole mit avrdude die 
Fuses auslesen. In der Konsole bekomme ich sowohl für lfuse als auch 
hfuse nur

:0100000000FF
:00000001FF

War mir dann auch egal, ich lösche einfach das Eerpom "per Hand" in 
meinem Code ab.
Nun funktioniert das aber auch nicht. Jeder Schreibbefehl führt nur 
dazu, dass wieder Kauderwelsch beliebiger Größe am falschen Ort im 
Eeprom erzeugt wird. Beispielsweise bewirkt folgender Befehl, was im 
Bild eeprom_02 steht:

eeprom_write_byte((uint8_t*)0x06, (uint8_t)0xAF);

Schön längsam bin ich ratlos. Warum nur funktioniert das alles nicht???


Ich bin schon am überlegen, ob da was mit meiner avr-libc nicht passt. 
Ich habe da vor Uhrzeiten mal was gemacht, um mir die Speicherbelegung 
in Prozent anzeigen zu lassen. Scheint aber alles auf dem neusten Stand 
zu sein, oder?
avr-libc   1:1.6.7-1ubuntu2
gcc-avr    1:4.3.4-1

[Krapao (Gast)]

Sieht für mich nach einem Bedienfehler beim Flashen aus. Leider gibt es 
keine Angaben wie du Flashen tust, also wie die Kommandozeile (von 
AVRDUDE?) aussieht. Daher das Ratespiel und die Möglichkeit mich zu 
blamieren.

Kann es sein, dass du nicht die Datei mit dem EEPROM-Inhalt flashen tust 
sondern eine Programmdatei? Ich frage nur so blöd, weil du nur einen 
Screenshot hast. Mit einer Hex-Datei im anhang hätte ich die Hexdatei im 
AVR-Studio disassembliert und bei falscher Vermutung geschwiegen :)

[Josef K. (zumlin)]

Krapao schrieb:
> Sieht für mich nach einem Bedienfehler beim Flashen aus. Leider gibt es
> keine Angaben wie du Flashen tust, also wie die Kommandozeile (von
> AVRDUDE?) aussieht. Daher das Ratespiel und die Möglichkeit mich zu
> blamieren.
>
> Kann es sein, dass du nicht die Datei mit dem EEPROM-Inhalt flashen tust
> sondern eine Programmdatei? Ich frage nur so blöd, weil du nur einen
> Screenshot hast. Mit einer Hex-Datei im anhang hätte ich die Hexdatei im
> AVR-Studio disassembliert und bei falscher Vermutung geschwiegen :)

Also ins Eeprom flashe ich die eep Datei. Deren Inhalt habe ich auch 
schon erwähnt.
Flashen tue ich - und auch Eclipse - mit folgendem Befehl:

Launching /usr/bin/avrdude -pm328p -cstk500v1 -P/dev/ttyACM0 -b115200 -F -Ueeprom:w:Client_C.eep:a 
Output:

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.03s

avrdude: Device signature = 0x000000
avrdude: Yikes!  Invalid device signature.
avrdude: Expected signature for ATMEGA328P is 1E 95 0F
avrdude: reading input file "Client_C.eep"
avrdude: input file Client_C.eep auto detected as Intel Hex
avrdude: writing eeprom (4 bytes):

Writing | ################################################## | 100% 0.03s

avrdude: 4 bytes of eeprom written
avrdude: verifying eeprom memory against Client_C.eep:
avrdude: load data eeprom data from input file Client_C.eep:
avrdude: input file Client_C.eep auto detected as Intel Hex
avrdude: input file Client_C.eep contains 4 bytes
avrdude: reading on-chip eeprom data:

Reading | ################################################## | 100% 0.03s

avrdude: verifying ...
avrdude: 4 bytes of eeprom verified

avrdude done.  Thank you.

avrdude finished

Die Datei mit dem Eeprom Inhalt habe ich mal als Anhang beigepackt, wäre 
aber echt erstaunt, wenn man daraus schlauer wird. Was würdest du 
erwarten? Assemblerbefehle, die man gegen die Befehle in der Hex-Datei 
fürs Flash vergleicht? Soll ich die auch posten?
Hab mal die out.eeprom gegen die Client_C.hex in Diffuse vergleichen 
lassen, aber leider ohne Erfolg.

[Krapao (Gast)]

> avrdude: Device signature = 0x000000
> avrdude: Yikes!  Invalid device signature.
> avrdude: Expected signature for ATMEGA328P is 1E 95 0F

Liest sich nicht gut. AVRDUDE warnt dich, dass Du versuchst einen µC 
zu flashen, der nicht richtig erkannt wird.

Mit -F

> Launching /usr/bin/avrdude -pm328p -cstk500v1 -P/dev/ttyACM0 -b115200 -F
> -Ueeprom:w:Client_C.eep:a

zwingst du AVRDUDE trotz Fehlermeldung weiter zu machen. Dass dabei 
allerlei Unglücke passieren können, ist für mich klar.

Versuche als erstes die Kommunikation zum µC in Ordnung zu bringen! 
Vorher ist jedes Flashen und jedes Schreiben von AVR Fuses Lotto.

Wenn du den Arduino Bootloader benutzt, ist es klar, dass du mit AVRDUDE 
keine AVR Fuses lesen/schreiben kannst. Es gibt aber einen Weg die 
Fuses aus dem Anwendungsprogramm heraus zu lesen: 
http://www.mikrocontroller.net/articles/AVR_Fuses#Tipps_.2B_Tricks

Dein ausgelesenes EEPROM enthält einen Teil Schrott und einen Teil 
Programmcode.

Um dem weiter auf den Grund zu gehen, müsste man

1/ den Inhalt von Client_C.eep kennen, um zu sehen ob diese Datei den 
Programmcode in EEPROM schafft

2/ dein Programm kennen, um zu sehen, ob das Schrott und ggf. durch 
einen Bufferoverflow Programmcode ins EEPROM schafft.

> War mir dann auch egal, ich lösche einfach das Eerpom "per Hand" in
> meinem Code ab.
> Nun funktioniert das aber auch nicht. Jeder Schreibbefehl führt nur
> dazu, dass wieder Kauderwelsch beliebiger Größe am falschen Ort im
> Eeprom erzeugt wird. Beispielsweise bewirkt folgender Befehl, was im
> Bild eeprom_02 steht:
>
> eeprom_write_byte((uint8_t*)0x06, (uint8_t)0xAF);

Den Quellpufferpointer auf eine wilde Adresse 0x06 zu setzen, sieht für 
mich schon superfischig aus. Abgesehen von der Länge

[Krapao (Gast)]

> Den Quellpufferpointer auf eine wilde Adresse 0x06 zu setzen, sieht für
> mich schon superfischig aus. Abgesehen von der Länge

Stop, da habe ich mich geirrt und write_byte mit write_block 
verwechselt.

[Josef K. (zumlin)]

> 1/ den Inhalt von Client_C.eep kennen, um zu sehen ob diese Datei den
> Programmcode in EEPROM schafft
Wie schon erwähnt, darin steht nur folgendes:

:0400000000000400F8
:00000001FF

Und dass schafft's auch ins ins Eeprom.

> Versuche als erstes die Kommunikation zum µC in Ordnung zu bringen!
> Vorher ist jedes Flashen und jedes Schreiben von AVR Fuses Lotto.
Die Kommunikation schien mir immer in Ordung. Ich arbeite jetzt mit dem 
Arduino Uno schon seit einem halben Jahr ohne Probleme. Ich nutze -F nur 
deshalb, weil ich nicht die "slightly modified version of avrdude" 
nutzen wollte und einfach mal ausschließe, dass ich einen falschen 
Controllertyp auswähle. http://arduino.cc/en/Guide/Troubleshooting#toc23
Aber anscheinend verträgt sich der Bootloader auch an anderen Ecken 
nicht so, wie ich das dachte, mit dem originalen avrdude, als an dem 
Signature-Check.

Ich probiere das Ganze mal über ICSP und schau, wie es sich da 
verhält...

[Josef K. (zumlin)]

Josef Kkk schrieb:
> Ich probiere das Ganze mal über ICSP und schau, wie es sich da
> verhält...

...und siehe da, es funktioniert alles wie gewollt.