Hallo zusammen,
Ich hab' ein Prog für die Ansteuerung eines LED-Displays an meinen
ATmega8515 geschrieben. Dieses hat allerdings noch einige Bugs, weshalb
ich es gerne Schritt für Schritt mit dem Debugger durchlaufen lassen
möchte.
Nun gibt's da aber ein Problem mit dem Stack:
Meine Routine zum Initialisieren des Stackpointers
1
ldi temp, LOW(RAMEND)
2
out SPL, temp
3
ldi temp, HIGH(RAMEND)
4
out SPH, temp
Das tut auch richtig, im Processor-Fenster wird für den Stackpointer
0x025F angezeigt. Sobald ich nun allerdings zu einem Aufruf einer
Subroutine komme, passiert Folgendes:
An der Adresse im RAM, auf die der Stackpointer zeigt, passiert nichts,
dort bleibt einfach 0000 stehen. Logischerweise geht das Prog dann
natürlich dort weiter, wo .org 0x00 steht, also ganz am Anfang. Warum
funktioniert das nicht? Hattet oder habt ihr dieses Problem auch? Ich
glaube, es funktioniert, wenn man keine Interrupts verwendet, also
keine .org-Anweisung vorkommt.
Noch etwas: Auch der normale Zugriff auf den Stack mit push und pop
funktioniert nicht richtig. Der Wert wird zwar ins RAM geschrieben und
von dort auch wieder richtig gelesen, aber beim poppen nicht mehr
gelöscht :(
Kann mir jemand helfen? Der Debugger wär' doch so praktisch!
Vielen Dank im Voraus!
PS: Bei rcall wird der Stackpointer schon verändert, er zeigt dann also
auf die Adresse 2 Byte vor dem RAMende. Nur wird dort eben nichts
reingeschrieben :(
Naja, SRAM fängt aber erst bei $60 ($100 beim 128er) an, drunter sind
schließlich noch Register und I/O gemappt. Also geht er auch $60 ($100)
Zellen weiter...
Wenn der nicht funzt, dann liegt's an Deinem Programm. Guck mal, ob in
der Subroutine "push"- und "pop"-Befehle stehen und check dann, ob
auch jeder "push" sein "pop"-Pendant hat. Gibt es Verzweigungen in
der Subroutine? Wird bei einer Verzweigung vielleicht ein notwendiges
"pop" übersprungen? Das könnte z. B. die Ursache für Dein Problem
sein.
Du kannst Deinem Bug übrigens auch einfach dadurch auf die Schliche
kommen, indem Du jeden_ _einzelnen_ _Schritt im Debugger in
"mühevoller Kleinarbeit" beobachtest. Dabei mußt Du insbesondere den
Stackpointer kontrollieren, d. h. Du mußt zu jedem Zeitpunkt darüber
Bescheid wissen, wo er hinzeigt. Du wirst dann feststellen, daß er an
irgendeinem Programmpunkt wo hinzeigt, wo er nicht hinzeigen soll. In
diesem Moment weißt Du die Stelle, wo der Bug in Deinem Programm
steckt. Probier's aus - viel Erfolg.
PS: [Ironie] Wenn mal ein selbstgeschriebenes Programm nicht das tut,
was es soll, dann liegt's stets am Compiler... ;-) [/Ironie]
Mal ne frage: soll man bei 16 Bit Angelegenheiten nicht immer erst das
High Byte schreiben? Hatte mal nen Ähnlichen Fall aber mit den Timer
Variablen.
Grüße Horst
Ja, da gibts nen paar Register, aber nicht der Stackpointer. Sonst würde
bei mir auch nix laufen. Timer ist nen Beispiel.
@Phip
Kannste vielleicht noch etwas Zeug rausrücken? Welches AVR-Studio isses
denn?
dave
Hallo,
ich misch' mich da mal kurz ein ;-) Hab kürzlich ein ähnliches
Phänomen gehabt, dass beim Rücksprung aus der Int-Routine wieder zum
Anfang des Programms gesprungen wurde. Bei mir lags daran, dass ich von
einem andren (kleineren) AVR den Code implementiert habe und ich dabei
den Stackpointer dabei vergessen hatte... Das ist bei Dir ja nicht der
Fall. Aber ich würde erstmal so als Tip geben: Überprüf nochmal, ob Du
den Debugger auch für den mega8515 eingestellt hast, vielleicht klappts
mit dem Code ja richtig, nur der Debugger ist falsch eingestellt? Hast
Du auch am Anfang des Codes die richtige Datei "included"? Nicht das
hier schon das "Ramend" falsch eingebunden wird...
ciao, Andi.
Nunja, beim Sim hab' ich das eingestellt, was ich so gefunden hab'.
Der 8515 hat ja eigentlich ein 512 Byte RAM, aber RAMEND zeigt auf
0x025F, da, wie schon gesagt, das RAM noch etwas grösser für den
IO-Bereich und so sein muss. Ich hab' das Programm schon Schritt für
Schritt durchlaufen, aber wie gesagt, an einem push oder pop kann's
nicht liegen, da schon der Aufruf der Prozedur seinen Zweck verfehlt.
Der Stackpointer wandert zwar um 2 Byte nach vorne, aber der
entsprechende Speicherplatz wird nicht verändert...
Auf'm Screenshot seht ihr das ganze Prog im Simulator mit den
Einstellungen desselben. Hier hab' ich den Prozeduraufruf schonmal
durchlaufen und wie ihr rechts im Data-Fenster seht, ist im RAM einfach
alles 0. Das einzelne F kommt von einem push in der Prozedur, das
allerdings nichts zur Sache tut.
Das Problem im Code, das ich ursprünglich gesucht hab', hab' ich
jetzt behoben, aber ein funktionierender Debugger wär' halt schon
schön.
Danke schonmal für die Hilfe!
512 Byte SRAM geht von $60 bis $25f... Was ist da falsch?????
- $00...$1f : 32 Byte Register
- $20...$5f : 64 Byte I/O-Bereich
- $60...$25f: 512 Byte SRAM
Wo ist das Problem???
...
Hi,
>an einem push oder pop kann's>nicht liegen, da schon der Aufruf der Prozedur seinen Zweck verfehlt.>Der Stackpointer wandert zwar um 2 Byte nach vorne, aber der>entsprechende Speicherplatz wird nicht verändert...
dann ist das wirklich sehr mysteriös. Trotzdem bleib ich dabei: Der
Simulator selbst ist nicht fehlerhaft, auch wenn er sich hier aufgrund
von was auch immer fehlerhaft verhält. Ich vermute, daß es an
irgendeiner "Mißkonfiguration" liegt, d. h. an irgendetwas, das Du
(unwissentlich?) falsch eingestellt hast.
Poste mal Dein Programm hier, damit ich es bei mir im Simulator laufen
lassen kann. Wenn ich den Fehler reproduzieren kann, werde ich ihm den
Garaus machen - versprochen.
Auweia...
Fangen wir mal hinten an:
- DEC setzt, sobald das Register 0 wird, das gleiche wie CPI 0, also
lass das CPI weg und setzt das DEC immer vors BRNE und feddich
- Wenn du da in dem riesen CPI Ding deine Leds ein/ausschaltest, da
nimmste nen Table, das auf einen Speicherplatz im Flash zeigt. An dem
hast du die Werte für die LEDs hinterlegt, im Tutorial hier ist sowas
angedeutet. Du lädst ind ZH:ZL den Anfang der Tabelle (WICHTIG: Adresse
mal 2 nehmen, wegen Byte/Word) und addierst dann den Wert dazu und liest
einfach mit LPM den vorher mit ".db 0b011101, 0b11011"
eingespeicherten Wert aus. Immer 2 Bytes in eine Zeile.
Kannste bitte einfach nochmal überprüfen, ob du aus Versehen den
ATMEGA85DREI5 oder nen 90er eingestellt hast... und stell nicht auf
CUSTOM, sondern hol dir das neue Studio, wenn das noch das alte ist.
dave
Wenn ich gewusst hätte, dass es ein neueres AVR-Studio gibt... Könnte da
vielleicht mal jemand den Link im Tut erneuern?
Jetzt geht's jedenfall! freu
Danke an alle, die daran beteiligt waren!
:)
Thread beobachten
Seitenaufteilung abschalten