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
Du schreibst
1 | eeprom_write_byte((uint8_t*)8, 4); |
ist das denn richtig wenn du an Adress 8 schreiben willst?
:
Bearbeitet durch User
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.
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?
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.
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.
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
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.
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
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 ...
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!
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.
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
Viel zu zart formuliert. Der Troll soll sich den Finger in den Ar... schieben.
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.
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.
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
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.