EEPROM ATmega32

[Umbrecht (Gast)]

Guten Tag,

leider habe ich zu meinem Problem keine direkte Lösung gefunden. Daher 
frage ich euch mal.

Seit kurzen arbeite ich mit dem internen EEPROM des ATmega32.
Hierbei habe ich mir dass verhalten mal angesehen,
speichere ich die Ziffer "A",

"eeprom_write_byte((uint8_t*)0,'A');"

wird sie nach alle 255 Bytes wiederholt, aslo 4x. Aus dem grund habe ich 
versucht in einem Speicherbereich über 255 zu schreiben. - Warum? weil 
ich später für ein Projekt den gesammten bereich benötige. -

Leider erfolglos, die Bytes bleiben unverändert. Vielleicht könnt ihr 
mir hier etwas unter die Arme greifen. ^^

PS: Sprache: C auf AVR Studio 4. ich arbeite mit "eeprom.h" definiere 
also          -   selber keine Register.

Liebe grüße
Umbrecht

[Ärgert sich (Gast)]

Und jetzt sollen wieder alle ihre kaputten Glaskugeln auspacken oder 
was.

zeig mal deinen Code wie du Daten ins EEPROM speicherst.

Wir sind doch keine hellseher!

[Umbrecht (Gast)]

#define F_CPU 8000000UL
#include <avr/io.h>
#include <avr/eeprom.h>

int main(void) {

eeprom_write_byte((uint8_t*)400,'A');

while(1) {

}}

So wie oben beschrieben, aber danke für deine aufmerksamkeit schon mal.

Statt "400" nutzte ich auch schon andere Zahlensysteme ( 0x190 ).

[Ärgert sich (Gast)]

Umbrecht schrieb:
> eeprom_write_byte((uint8_t*)400,'A');

Bist du sicher das die Parameterübergabe richtig ist?

sollte wohl eher so lauten wenn ich mich nicht irre:

eeprom_write_byte(400,'A'); Also EEprom-Adresse, Wert

[Heinz V. (heinz_v)]

Der Wert '400' passt nicht in ein unsigned 8bit integer ...

[Ärgert sich (Gast)]

Also

eeprom_write_byte( (uint8_t * ) 0x0190  ,'A');

Passt schon laut Simulator.  Der 16Bit Wert wird hier ja geCastet.

Umbrecht schrieb:
> Statt "400" nutzte ich auch schon andere Zahlensysteme ( 0x190 ).

Hier liegt der Fehler 0x190 wird interpretiert als 0x1900 und da bist 
beim Zugriff weit über dem EEPROM Bereich.

Ab  0x0400 ist schluss.

[Oliver S. (oliverso)]

Ärgert sich schrieb:
> 0x190 wird interpretiert als 0x1900

Hüstel...

Nullen vorne dran darf der Compiler sich dazu denken, so viel er will, 
aber hinten dran nicht. Und daher tut der das auch nicht.

0x0190 ist 0x000000190 ist 0x190 ist dez 400. Nix anderes.

Oliver

[Umbrecht (Gast)]

Ärgert sich schrieb:
> Ab  0x0400 ist schluss.

Habe diesen Wert mal eingetragen also 
"eeprom_write_byte((uint8_t*)0x400,'A');"
und den µC gestartet. Anschließend mit "AVR8 Burn-O-MAT V2" den EEPROM 
als RAW format auf meinen PC kopiert.

Beim Durchsuchen des files fiel mir auf, dass das 'A' an erster stelle 
in der datei steht. Liegt es dran, weil mit 1024 der bereich 
überschritten ist?

Daraufhin habe ich "eeprom_write_byte((uint8_t*)0x3FF,'A');" Probiert 
also 1023, hier habe ich wieder dass selbe problem, man findet das 'A' 
nicht, es steht nicht in der Textdatei.


Was aber auch komisch ist, wenn ich die EEPROM datei umschreibe also auf 
meine gewünschten Zeichen, kann ich es erfolgreich hochladen wenn ich 
weniger als 256 Byte bzw. Ziffern verwendet habe. Brauche ich mehr kommt 
immer ein Error, dass beim schreiben etwas schiefgelaufen ist.

Error:  avrdude.exe: verification error, first mismatch at byte 0x0011
        0xff != 0x71
        avrdude.exe: verification error; content mismatch

[Walter T. (nicolas)]

Du bist sicher, einen ATmega32 zu haben? Die Brownout-Fuses sind auch 
richtig gesetzt?

[Umbrecht (Gast)]

Walter T. schrieb:
> Du bist sicher, einen ATmega32 zu haben?

Als ich ihn bei Reichelt + 5 anderen gekauft habe stand "ATmega32" da, 
auf dem Gehäuse des Prozessors steht ATmega32, ich vermute zu 10% dass 
er es sein könnte.

Nein - spaß bei seite, er ist es sicher.


Fuses sind im Anhang, ich habe hier nichts verändert bis auf die Quarz 
einstellungen.

[Falk B. (falk)]

@ Umbrecht (Gast)

>Hierbei habe ich mir dass verhalten mal angesehen,
>speichere ich die Ziffer "A",

>"eeprom_write_byte((uint8_t*)0,'A');"

Was soll das? In C kümmert sich der COMPILER um die Adressen der 
Variablen!

>PS: Sprache: C auf AVR Studio 4. ich arbeite mit "eeprom.h" definiere
>also          -   selber keine Register.

Also mach es so wie der Rest der Welt!

https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM

[Umbrecht (Gast)]

Falk B. schrieb:
> Also mach es so wie der Rest der Welt!
>
> https://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM

ja das tutorial ist mir bekannt.

Falk B. schrieb:
> Was soll das? In C kümmert sich der COMPILER um die Adressen der
> Variablen!

k

[Walter T. (nicolas)]

Umbrecht schrieb:
> auf dem Gehäuse des Prozessors steht ATmega32, ich vermute zu 10% dass
> er es sein könnte.

Der Teufel ist ein Eichhörnchen.

Umbrecht schrieb:
> Fuses sind im Anhang

BODEN und EESAVE wären schon einmal ein guter Anfang.

Falk B. schrieb:
> Was soll das? In C kümmert sich der COMPILER um die Adressen der
> Variablen!

Für das Hardkodieren von EEPROM-Adressen kann es auch unter C gute 
Gründe geben. Z.B. um einen EEPROM-Dump aufs Display oder UART zu geben. 
Und ich finde auch nichts, was dagegen spricht, außer den Komfort, den 
die automatische Verwaltung der EEPROM-Adressen bietet.

[Umbrecht (Gast)]

Walter T. schrieb:
> BODEN und EESAVE wären schon einmal ein guter Anfang.

Warum EESAVE? Hierdurch werden alle Bytes des EEPROM bei einem neuen 
Programm upload auf 0xFF gesetzt - oder liege ich falsch?

Walter T. schrieb:
> Für das Hardkodieren von EEPROM-Adressen kann es auch unter C gute
> Gründe geben. Z.B. um einen EEPROM-Dump aufs Display oder UART zu geben.

Dass trifft es.. Mein fehler dass ich es nicht erwähnt habe - Sorry

[Peter D. (peda)]

Falk B. schrieb:
> Was soll das? In C kümmert sich der COMPILER um die Adressen der
> Variablen!

Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.
Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man 
ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.

[Karl H. (kbuchegg)]

Umbrecht schrieb:
> Guten Tag,
>
> leider habe ich zu meinem Problem keine direkte Lösung gefunden. Daher
> frage ich euch mal.
>
> Seit kurzen arbeite ich mit dem internen EEPROM des ATmega32.
> Hierbei habe ich mir dass verhalten mal angesehen,
> speichere ich die Ziffer "A",
>
> "eeprom_write_byte((uint8_t*)0,'A');"
>
> wird sie nach alle 255 Bytes wiederholt, aslo 4x.

Wie hast du das festgestellt?

[Umbrecht (Gast)]

Karl H. schrieb:
> Wie hast du das festgestellt?

Ich habe den EEPROM mittels AVR Burn-O-Mat ausgelesen (im Programm die 
funktion "Read" beim EEPROM).

In meinem Fall wird dann auf dem Desktop die datei "eeer" angelegt ohne 
endung. Sorry für den Namen aber ich war einfallslos.

Diese öffne ich mit Notepadd++ und man kann alle 1024Byte lesen. 
Gegebenfalls auch ändern und hochladen mit "Write" aber eben nur bis 
Byte 256 danach kommt der Error.

[Karl H. (kbuchegg)]

Umbrecht schrieb:

> Gegebenfalls auch ändern und hochladen mit "Write" aber eben nur bis
> Byte 256 danach kommt der Error.

Was schon mal ein Hinweis darauf ist, dass irgendetwas hardwaremässig 
nicht stimmt.
Es gibt keinen Grund, warum du beim Beschreiben des EEPROM einen Fehler 
bekommen solltest. Von daher würde ich schon mal dem, was Burn-O-Mat aus 
dem EEProm ausliest, nicht mehr über den Weg trauen.

Solange dein Brennprogramm weiss, dass es sich um einen Mega32 handelt, 
musst du 1024 Bytes fehlerfrei ins EEPROM schreiben können. Egal welche 
Werte. Solange das nicht der Fall ist, würde ich dem alles nicht über 
den Weg trauen.

[Umbrecht (Gast)]

Denkst du dann eher ich sollte einen anderen ATmega32 testen oder ganz 
weg von AVR Burno-O-Mat?

Eine Option die mir gerade einfällt, wenn ich z.b. die Adresse 500 des 
EEPROM beschreibe, anschließend auslese mit eeprom_read_byte und über 
den Uart oder LCD ausgebe. - Werde ich gleich mal ein Programm dafür 
schreiben und testen

[Joachim B. (jar)]

Karl H. schrieb:
> Solange dein Brennprogramm weiss, dass es sich um einen Mega32 handelt,
> musst du 1024 Bytes fehlerfrei ins EEPROM schreiben können.

aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher 
genannten 0x400

[Walter T. (nicolas)]

Umbrecht schrieb:
> Eine Option die mir gerade einfällt, wenn ich z.b. die Adresse 500 des
> EEPROM beschreibe, anschließend auslese mit eeprom_read_byte und über
> den Uart oder LCD ausgebe. - Werde ich gleich mal ein Programm dafür
> schreiben und testen

Wahlweise das gesamte (mit Burnomat geschriebene) EEPROM mal auslesen 
und über UART dumpen. Ist ja ein Wenigzeiler.

Umbrecht schrieb:
> Warum EESAVE? Hierdurch werden alle Bytes des EEPROM bei einem neuen
> Programm upload auf 0xFF gesetzt - oder liege ich falsch?

Neee, andersherum: Der EEPROM-Inhalt wird auch über ein Chip Erase 
hinaus aufbewahrt.

[Planlos (Gast)]

Peter D. schrieb:
> Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.
> Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man
> ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.

Genau das geht auch bei Verwaltung durch den Compiler komfortabel.

uint16_t EEMEM  beispiel = 42;

im Source.

Compiler vergibt eine Adresse im Eeprom, Makefile erzeugt passend ein 
.eep - HEX-File, avrdude - Aufruf im Makefile kann das eeprom 
automatisch beschreiben.

Klappt auch mit vorbelegten Structs, Arrays usw. im EEMEM.

%.eep: %.elf
        @echo
        @echo $(MSG_EEPROM) $@
        -$(OBJCOPY) -j .eeprom --set-section-flags=.eeprom="alloc,load" \
        --change-section-lma .eeprom=0 -O $(FORMAT) $< $@

[Umbrecht (Gast)]

Also, vom ATmega32 funktioniert alles einwandfrei, ich habe ein 'A' in 
die Adresse 0x3FF geschrieben und lese sie aus. Zusätzlich auch noch die 
Adressen 0x3FE, 0x400 um sicher zu gehen. Herauskommt dass 'A' und 2 
Werte mit 255 - was soweit richtig ist.

Was aber nun blöd ist, dass irgendwas mit dem AVR Burn-O-Mat nicht 
stimmt..

Soweit schon mal danke für die Hilfe! ^^

[spess53 (Gast)]

Hi

>aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher
>genannten 0x400

Warum? Damit landet man einfach wieder auf Adresse 0.

MfG Spess

[Karl H. (kbuchegg)]

Planlos schrieb:
> Peter D. schrieb:
>> Das betrifft nur Flash und RAM, da diese vom Linker verteilt werden.
>> Beim EEPROM nimmt man aber oftmals eine feste Zuweisung, dann kann man
>> ihn auch über ISP oder Bootloader vorbelegen bzw. auslesen.
>
> Genau das geht auch bei Verwaltung durch den Compiler komfortabel.
>
> uint16_t EEMEM  beispiel = 42;
>
> im Source.

Das löst das Problem nicht, welches Peter anspricht.

Gerade beim EEPROM will man die Adressen kontrollieren können. Ganz 
speziell will man das zb, wenn sich von einer Linkerversion zur nächsten 
die Adresszuordnung ändert, du aber einen bereits benutzten AVR mit 
intakten Daten im EEPROM auf eine neue Programm Version updaten musst 
und zwar ohne dass es beim Lesen aus dem EEPROM zu Datensalat kommt.

Und ja: das hat es schon gegeben, dass eine neuere GCC Version die 
Adressvergabe anders gelöst hat.

[Karl H. (kbuchegg)]

spess53 schrieb:
> Hi
>
>>aber nur von 0 bis 0x3ff oder 1023 , mich stören immer noch die vorher
>>genannten 0x400
>
> Warum? Damit landet man einfach wieder auf Adresse 0.

Ist die Frage, was der Burn-O-Mat mit der ungültigen Adresse macht.

Aber: im Originalposting war ja von der Adresse 0 die Rede. Die 0x400 
sind ja erst später aufgetaucht.

[Peter D. (peda)]

Umbrecht schrieb:
> Zusätzlich auch noch die
> Adressen 0x3FE, 0x400 um sicher zu gehen.

Das ist Quark, die unterscheiden sich doch im Low-Byte.
Schreibe auf 0x3FF und lies auf 0xFF, 0x1FF, 0x2FF, 0x3FF aus.

[Umbrecht (Gast)]

Da hast du natürlich recht ^^

Dass Ergebniss stimmt,  nur bei 0x3FF kommt der gespeicherte wert.

Habe den burnomat mal auf einem anderen Gerät getestet, hier habe ich 
den selben Fehler..