mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 512Byte-Array in 512Byte-EEPROM ablegen


Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

der Betreff sagt eigentlich schon alles. Ich möchte ein 512Byte großes,
konstantes Array (Daten werden während der Laufzeit nicht geändert) in
einem 512Byte großen EEPROM speichern. Leider mag das mein Linker nicht
so recht. Ich erhalte folgende Fehlermeldung, welche darauf schließen
lässt, dass neben den 512Byte Nutzdaten noch irgendwelche Infos über
das Array abgespeichert werden. Wenn ich das Array um ein Element
verkleinere, funktioniert es.

*****************
Error[e16]: Segment EEPROM_I (size: 0x200 align: 0) is too long for
segment definition. At least 0x1 more bytes needed. The problem
occurred while ...
*****************

Sollte das mit den Zusatzinfos stimmen? Wie kann ich das Problem
umgehen? Hat jemand eine Idee. Das Array liegt zur Zeit im FLASH, soll
aber aus Optimierungsgründen ins nicht verwendete EERPOM. RAM kommt
selbstverständlich auch nicht in Frage.  ;o)

Ich könnte natürlich 256 einzelne Variablen ins EEPROM legen und einen
Zeiger vom FLASH aus darauf richten. Aber vielleicht kann ich mir die
Schreibarbeit auch sparen(?).

Kurzinfo über die verwendete Hard-/Software: ATMega88, IAR Compiler,
IAR Embedded Workbench.

Hoffe auf Hilfe.

Danke!

Gruß
ewigerstudent74

Autor: Kurt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sind es vielleicht 513 Bytes ?

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kurt,

nö, bin mir sicher, dass es 512 Byte sind. Die Deklaration sieht in
etwa so aus:

unsigned short __eeprom ucArr[256] = { ... Hier stehen 256 2Byte-Werte
... };

Ein "unsigned short" belegt hier 2 Byte => 2Byte x 256 = 512Byte.

Noch 'ne andere Idee?

Gruß
ewigerstudent74

Autor: Simon Küppers (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
1 Byte zu wenig? das ist komisch....

Hätte ja sein können dass das Array von 0...256 geht, dann wärns aber
514 Bytes gewesen. Also müsste der Compiler 2 Bytes zuviel melden..
kratz ?

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich kratz mit!  ;o)

Autor: Erwin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

unelegante Lösung:
Du könntest doch einfach eine kleine Schleife schreiben
die Dir die Arraywerte einzeln vom Flash ins Eeprom kopiert
und danach die Eeprom-nicht-lösch-fuse setzen...

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Erwin,

das kommt auch nicht in Frage. Würde ich in dieser Applikation eine
EEPROM-Schreibroutine verwenden, müsste ich aus Sicherheitsgründen
einen EEPROM-Handler einsetzen => Ist technisch und "finanziell"
nicht vorgesehen.

Gruß
ewigerstudent74

Autor: peter dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du weißt aber schon, daß bei Verwendung des EEPROM unbedingt das
Brownout eingeschaltet werden muß !

In früheren AVRs war der EEPROM sehr unzuverlässig und besonders die
Adresse 0x00. Kann sein, daß deshalb der Compiler erst bei Adresse 0x01
anfängt und deshalb genau ein Byte fehlt.


Peter

Autor: Steffen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
könnte es sein, das dieses Array erst ab Adresse 0x0001 beginnt ?
schau mal in das map des Linker bzw. in das HEX-File des EEPROM.

Autor: Monguz (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann sein das der erste hex wert eines arrays seine länge definiert ??
wenn so dann fehlen dir 2 bytes (2byte Len ; 2* 0-FF =256*2 =512 also
der array als hex dump hat 514 bytes) Da du weist wie gross er ist
köntest die erste zwei bytes sparen...my 2 cents

Autor: Wolle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte es nicht sein, dass das erste Byte im eingebauten EEPROM nicht
für solche Sachen nutzbar ist ?

Ich meine, sowas mal gelesen zu haben !

Autor: Michael Wilhelm (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Probier mal folgende Deklaration:
__eeprom __no_init unsigned char test[512] @ 0x00;

Meine IDE (IAR) hat compiliert und gelinkt ohne Fehler;

MW

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle,

danke für die tollen Tipps. Es war in der Tat so, dass der Linker das
Array erst ab Adresse 0x001 angelegt hatte. Mit "@ 0x0" habe ich das
Problem behoben. Atmel hatte bei ihren ersten AVRs das Problem, dass
die Adresse 0x000 des EEPROMS teilweise defekt war. Deshalb gab es
diesen Workaround von IAR.

Jetzt ist aber etwas anderes "tolles" passiert. Bei dem Array handelt
es sich ja um ein statisches Array, also ist es vorinitialisiert. Bei
einem Blick ins EEPROM musste ich aber festellen, dass da nur
Schrottwerte drin standen. Verkleinert man das Array auf 127 Werte (127
x 2Byte), dann wird korrekt initialisiert.

Was ist denn nun noch korrupt?

Gruß
ewigerstudent74

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lies Dir trotzdem im Datenblatt "Preventing EEPROM Corruption" durch.

Ich würde aber lieber den Mega168 nehmen, statt Konstanten im EEPROM
abzulegen.


Peter

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P.S.:

Es ist ein Irrtum zu glauben, die Daten im EEPROM sind sicher, wenn im
Programm gar keine Schreibroutine ist. Sie sind gleich unsicher ohne
den Brownout.


Peter

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Peter,

auf die Wahl des Controller habe ich keinen Einfluss mehr.

Aber irgendwie habe ich das nicht verstanden. Ich dachte, der Brownout
macht nur Sinn, wenn ins EEPROM geschrieben wird? Können sich die Daten
im EEPROM bei Leseoperationen, Shutdowns oder irgendwelchen
Umwelteinflüssen ändern? Das Setzen des Brownout-Fuses wäre in meiner
Applikation aber sicherlich möglich.

Gibt es noch eine Idee zum oben beschriebenen Problem (mein letzter
Thread) mit den korrupten Intial-Werten?

Gruß
ewigerstudent74

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Irgendwo im Netzteil hast Du einen dicken Elko, der sich nach dem
Abschalten ganz langsam entlädt.

Und irgendwann reicht die Spannung für die CPU nicht mehr aus, um
einwandfrei zu arbeiten und sie macht nur Unsinn.
Sie kann z.B. einen Befehl falsch dekodieren, z.B. als Schreiben des
EEPROM, obwohl ein solcher nicht im Flash steht.

Der Brownoutreset soll nun die CPU im Reset halten, wenn beim
Einschalten die VCC noch zu klein ist bzw. beim Auschalten langsam zu
klein wird.


"auf die Wahl des Controller habe ich keinen Einfluss mehr."

Der 168 ist doch ein 88, nur eben mit doppelt Flash.


Peter

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Der 168 ist doch ein 88, nur eben mit doppelt Flash.

Ja, aber der ist auch teurer. Wir reden hier von späteren Serienteilen.
Da lassen wir lieber den Herrn Softwareentwickler ein paar Stunden mehr
schaffen und nehmen dafür den 2 Cent billigern µC.   ;o)

Autor: ewigerstudent74 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich habe gerade die Lösung für das Problem mit den fehlerhaften
Initial-Werten im EEPROM gelöst. In den Release Notes des AVR-Studios
habe ich unter "Updates" folgenden Eintrag entdeckt:

"- Large EEPROM arrays/structures in UBROF object files were
incorrectly loaded."

Nach dem Einspielen des Servicepacks 3 verläuft die Initialisierung nun
korrekt.

Gruß
ewigerstudent74

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.