Hallo, weiss jemand, ob es Simulationsprobleme gibt, wenn im Code auf EEPROM zugegriffen wird ? Zu EEPROM speichern: Folgender Code: ..... cli code_speichern1: ;Beschreiben EEPROM ldi r17,3 ldi r18,5 ;zu speicherndes Byte ... out eedr,r18 ;... in EEPROM-Datenregister out eear,r17 ;Adresse in EEPROM-Adressregister sbi eecr,eewe ;... setzen code_speichern2: sbic eecr,eewe ;wenn eewe-Bit gesetzt ... rjmp code_speichern2 ;... warten .... Problem: Beim Schreiben EEPROM hängt sich Programm auf, weil das Bit in eecr nicht rückgesetzt wird. Zu EEPROM lesen: ... clr r17 code_ausw2: out eear,r18 ;Adresse in EEPROM-Adressregister sbi eecr,eere ; sbic eecr,eere ;wenn eere-Bit gesetzt ... rjmp code_ausw2 ;... warten in r17,eedr ;Byte aus EEPROM auslesen ... Folgendes Problem: Obwohl ich den EEPROM initialisiert habe mit .cseg .org 0x00 ;initialisierewn EEPROM eeNULL0: .DW 0x3F03,0x6D67 und so weiter kommen beim Lesen andere Werte raus. Anmerkung: Lt. Atmel könnte auf Abfrage eere verzichtet werden; geht aber trotzdem im Simulator nicht. Besten Dank im Voraus
Das Problem biem Lesen ist eigentlich einfach. Der Simulator kennt Deine *.eep nicht und will sie auch gar nicht kennen. Um aber vernünftige Werte bei der Simulation aus dem EEPROM lesen zu können, musst Du zu Begin der Simulation diese *.eep-Datei in den Speicherbereich für den EEPROM hochladen. Also Simulation starten (ging früher mal mit F5 :( ) und danach über Debug->Up/Download Memories Deine eep-Datei "Load from File" laden. Jörg
Hallo Jörg, vielen Dank. Damit ist wenigstens das EEPROM-Leseproblem gelöst. Aber kann ich Deiner Antwort entnehmen, dass das S c h r e i b e n in den EEPROM per Code beim Simulator nicht funktioniert ? Er bleobt ja immer an der Abfrage des EEWE-Bits im Register EECR hängen, da dieses Bit vom Simulator als Quittung nach erfolgreichem Schreiben rückgesetzt werden sollte, dies aber nicht tut. Gruss Günter
Stimmt, ich habe es gerade mal schnell selbst im aktuellen AVR-Studio getestet. Nach dem 1. Schreibzyklus wird das EEWE offensichtlich vom Simulator nicht wieder zurückgesetzt, auch nach langer Wartezeit (der Schreibzyklus dauert ja ca. 2,5-4ms beim 1200er). Möglicherweise ist das aber dem etwas anderen Algorithmus des 1200er EEPROMs geschuldet. Ich kann mich nicht entsinnen, bei anderen AVRs auf solche Problem gestoßen zu sein, also vermutlich ein spezielles Problem der Simulation beim AT90S1200:(. Vielleicht steht ja etwas dazu in den Fehlerbeschreibungen des AVRStudios? Jörg
Hallo, nochmals vielen Dank für die Unterstützung. Wenigstens weiss ich nun, dass das Problem nicht bei mir lag. Eine Fehlerbeschreibung habe ich übrigens bei atmel nicht gefunden. Gruss Günter
Ohne externen Unterspannungs-Reset-IC wirst du am EEPROM aber keine Freude haben, dann ist er sehr vergeßlich. Peter
@Peter Dannegger
>>Ohne externen Unterspannungs-Reset-IC wirst du am EEPROM aber keine
Freude haben, dann ist er sehr vergeßlich.
Und wie simuliert man den?
Sven
"Und wie simuliert man den?" Du bist ein Scherzkeks ! Hardwarefehler simuliert man nicht sondern beseitigt sie. Beim AT90S1200 wird Atmel das aber definitiv nicht mehr tun, sondern auf den ATTiny2313 als Nachfolger verweisen. Und bei dem muß man dann eben den Brownout-Reset einschalten, wenn man den EEPROM nutzen will. Peter
Nur damit ich das richtig verstehe. Wenn ich den EEPROM nur lesend nutze (ich lade die Daten beim programmieren des AT90S1200) ist doch ein externer Unterspannungs-Reset nicht nötig ? Günter
"Wenn ich den EEPROM nur lesend nutze (ich lade die Daten beim programmieren des AT90S1200) ist doch ein externer Unterspannungs-Reset nicht nötig ?" Lach lach, schön wärs. Ich hatte im EEPROM Texte fürs LCD abgelegt, da der ja kein LPM kann. Es war (leider gar nicht) lustig, wie nach jedem Einschalten mehr und mehr Zeichen unleserlich wurden. Peter
Hallo, kann mir mal jemand diese Problematik erklären? Wodurch kommt diese Unterspannung, schlechte Stromversorgung oder schwingt der Regler am Anfang etwas? Man kann den AVR ja so programmieren das es erst nach 64mSek. losgeht bzw. diese Zeit durch ein RC Glied an VCC und GND verlängern. Man könnte aber auch einen Schleife an den Anfang des Progs setzten um erst nach 1Sek. das eigentliche Prog zu starten.
Ich versthe das auch nicht ganz. Die einzige Erklärung für ein Unterspannungs-Reset-IC ist die, dass das Teil auch beim Abschalten der Spannung sein EEPROM-Gedächtnis verlieren kann. In diesem Fall helfen weder ein RC-Glied noch eine Programmschleife ? Günter
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 Unterspannungsreset-IC soll nun die CPU im Reset halten, wenn beim Einschalten die VCC noch zu klein ist bzw. beim Auschalten langsam zu klein wird. Peter
Hallo, jetztz ists mir klar. Kann es passieren das die I/O Pins sich auch undefiniert ändern? Ich verwende nämlich externes EEPROM oder betrifft das nur den internen?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.