Forum: Mikrocontroller und Digitale Elektronik EEPROM - Atmega stürzt ab


von Bernd (Gast)


Angehängte Dateien:

Lesenswert?

Hallo,

ich kämpfe derzeit mit der EEPROM Programmierung mit dem ATmega 328p. 
Leider funktioniert das noch nicht wie gewünscht und ich beobachte ein 
recht ungewöhnliches Phänomen.
Ich benutze die vorgefertigte <avr/eeprom.h> library, um den EEPROM 
anzusprechen.

Im angehängten Beispiel möchte ich einfach nur eine Zahl an den 
Speicherort 8 ins EEPROM speichern. Doch nach der Zeile "EEPROM 
beschreiben" stürzt der ATmega ab und das Programm beginnt von vorne.

Hat jemand von euch eine Idee, woran das liegen könnte?
Ich würde mich über Ideen aus allen Richtungen freuen.

Vielen Dank!
Bernd

von M. K. (sylaina)


Lesenswert?

Du schreibst
1
eeprom_write_byte((uint8_t*)8, 4);
ist das denn richtig wenn du an Adress 8 schreiben willst?

: Bearbeitet durch User
von Bernd (Gast)


Lesenswert?

Danke für die Antwort.

Ich hätte schon gedacht, dass ich auf diese Weise Daten ins 
Adressregister 8 schreibe. Liege ich da falsch?

Ich habe auch schon andere Adressen ausprobiert, was leider ebenfalls 
diesen komischen Absturz auslöste.

von M. K. (sylaina)


Lesenswert?

Bernd schrieb:
> Ich hätte schon gedacht, dass ich auf diese Weise Daten ins
> Adressregister 8 schreibe. Liege ich da falsch?

Das weiß ich grade aktuell nicht, ich fragte nur eben weil du den 
Absturz auf diesen Codeteil schon eingeschränkt hast. Das lässt 
vermuten, dass der Aufruf falsch ist. Ich kann erst heute abend daheim 
schaun. Jetzt wo ich allerdings in Google mal geschaut hatte: Es schaut 
erstmal richtig aus. Wie schaut deine Beschaltung aus? Das EEPROM, so 
versteh ich grad das Datenblatt, kann beim Beschreiben empfindlich 
reagieren wenn Vcc nicht stabil ist. Hast du das mal überwacht bei der 
Programmausführung?

von Joachim B. (jar)


Lesenswert?

M. K. schrieb:
> Das EEPROM, so
> versteh ich grad das Datenblatt, kann beim Beschreiben empfindlich
> reagieren wenn Vcc nicht stabil ist.

war auch mein Gedanke, evtl. fehlt der Kondensator an VCC oder es gibt 
ein Problem mit seiner Stromversorgung.

von Helmut L. (helmi1)


Lesenswert?

Brownout richtig gesetzt?
Watchdog eventuell eingeschaltet?

von Ralf G. (ralg)


Lesenswert?

Bernd schrieb:
> Doch nach der Zeile "EEPROM
> beschreiben" stürzt der ATmega ab und das Programm beginnt von vorne.

Nach der Zeile? Woran siehst du das? Die LCD-Routinen laufen korrekt?
Testweise würde ich mal nur 'ne LED nach jedem Schritt toggeln.

von Taktluhser (Gast)


Lesenswert?

Bernd schrieb:
> Hat jemand von euch eine Idee, woran das liegen könnte?

Dein Aufbau ist scheisse.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Am besten deklarierst du deine EEPROM Zelle, so das der Compiler das 
auch versteht:
1
// optional with a preset value for the *.eep File
2
uint8_t ee_myCell __attribute__((section(".eeprom"))) = 20;
3
// Variable aus dem EEPROM zum benutzen im Programm
4
uint8_t myWorkByte;
5
6
// lesen:
7
myWorkByte = eeprom_read_byte(&ee_myCell);
8
// schreiben
9
eeprom_busy_wait();
10
eeprom_write_byte(&ee_myCell,myWorkByte);
11
//
Das ganze Adresskrams überlässt du so dem Compiler.
Die 20, die da oben steht, wäre eine Vorbesetzung der EEPROM Zelle und 
landet beim Kompilieren im *.eep deines Projektes. Damit kann man den 
EEPROM vorprogrammieren.

Taktluhser schrieb:
> Dein Aufbau ist scheisse.

Ist natürlich Blödsinn, sonst würde der MC gar nicht so weit kommen.

: Bearbeitet durch User
von Taktluhser (Gast)


Lesenswert?

Matthias S. schrieb:
> Ist natürlich Blödsinn,

Ich würde mich da gerne (von einem Anblick) überraschen lassen.
Was ich hier schon alles zu sehen bekommen habe .... meist
trauen sich die Leute ihre Werke ja gar nicht herzeigen.

von Bernd (Gast)


Angehängte Dateien:

Lesenswert?

Hallo zusammen,

sorry für die späte Rückmeldung. Ich hatte erst heute Zeit eure Tipps 
auszuprobieren.
Vielen Dank für die vielen Antworten.

Ich habe es jetzt herbekommen zumindest ein Byte erfolgreich ins EEPROM 
zu speichern.

Helmut L. schrieb:
> Brownout richtig gesetzt?
> Watchdog eventuell eingeschaltet?
Es lag anscheinend wirklich der falsch gesetzte Brownout. Zumindest habe 
ich den Brownout jetzt von disabled auf 1,8V gestellt.


Matthias S. schrieb:
> Am besten deklarierst du deine EEPROM Zelle, so das der Compiler
> das
> auch versteht:// optional with a preset value for the *.eep File
> uint8_t ee_myCell __attribute__((section(".eeprom"))) = 20;
> // Variable aus dem EEPROM zum benutzen im Programm
> uint8_t myWorkByte;

Vielen Dank für den Tipp. So sieht das ganze gleich viel professioneller 
aus.

Leider funktioniert der EEPROM immernoch nicht wie erwünscht, denn wenn 
ich gleich 16 Werte auf einmal reinschreiben möchte, kommt es zu einem 
ziemlich seltsamen verhalten.
Der Hintergrund liegt darin, dass ich eine AES Codierung für das RFM69 
Funkmodul im EEPROM abspeichern möchte.
Die einfache Speicherroutine 16x je ein Byte habe ich im Anhang 
angefügt. Auch das LCD Display nach dem Ausführen der Routine.

Da auch die Vermutung im Raum stand, der ATmega wäre falsch verschaltet, 
hänge ich noch einen Teil des Schaltplans an. Vielleicht liegt es ja 
wirklich an der Beschaltung.

Habt ihr eine Idee wie es zu solch einem Verhalten kommen kann?

Beste Grüße
Bernd

von Taktluhser (Gast)


Lesenswert?

Bernd schrieb:
> Da auch die Vermutung im Raum stand, der ATmega wäre falsch
> verschaltet, ....

Bernd schrieb:
> Habt ihr eine Idee wie es zu solch einem Verhalten kommen kann?

Da steht immer noch die Vermutung im Raum dass dein
Aufbau sch... ist äähhh nichts taugt, auch wenn du das
nicht hören willst da du ja alles so perfekt gemacht hast.
Dazu gehört auch die Art der Spannungsversorgung ...

von Draco (Gast)


Lesenswert?

Was soll da an der Spannungsversorgung sch... äääähhh nichts taugen? Sie 
sieht doch gut aus? Irgendwelche doofen Kommentare ablasen ohne 
irgendwelche Hintergrunderklärungen sind schei... ähhhhh scheiße!

von Taktluhser (Gast)


Lesenswert?

Draco schrieb:
> Sie sieht doch gut aus?

Ach so? Du hast den Aufbau schon gesehen? Ja dannnnnnn....

von Draco (Gast)


Lesenswert?

Taktluhser schrieb:
> Ach so? Du hast den Aufbau schon gesehen? Ja dannnnnnn....

Ja laut Schaltplan sieht er gut aus?! Ich verstehe dein Problem gerade 
nicht?! Willst du jetzt nen Bild von der Platine / Breadboard haben? 
Schwachsinn bei der Fehlerbeschreibung, aber Hauptsache was dazu 
gelabert. Nimm dir dein Sonntagskaffee, dein Plätzchen und gut ist. Dazu 
mal ganz ab: Sollte der Aufbau an sich Probleme mitbringen wäre 
spätestens nach der Disp. Init Schluss.

von M. K. (sylaina)


Lesenswert?

Bernd schrieb:
> Es lag anscheinend wirklich der falsch gesetzte Brownout. Zumindest habe
> ich den Brownout jetzt von disabled auf 1,8V gestellt.

Dann lag es mit Sicherheit nicht am Brownout wenn er vorher eh 
abgeschaltet war.

Bernd schrieb:
> Da auch die Vermutung im Raum stand, der ATmega wäre falsch verschaltet,
> hänge ich noch einen Teil des Schaltplans an. Vielleicht liegt es ja
> wirklich an der Beschaltung.

1. Der Widerstand R6 ist falsch
2. Zwischen AVcc und Vcc gehört eine Iduktivität (war L1 dafür 
eigentlich gedacht?)
3. Das Widerstandsverhältnis R7/R8 passt nicht ganz (liefe bei 12V auf 
3.367V hinaus)
4. ARef gehört keinesfalls mit AVcc oder Vcc verbunden (Im Falle eines 
Falles macht man das in der Software)! Das kann im Worst Case ein böser 
Kurzschluss werden.
5. Wie stabil sind die 3.3V?

Das Beschreiben des EEPROM erfordert Energie, das kann gff. Vcc 
einbrechen lassen was der Schreibvorgang nicht wirklich mag.
Draco schrieb:
> Nimm dir dein Sonntagskaffee, dein Plätzchen und gut ist

Das hab ich heute morgen schon :D

: Bearbeitet durch User
von BlaBla (Gast)


Lesenswert?

Viel zu zart formuliert. Der Troll soll sich den Finger in den Ar... 
schieben.

von Taktluhser (Gast)


Lesenswert?

M. K. schrieb:
> Das Beschreiben des EEPROM erfordert Energie,

"Fachleute" schreiben dazu:

Matthias S. schrieb:
> Ist natürlich Blödsinn, sonst würde der MC gar nicht so weit kommen.

Draco schrieb:
> Sollte der Aufbau an sich Probleme mitbringen wäre
> spätestens nach der Disp. Init Schluss.

von Lutz (Gast)


Lesenswert?

Wie schon geschrieben wurde: Die Induktivität gehört dort keinesfalls 
hin, sondern vor ARef. Jede plötzliche Stromerhöhung wird (abhängig von 
der Stromstärkenänderung) so zu einer Versorgungsspannungserniedrigung 
führen. Nimm sie (sowieso) raus und/oder schalte mal 100 µF parallel zu 
C14, dann wirst du sehen...

Das ganze Gedöns an RESET soll genau was bewirken? LED leuchtet 
sichtbar, wenn du den Taster ein lange Zeit gedrückt hälst?

Natürlich kann man AVCC, ARef und VCC verbinden.

von BlaBla (Gast)


Lesenswert?

Ich würde auch R6 entfernen und überbrücken.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Lutz schrieb:
> Die Induktivität gehört dort keinesfalls
> hin, sondern vor ARef.

So, das macht die Verwirrung nun wirklich komplett.
Also, nochmal:
* AREF an einen 100nF, der gegen Masse geht. AREF im Programm auf Vcc 
als Referenz setzen.
* AVCC über LC Filter (z.B. 100µH, 100nF) und ohne Widerstand mit VCC 
verbinden.
* Alle VCC des Gehäuses miteinander verbinden.
* Alle GND des Gehäuses miteinander verbinden.
* VCC mit 100nF dicht am Gehäuse gegen GND abblocken als Reservoir.

: Bearbeitet durch User
von Bernd (Gast)


Lesenswert?

Ich habe heute Abend gleich eure Ideen bei meiner Schaltung angewandt.

BlaBla schrieb:
> Ich würde auch R6 entfernen und überbrücken.

Das mit den 100 Ohm habe ich schon öfter gesehen. Der soll zusammen mit 
dem Kondensator als Tiefpassfilter wirken.
Versuchsweise habe ich ihn trotzdem mal Überbrückt.

Matthias S. schrieb:
> Lutz schrieb:
>> Die Induktivität gehört dort keinesfalls
>> hin, sondern vor ARef.
>
> So, das macht die Verwirrung nun wirklich komplett.
> Also, nochmal:
> * AREF an einen 100nF, der gegen Masse geht. AREF im Programm auf Vcc
> als Referenz setzen.
> * AVCC über LC Filter (z.B. 100µH, 100nF) und ohne Widerstand mit VCC
> verbinden.
> * Alle VCC des Gehäuses miteinander verbinden.
> * Alle GND des Gehäuses miteinander verbinden.
> * VCC mit 100nF dicht am Gehäuse gegen GND abblocken als Reservoir.

Auch die Induktivität habe ich vorsichtshalber überbrückt.
Die Versorgungsspannung selbst sieht auf dem Oszi relativ sauber aus. Es 
kommt auch während des Schreibens des EEPROMS nicht zu Einbrüchen.
Bezüglich des letzten Punkts: Ich habe eine Alu-Platte mit den 
Bedienelementen. Heißt das, dass es sinnvoll ist einen 100nF Kondensator 
zwischen Alu-Platte und Vcc zu hängen? Was bringt das für Vorteile?

Was mich ziemlich wundert: Die Baugruppen für das Funkmodul, der ADC, 
LCD, etc. funktioniert wunderbar. Lediglich der EEPROM macht Probleme.

Meint ihr könnte es eventuell auch an den Fusebytes liegen? Ich verstehe 
auch nicht, warum es nach Umstellung der Brown-out Fusebits teilweise 
funktionierte.
Falls sich jemand damit auskennt. Derzeit sind die Fusebits bei:
#AVRDUDE_FLAGS += -U lfuse:w:0xEC:m
#AVRDUDE_FLAGS += -U hfuse:w:0xD1:m
#AVRDUDE_FLAGS += -U efuse:w:0x06:m

Ich habe irgendwo noch eine andere ATmega Testschaltung. Vielleicht 
werde ich morgen damit mit einem anderen Chip Versuche durchführen. 
Eventuell ist das EEPROM ja wirklich hinüber.

Vielen Dank für eure Ratschläge!

Schöne Grüße
Bernd

von Peter D. (peda)


Lesenswert?

Sag doch einfach mal, welche AVR-GCC Version Du benutzt.
Und benutze die Optimierung -Os.

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Lesenswert?

Ab und zu hatte ich Anomalien beim EEPROM mit der Adresse 0 und vermeide 
sie seitdem. Das kann durch Einfügen eines Dummy Bytes erreicht werden, 
das ganz am Anfang des EEPROM Segments liegt.
Evtl. hilft es auch, nach einem missglückten Schreibversuch den Inhalt 
des EEPROM mal mit dem Programmer auszulesen und anzuschauen.

: Bearbeitet durch User
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.