mikrocontroller.net

Forum: Compiler & IDEs Error: Operand Out Of Range


Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Beim Kompilieren meines SourcesCodes erscheinen folgende Fehler:

C:\{Pfad} ccEXaaaa.s: 2492: Error: operand out of range: -2049
C:\{Pfad} ccEXaaaa.s: 2495: Error: operand out of range: -2051
C:\{Pfad} ccEXaaaa.s: 2498: Error: operand out of range: -2053
C:\{Pfad} ccEXaaaa.s: 2501: Error: operand out of range: -2055
C:\{Pfad} ccEXaaaa.s: 2504: Error: operand out of range: -2057

Ich habe schon verschiedene Möglichkeiten probiert und 
selbstverständlich auch im Internet bzw. verschieden Foren gesucht, bin 
dabei aber leider nicht glücklich geworden. Aus diesem Grund wollte ich 
euch bitten, mir bei diesem Problem behilflich zu sein!

Vielen Dank im Voraus!

LG NoSiCo

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
ohne sourcecode wird das sicher nichts, denke ich. es sei denn, jemand 
packt seine glaskugel aus und schaut da mal nach :)
bye kosmo

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Kosmo!

Yep, da hast Du sicherlich Recht, habe den Beitrag ein bisschen 
überstürzt, aber genau hier beginnt mein Problem ;)

Ich verwende einen ATMega2560 und das derzeitige HEX-File weißt eine 
Größe von 12KB auf. Es ist noch nicht sehr viel inkludiert außer SPI und 
USARTs.
Der oben beschriebene Fehler erscheint auch nicht immer und vorallem ist 
er nicht auf einzelene Zeilen/Operationen beschränkbar. Ich habe zum 
Beispiel ca. 7 Zeilen, die folgendermaßen aussehen:

RTC_date = ((temp & 0x30) >> 4)*10 + (temp %10);

Wenn ich jetzt aber mehr als 5 von diesen 7 Zeilen stehen lasse (egal 
welche, switchen bringt keinen Unterschied!!!), dann erscheinen die 
Fehler! Ich tippe mal Richtung Makefile, kann aber den Verdacht nicht 
untermauern. Ich finde es nur sehr faszinierend, dass es bei der 
gesamten Problematik nicht davon abhängt, "welchen Sourcecode ich 
schreibe".

LG NoSiCo

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie sind RTC_date und temp deklariert? Was steht in der temporären Datei 
ccEXaaaa.s in den Zeilen 2492, 2495, 2498, 2501, 2504?

Wenn du die temporäre Datei nicht einsehen kannst, versuche es mit einer 
Compilierung mit der -S Option (Ausgabe als Assemblerquelltext).

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RTC_date und temp sind beide BYTE (#define BYTE  unsigned char).

Hm. leider kann ich "ccEXaaaa.s" nicht einsehen, jetzt probiere ich es 
mal die dem Assemblerquelltext.

Ich möchte aber noch anmerken, dass dieser Fehler nicht das erste mal 
bei meinen Programmen auftritt, sondern viel öfter erscheint. Wie 
gesagt, ich kann dabei nie auf einen offensichtlichen Fehler in einer 
Zeile schließen, es sieht eher danach aus, wie wenn den uCs der Speicher 
ausgeht, aber auch das kann ich ausschließen, da ich der Fehler 
teilweise damit behoben werden kann, dass ich an völlig anderen Stellen 
im Courcecode etwas streiche!

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ich nehme an, die ca. 7 zeilen unterscheiden sich, ansonsten spielt dir 
bekanntlich der optimierer einen streich.
schau mal, ob du den asm-code zusammenkriegst, wie stefan vorgeschlagen. 
und die deklarationen auch.

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yep, die 7 Zeilen unterscheiden sich ;)

Hm, ich habe leider noch nicht herausgefunden, wo ich dieses "-s" 
schreiben muss, damit mir ein Assembler-Code ausgegeben wird, weil ich 
das bis dato noch nie gemacht habe.

Ich habe aber jetzt einmal die Optimierung auf -00 gestellt und die 
Fehler sind weg :|

Ich werde mich aber auf alle Fälle wieder melden, wenn ich weiß, wie das 
mit dem AssemblerCode aussieht!


LG NoSiCo

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NoSiCo wrote:

> Hm, ich habe leider noch nicht herausgefunden, wo ich dieses "-s"
> schreiben muss, damit mir ein Assembler-Code ausgegeben wird, ...

Es ist ein -S (das ist was anderes).  Du gibst es statt eines -c
beim Aufruf des AVR-GCC an.

Wenn du das Makefile von WinAVR nimmst, genügt es, wenn du auf der
Kommandozeile "make foo.s" sagst, wenn deine C-Datei "foo.c" heißt.

Welchen Compiler nimmst du für den ATmega2560, die AtmanAVR-Variante?

> Ich habe aber jetzt einmal die Optimierung auf -00 gestellt und die
> Fehler sind weg :|

Ja klar.  Ist ja dann auch komplett anderer Code, der da generiert
wird.

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Guten Morgen!

Die Fehlermeldungen beziehen sich jetzt auf die Zeilen: 3047, 3049 und 
3936. Im folgenden habe ich die ASM-Codezeilen aus main.o reinkopiert:

3044: /* #NOAPP */
3045:  rcall init_ports
3046: .LM318:
3047:  rcall init_uart0
3048: .LM319:
3049:  rcall init_uart1
3050: .LM320:
3051:  rcall init_uart2
3052: .LM321:
3053:  rcall init_uart3
3054: .LM322:
3055:  rcall SPI_MasterInit

3932: .LM380:
3933:  lds r24,b
3934:  lds r25,(b)+1
3935:  subi r24,lo8(-(32))
3936:  rcall u2_s_data

void init_uart0(void)
{
  UBRR2L = 25;
  UCSR2B = 0xD8;
  UCSR2C = 
((0<<UMSEL21)|(0<<UMSEL20)|(1<<UPM20)|(1<<UPM21)|(1<<UCSZ21)|(1<<UCSZ20) 
);
}


void u2_s_data(BYTE address)
{
  volatile BYTE temp = 0;

  PORTB |= (1 << R_W_2);      // Auf senden umstellen

  while (!(UCSR2A & (1<<UDRE2))) {}
  UDR2 = address;
  u2_crc_c  = address;
         while (!(UCSR2A & (1<<UDRE2))) {}
  UDR2 = u2_s_adr_t;
  u2_crc_c ^= u2_s_adr_t;  // Source-address (transcieved)
         .
         .
         .
}

Hm, ich versteh einfach nicht, warum ich diese Fehlermeldungen erhalte!

LG NoSiCo



Autor: johnny.m (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem kann ich zwar nicht für Dich lösen, aber "volatile" macht 
bei lokalen Variablen keinen Sinn. Das geht nur mit globalen...

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, Kopierfehler!

void init_uart0(void)
{
  UBRR0L = 25;    // 38462 (0.2%)
  UCSR0B = 0xD8;
  UCSR0C = 
((0<<UMSEL01)|(0<<UMSEL00)|(1<<UPM00)|(1<<UPM01)|(1<<UCSZ01)|(1<<UCSZ00) 
);
}

Achja, wenn ich init_uart0 rausnehme, bekomme ich den Fehler bei 
init_uart1 und wenn ich die dann auch rausnehme ist er weg!?!

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
macht's dir was aus, mal den gesamten -S -output zu dieser datei zu 
posten oder besser in eine datei zu packen und schicken?
bye kosmo

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NoSiCo wrote:

> Die Fehlermeldungen beziehen sich jetzt auf die Zeilen: 3047, 3049 und
> 3936.

> 3047:  rcall init_uart0

Nun, was wird es wohl bedeuten, wenn der Operand eines rcall out of
range ist?

Du solltest an dieser Stelle keine rcalls benutzen, sondern calls.

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
da hat der große meister recht:

http://www.mikrocontroller.net/articles/AVR_Assemb...

auszug:"Mittels rcall ist es nur möglich, relative Adressen im Bereich 
von -2K+1 und +2K Worten anzuspringen"

bei dir:
-2049
-2051
-2053
-2055
-2057

(gut zu wissen, habe ich bisher noch nirgends bei avr gelesen)

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ich weiß, dass ich schön langsam zu nerven beginne, aber ich weiß 
jetzt nicht, wie ich in C zw. CALL und RCALL unterscheiden kann. :( Kann 
mich hier jemand bitte einen hint geben? Danke!

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Du solltest an dieser Stelle keine rcalls benutzen, sondern calls.

Wenn ich ihn richtig verstanden habe, dann schreibt
er ja gar nicht in Assembler sondern in C.
Es ist also der Compiler, der den Murks macht.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann stellst sich doch direkt die Frage, welcher Prozessor beim 
Kompilieren eingestellt ist.

Was steht in der Kommandozeile (Beispiel -mmcu=atmega8) oder im Makefile 
(Beispiel MCU=atmega8)?

Vielleicht ist dort ein "kleiner" AVR eingestellt und die 
Codeoptimierung innerhalb GCC geht davon aus, dass auf dem "Kleinen" 
RCALLs immer passen.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nur zur Erinnerung, diese Frage von Jörg ist auch noch offen:

"Welchen Compiler nimmst du für den ATmega2560, die AtmanAVR-Variante?"

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
nein, habe eigentlich im Makefile den richtigen uC eingestellt: 
MCU=atmega2560

Hm, ich weiß leider nicht, ob ich die AtmanAVR-Variante verwende oder 
nicht, weil ich nicht weiß, was das ist :(

Falls es weiterhilft: WinAVR vom 20060421 (AVR-gcc3.4.6)

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NoSiCo wrote:

> Falls es weiterhilft: WinAVR vom 20060421 (AVR-gcc3.4.6)

Mit Sicherheit nicht, weil der keinen ATmega2560-Support hatte.

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ok, habe auf ATMega 1280 umgestellt, sowohl Hard- als auch Software, 
aber leider noch immer daselbe Problem, ich weiß nicht, wie ich die 
RCALLs in CALLs wandeln kann, da ich mit C programmiere!

Außerdem ist ein neuer für mich absolut unerklärlicher Fehler 
aufgetreten, obwohl ich in diesem Bereich nichts geändert habe:

g:\{Pfad}\SPI.c:9 relocation truncated to fit: R_AVR_13_PCREL against 
symbol '__udivmoidqi4' defined in .text.libgcc section in 
C:/{Pfad}/libgcc.a(_udivmodqi4.o)

8: void SPI_MasterTransmit(BYTE cData)
9: {
10:   SPDR = cData;  // Start transmission
11:   while(!(SPSR & (1 << SPIF)));// Wait for transmissionc omplete
12:}

Außerdem wird mir dieser Erorr ca. 10 mal angezeigt :(

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
warum updatest du nicht mal auf aktuelles zeug? find ich irgendwie 
sinnvoller, als die hw zu wechseln.

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
entschuldigung, winavr ist wohl aktuell, vergiss den letzten unsinn von 
mir :(

benutze ich selber nicht, daher. weiß aber, dass der avr-gcc bei 4.1.1 
ist, iirc.

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weil es laut "http://sourceforge.net/"; die aktuellste Version ist

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hast ja recht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NoSiCo wrote:

> Ok, habe auf ATMega 1280 umgestellt, sowohl Hard- als auch Software,
> aber leider noch immer daselbe Problem, ich weiß nicht, wie ich die
> RCALLs in CALLs wandeln kann, da ich mit C programmiere!

Kannst du den relevanten Sourcecode posten?

Ich fürchte immer noch, dass das ein pilot error irgendwie ist.

> g:\{Pfad}\SPI.c:9 relocation truncated to fit: R_AVR_13_PCREL against
> symbol '__udivmoidqi4' defined in .text.libgcc section in

Linke bitte immer gegen -lm (libm.a), insbesondere dann, wenn du mit
Gleitkommazahlen in irgendeiner Form arbeitest.  (Da gibt's einen
known bug, der nicht so einfach zu reparieren ist.)  Wenn sie nicht
gebraucht wird, stört sie auch nicht.

Autor: NoSiCo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe leider ein Problem damit, dass ich den relevanten Sourcecode 
poste, weil die Fehler quer durch den gesamten Sourcecode springen. 
Einmal sind sie in Zeile 2400, dann wieder in 4500 (z.B. Port_init), das 
nächste mal wieder ganz wo anders. Ich bin schön langsam am verzweifeln, 
weil kein Vorwärtskommen erkennbar ist.
Wenn ich irgendwo anders wieder einen Teil eines Sourcecodes 
rauskommentiere (der hat gar nichts damit zu tun!), dann funktioniert es 
wieder, aber ich habe derzeit erst ein 10K-Hex-File.

Hm, ist es vielleicht möglich, dass jemand ein Makefile zur Verfügung 
stellt, weil so wie es aussieht (Beispiel -lm) gibt es vielleicht doch 
noch ein paar Dinge, die ich noch nicht habe.

Vielen Dank und LG NoSiCo

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.