Hallo zusammen, bitte entschuldigt die merkwürdige Überschrift - aber ich habe keine bessere Beschreibung. Ich nutze Atmel Studio 6 und einen ATmega32. Beim build habe ich eine Fehlermeldung des Linkers, die ich überhaupt nicht einordnen kann, alle vom Typ: "C:\Users\Nicolas\Desktop\SVN\Funkenerodierer\AVR_FirmwareAS6\Pulsgenera tor04\default/.././edm.c:103:(.text+0x110): relocation truncated to fit: R_AVR_13_PCREL against symbol `pwm_disable' defined in .text section in pwm.o" und das ganze für recht viele Funktionen, die alle für sich problemlos funktionieren, d.h. keine Funktion lädt plötzlich eine neue Library. Hat jemand einen Anhaltspunkt für die Fehlersuche? Viele Grüße Nicolas
Die Objektmodule, für die der Linker das beanstandet, wurden laut diesem Build-Log soeben nicht neu gebaut. Bist du dir sicher, dass für deren Compilieren auch -mmcu=atmega32 gesetzt war?
Hallo Jörg, danke, daß Du Dir diesen Wust angesehen hast. Ich bin mir zumindest sehr sicher, daß das Objectfile noch nie für ein andere Target als den ATmega32 erzeugt worden ist. Aber Du hast Recht: Ich hätte besser das Log eines kompletten Rebuilds gezeigt. Ich konnte den Fehler jetzt auf ein paar snprintf auf static uint8_t-Variablen in der Datei "edm.c" eingrenzen (Sprich: sind die auskommentiert, geht alles sichtbare so, wie ich es erwarte). Mir ist die Ursache noch etwas rätselhaft, aber ein Ansatz zur Behebung ist jetzt da. Viele Grüße Nicolas
Beim Relozieren kann ein relativer Sprung nicht aufgelöst werden, weil da, wo die Relokation eingetragen werden soll, nur ein 13-Bit-Feld zu Verfügung steht, aber die Distanz größer als 13 Bit ist. Siehe http://www.technovelty.org/c/relocation-truncated-to-fit-wtf.html
Hallo Konrad, Du meinst die Objekte liegen weiter als 8kB auseinander und der Linker schafft das nicht mehr, die Teile sinnvoll anzuordnen? Die Größenordnung von 8kB für das Hex-File könnte tatsächlich so langsam erreicht werden (die genaue Größe kann ich momentan nicht prüfen) - ist das eine harte Grenze für irgendetwas und gibt es "Programmierrichtlinien über 8kB"? Viele Grüße Nicolas P.S.: Nach dem Artikel scheint es ein Problem der Buildoptionen zu sein. Vielleicht '-mshort-calls'? Also wird der zweite Schritt die Suche in die Richtung sein.
OK, bin durch Zufall gerade drauf gestoßen: http://www.nongnu.org/avr-libc/user-manual/using_tools.html > -mshort-calls > > Use rjmp/rcall (limited range) on >8K devices. On avr2 and avr4 > architectures (less than 8 KB or flash memory), this is always the case. > On avr3 and avr5 architectures, calls and jumps to targets outside the > current function will by default use jmp/call instructions that can cover > the entire address range, but that require more flash ROM and execution > time. d.h. die Build-Optionen passen einfach nicht mehr, wenn der Flash >8kB benötigt wird. Komisch, daß Atmel Studio die Defaultoptionen so "gefährlich" setzt. Bleibt die Frage: Kann ich den Build so ändern, daß kurze Sprünge immer reichen, z.B. große Lookuptables irgendwie in die Näher der sie aufrufenden Funktionen rücken? Viele Grüße Nicolas
Nicolas S. schrieb: > -mshort-calls > Ach du Sch***. Die war mir entgangen. Diese Option hätte nie im GCC implementiert werden dürfen, und erst recht nicht im AVR Studio den Nutzern zugänglich gemacht werden. Auf einem Controller mit mehr als 8 KiB Flash müssen by default lange Aufrufe benutzt werden (CALL statt RCALL). Wenn überhaupt, kann man dem Linker (mit -mrelax) es überlassen, daraus wieder kurze zu machen, denn der weiß, wo die einzelnen Funktionen liegen. Andererseits ist der Performancegewinn minimal, kann man also auch sein lassen. lookup tables liegen ohnehin direkt bei den Funktionen, die sie benötigen, aber das spielt keine große Rolle.
Nicolas S. schrieb: > Komisch, daß Atmel Studio die Defaultoptionen so > "gefährlich" setzt. Macht es nicht. Das hast du selber irgendwann mal angeklickt/eingetragen.
Mag sein, daß es durch die Konvertierung von AVR-Studio 4 auf Atmel-Studio 6 (ich bin gerade dabei, ein 2 Jahre liegengebliebenes Projekt fortzuführen) irgendwie hineingekommen ist. Normalerweise halte ich mich mit dem Auswählen von Optionen, deren Zweck mir nicht völlig klar ist, sehr zurück und gehe davon aus, daß die Standardoptionen durchaus einen Sinn haben. Naja, ganz ausschließen kann man es nie, in mehreren Jahren ein Häkchen womöglich angeklickt zu haben. Also ist es vielleicht eine gute Idee, das Projekt unter AtmelStudio 6 noch einmal neu aufzusetzen - wer weiß welche Settings sonst noch implizit übernommen wurden aus den Zeiten, wo es mal unter AVR Studio 4 auf einem ATmega48 aufgesetzt wurde, und womöglich erst mit zunehmender Codegröße zum Vorschein kommen. Allein daß der Projektname, der an allen möglichen Stellen als Dateiname auftaucht nun wirklich überhaupt nichts mehr mit dem gegenwärtigen Entwicklungsziel zu tun hat nervt schon ein bischen. Vielen Dank für die Unterstützung Nicolas
Jörg Wunsch schrieb: > Nicolas S. schrieb: >> -mshort-calls > > Diese Option hätte nie im GCC implementiert werden dürfen, [...] Ab 4.8 ist wieder aus dem Compiler entfernt :-) > On AVR, support has been removed for the command-line option > -mshort-calls deprecated in GCC 4.7. http://gcc.gnu.org/gcc-4.8/changes.html
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.