Assembler-Problem

[Matthias B. (matthias882)]

Hi!
Hab ein großes Problem und kanns mir nicht erklären...
Ich schreibe mit "sts" einen wert in den SRAM, aber er kommt dort
nicht an. Wenn ich mir den code disassembled ansehe, kommt das dabei
raus.
2x der gleiche Befehl nacheinander, aber einmal steht die Adresse im
SRAM auf 0x0000 und das andere mal auf dem richtigen Wert. WARUM???
müsste doch eigentlich alle beide male auf 0x04AD stehen:

Wer kann mir helfen?
MfG Matthias

857:            sts FAT_SECTOR, cluster_H
+0000069A:   92F00000    STS     0x0000,R15       Store direct to data
space
858:            sts FAT_SECTOR, cluster_H
+0000069C:   92F004AD    STS     0x04AD,R15       Store direct to data
space

[Läubi (Gast)]

Sorry aber ich versteh nur Bahnhof...
hast du den Code jezt selbst geschrieben oder dissasembled?
Und was willst du erreichen udn was "geht nicht"

[Rolf Magnus (Gast)]

> Hab ein großes Problem und kanns mir nicht erklären...

Du hast es leider auch nicht geschafft, es uns zu erklären. (SCNR)

> Ich schreibe mit "sts" einen wert in den SRAM,

Also in Assembler? Um welche Architektur geht es?

> aber er kommt dort nicht an.

Woher weißt du das?

> Wenn ich mir den code disassembled ansehe, kommt das dabei
> raus.

Also fügt irgendwas zusätzliche Befehle ein?
Mir kommt das alles sehr mysteriös vor. Vielleicht beschreibst du's
nochmal etwas genauer.

[Matthias B. (matthias882)]

Also nochmal im detail:
die ganze sache ist von mir selbst und in assembler geschrieben.
bei der ganzen sache geht es um das auslesen eines fat16 sectors von
einer sd-karte. das ganze hat auch schon funktioniert. nur eben seit
neusten nicht mehr.

ich lege im sram ab, welcher sector der fat gelesen werden soll.
dieser steht in "cluster_H" (r15).
das sram byte ist als "FAT_SECTOR" definiert.

und zwar mit "sts FAT_SECTOR, cluster_H".
nehmen wir mal an, der wert wäre 0x04.

im unterprogramm zum lesen der fat lade ich den wert dann wieder in ein
register "temp1"

lds temp1, FAT_SECTOR

und jetzt kommt das mysteriöse.

das unterprogramm arbeitet, als wenn in register temp1 der wert 0x00
stehen würde.
füge ich in das up allerdings direkt nach dem laden des wertes eine
programmzeile ein die mir den wert von temp1 auf meinem display ausgibt
dann bekomme ich 0x04 angezeigt.
trotzdem arbeitet das up so, als wenn in temp1 0x00 stehen würde.

wenn ich allerdings nach dem befehl
lds temp1, FAT_SECTOR
den wert 0x04 mit
ldi temp1, 0x04
quasi per hand in das register lade, dann arbeitet das unterprogramm
dementsprechend.
aber nur so, obwohl der wert laut displayanzeige schon genauso im
register gestanden hat.
deshalb habe ich mir die ganze sache mal in der disassembler-ansicht
angesehen.
dort habe ich festgestellt, daß die adresse des sts befehl gar nich
stimmt. sie lautet dort 0x0000, obwohl "FAT_SECTOR" auf 0x04AD
definiert ist.
857:            sts FAT_SECTOR, cluster_H
+0000069A:   92F00000    STS     0x0000,R15       Store direct to data

und das ganz tolle ist, wenn ich den befehl
"sts FAT_SECTOR, cluster_H"
2x nacheinander ausführe dann will es den wert wohl einmal nach 0x0000
schreiben, und einmal auf die richtige adresse.
857:            sts FAT_SECTOR, cluster_H
+0000069A:   92F00000    STS     0x0000,R15       Store direct to data
space
858:            sts FAT_SECTOR, cluster_H
+0000069C:   92F004AD    STS     0x04AD,R15       Store direct to data
space

aber warum?????

ich benutze das avr-studio 4.11.410  Service Pack 3

hilfe ich weiß nicht mehr weiter........

[Johannes Raschke (Gast)]

Ich habe auch keine andere Erklärung als einen Compiler-Fehler. Hast Du
schon mal einen anderen Assembler probiert? Es gibt doch auch eine
Kommandozeilen-Version davon...
Ich würde Atmel mal direkt danach fragen...

Johannes