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
hallo, ohne sourcecode wird das sicher nichts, denke ich. es sei denn, jemand packt seine glaskugel aus und schaut da mal nach :) bye kosmo
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
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).
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!
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.
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
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.
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
Das Problem kann ich zwar nicht für Dich lösen, aber "volatile" macht bei lokalen Variablen keinen Sinn. Das geht nur mit globalen...
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!?!
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
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.
da hat der große meister recht: http://www.mikrocontroller.net/articles/AVR_Assembler_-_Unterprogramme 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)
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!
> 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.
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.
Nur zur Erinnerung, diese Frage von Jörg ist auch noch offen: "Welchen Compiler nimmst du für den ATmega2560, die AtmanAVR-Variante?"
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)
Zu WinAVR + atmega2560 http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=42536&highlight=winavr+atmega2560 Zu AtmanAVR http://www.avrfreaks.net/modules.php?op=modload&name=News&file=article&sid=523&mode=thread&order=0&thold=0 http://www.atmanecl.net/EnglishSite/indexEnglish.htm
NoSiCo wrote:
> Falls es weiterhilft: WinAVR vom 20060421 (AVR-gcc3.4.6)
Mit Sicherheit nicht, weil der keinen ATmega2560-Support hatte.
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 :(
warum updatest du nicht mal auf aktuelles zeug? find ich irgendwie sinnvoller, als die hw zu wechseln.
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.
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.
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
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.