EEPROM - Verhalten beim Beschreiben

[Jack X. (br3w3ry)]

Moin zusammen,

ATXmega256A3U @32 Mhz
Atmel Studio 7
JTAG - ICE
header avr/eeprom.h

Optimiazation steht auf "Optimize for size"


ich beschreibe meinen EEPROM mittels eeprom_write_block(&buffer... zwei 
mal hintereinander (Daten kommen über UART).

Wenn ich die Daten im Betrieb mittels eeprom_read_block(... auslese und 
ausgebe, stehen falsche Daten drin.

Als ich aber Breakpoints an eeprom_write_block&buffer... gesetzt habe um 
zu sehen, was für Daten in buffer stehen (waren die richtigen) hat die 
Ausgabe gepasst...
Also liegt es vermutlich am Beschreiben des eeproms...

Kennt jemand das Problem und die dazugehörige Lösung?


Grüße

[tja (Gast)]

lies doch mal über JTAG den EEPROM aus und überprüfe ob die stimmen - 
wenn nein, dann ist doch beim Schreiben was schief gelaufen!

[Jack X. (br3w3ry)]

Hallo,

danke für den Tipp!
Habe das überprüft und tatsächlich steht im EEPROM nach dem Schreiben 
nichts drin...

Woran könnte das liegen?
Wenn ich den EEPROM dummy mäßig beschreibe (hier ein '!') in der 
Initialisierung funktioniert das.

Wenn ich den gleichen Aufruf an der selben Stelle mache, wo der UART 
schreibt klappt es NICHT.

// dummycode

char test[10];
test[0] = '!';

eeprom_write_block (&test , (void*) 0x440, 1 );

[tja (Gast)]

hmm - komisch. Bist du da in einer ISR? Weiß zwar nicht, ob es damit 
etwas zu tun haben kann, aber es wäre zumindest ein Unterschied.

[Jack X. (br3w3ry)]

Ne gar nicht.

Wird in der main aufgerufen und ist verschachtelt in 2 Funktionen und 
einer switch case Anweisung wo dann in EEPROM geschrieben wird (im 
richtigen "case").

[tja (Gast)]

schonmal probiert in deiner Initialisierung mehrmals die 
eeprom_write_block Funktion aufzurufen? Das Schreiben in das EEPROM 
braucht eine gewisse Zeit. Ich weiß jetzt auf Anhieb nicht, ob die 
Funktion blockt. Wenn du nun mehrmals hintereinander schreibst, ohne 
Pause, dann kann es vielleicht passieren, dass Zugriffe unterdrückt 
werden.

[Oliver S. (oliverso)]

tja schrieb:
> Ich weiß jetzt auf Anhieb nicht, ob die
> Funktion blockt.

Die Doku weiß es.

Oliver

[Jack X. (br3w3ry)]

Oliver S. schrieb:
>> Ich weiß jetzt auf Anhieb nicht, ob die
>> Funktion blockt.
>
> Die Doku weiß es.

Moin zusammen,

vielen Dank für eure Hilfe.
RTFM --> AVR Libc Reference Manual --> <avr/eeprom.h>: EEPROM handling

#define eeprom_is_ready() \

Returns
1 if EEPROM is ready for a new read/write operation, 0 if not.

Man darf den EEPROM nicht hintereinander beschreiben... wenn du muss man 
mit dem Makro "eeprom_is_ready()" warten bis eine "1" geschrieben wird.
Das war der Fehler. Funktioniert jetzt einwandfrei.

http://www.atmel.com/webdoc/avrlibcreferencemanual/group__avr__eeprom.html

[Rolf M. (rmagnus)]

Jack X. schrieb:
> Man darf den EEPROM nicht hintereinander beschreiben... wenn du muss man
> mit dem Makro "eeprom_is_ready()" warten bis eine "1" geschrieben wird.
> Das war der Fehler. Funktioniert jetzt einwandfrei.

Erstaunlich. Denn in der verlinkten Doku steht auch:

All of the read/write functions first make sure the EEPROM is ready to 
be accessed. Ist ja auch logisch. Gerade bei eeprom_write_block geht das 
ja gar nicht anders. Da können ja viele Bytes geschrieben werden, also 
muss in der Funktion sowieso vor jedem Byte gewartet werden, bis es 
geschrieben ist und das nächste angenommen werden kann.