RAM-Zugriffsfehler auf Adr. 0x500

Markus Altmann Gast #99896
Lesenswert?
• ▲
▼ 
Hallo,
Ich arbeite mit einem ATmega162, avr-gcc 3.3.1, binutils 2.14 (avr-ld
2.14 20030612)

Ich habe folgendes Problem:
Beim Aufruf einer Funktion wird der Pointer auf eine lokale Variable
übergeben um der Funktion zu ermöglichen dorthin zu schreiben.

Dieser Pointer zeigt allerdings ausserhalb des gültigen RAM Bereiches
der bei 0x4FF endet
Er zeigt auf 0x500!


Ich habe einen Auszug der Ausgabe von nm beigefügt wo ich aber keinen
Fehler erkennen kann.
Die relevanten Codeteile sind auch dabei.

Ich verwende das Standard Linker Script und verwende auch sonst keine
besonderen Compiler-Parameter
CFLAGS   = -g -Wall -O -mmcu=atmega162 -I/usr/avr/include
LDFLAGS  = -Wl,-t,-Map,main.map

Ich habe diese Routine auch schon simuliert, allerdings kompiliert für
den mega16 da der mega162 von simulavr nicht unterstützt wird, die
Routine funktioniert, es dürfte sich eher um ein
Implementierungsproblem handeln.


Hat jemand eine Idee?

PS Arbeitet eingentlich sonst auch jemand mit dem mega162, hab im Forum
noch selten was drüber gefunden?

Danke für die Hilfe
Markus
Angehängte Dateien:
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Jörg Wunsch Gast #99897
Lesenswert?
• ▲
▼ 
Würde nach Bug klingen, kann ich aber nicht reproduzieren.

Das generierte .s sieht bei mir so aus:

        ldi r28,lo8(__stack - 6)
        ldi r29,hi8(__stack - 6)
        out _SP_H_,r29
        out _SP_L_,r28
        movw r16,r28
        subi r16,lo8(-(1))
        sbci r17,hi8(-(1))
        push r17
        push r16
        ldi r24,lo8(.LC1)
        ldi r25,hi8(.LC1)
        push r25
        push r24
        call printf
        movw r24,r16
        call getRTC

d. h. rr16..17 führen die Adresse Deiner lokalen Variablen, und die
werden auf __stack - 6 + 1 initialisiert.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Markus Altmann Gast #99898
Lesenswert?
• ▲
▼ 
Hallo Jörg,
Ich habe meine main() mit dem Attribut naked versehen um Platz zu
sparen, da ich der Meinung war, dass diese Funktion nicht umbedingt
einen Pro- bzw. Epilog braucht, damit bin ich aber anscheinend falsch
gelegen.

Sobald ich dieses Attribut weglasse funktioniert es.

Kannst du mir da den Grund nennen?

Eine andere Frage wie bekomme ich die .s files wie du sie geposted
hast?
Ich habe bis jetzt immer nur im list file nachgeschaut um zu sehen was
der Compiler produziert, wo z.B ein call nur mit der Sprungadresse
sichtbar ist und nicht mit dem dazugehörigen Funktionsnamen.

Gruß Markus
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg Wunsch Gast #99899
Lesenswert?
• ▲
▼ 
> Ich habe meine main() mit dem Attribut naked versehen um Platz zu
> sparen, [...]

Pilot error. ;-)

Wie Du siehst, brauchst Du den Prolog/Epilog (zur Erzeugung der
auto-Variablen), sonst würde ihn der Compiler sowieso weglassen.

Solche Details solltest Du natürlich mit posten...

> Eine andere Frage wie bekomme ich die .s files wie du sie geposted
> hast?

Compileroption -S statt -c (ggf. auch das -g weglassen).  Bei
passendem Makefile genügt es, `make foo.s' zu schreiben.  (Wichtig:
kleines .s, ein großes .S ist was anderes.)

Warum die Leute alle so auf diese Disassembler-Listings stehen, kann
ich Dir auch nicht sagen.  Ich mag den direkt produzierten
Assemblercode lieber -- auch wenn er nicht den C-Code enthält, der
wird im combined listing nachträglich anhand der Debuginfo wieder
eingefügt.  Wenn man das -g dringelassen hatte, kann man anhand der
.stabn-Anweisungen die Zeilennummern verfolgen.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren