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
Gast
#5250026
lies doch mal über JTAG den EEPROM aus und überprüfe ob die stimmen - wenn nein, dann ist doch beim Schreiben was schief gelaufen!
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 );
Gast
#5250200
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.
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").
Gast
#5250213
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.
tja schrieb: > Ich weiß jetzt auf Anhieb nicht, ob die > Funktion blockt. Die Doku weiß es. Oliver
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
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.