relocation truncated to fit

[Bumbum]

Ich habe es jetzt gerade noch mal probiert und jetzt läuft es. Das Programm ist schon ein paar Tage fertig und funktioniert, ich bin zur Zeit nur noch am Feinschliff und Optimieren. Es wurden inzwischen eine handvoll Codezeilen an verschiedenen Stellen geändert und nun taucht der Fehler nicht mehr auf. Seltsam!

Vorschlag 2 hatte ich bereits probiert, das hat nicht zum Erfolg geführt.

Welche U16 bzw. U8 meintest du genau?

[SprinterSB]

Das Problem ist ein zu großer Offset in einem relativen Spring, vermutlich wegen inline assembler.

Wie sieht das mit -save-temps erzeugte Präcompilat (i-File) und das s-File aus?

[Bumbum]

Guten Morgen SprinterSB,

danke für deine Erklärung. Ich nutze kein inline assembler. Woran hätte es dann noch liegen können?

Wie lange dürfen denn die Sprünge sein, bzw. entscheidet nicht der Compiler bzw. Linker, ob er einen relativen oder absoluten Sprung machen muss?

Mein Controller ist fast voll (>99%). Ich nutze eine eigene Bibliothek (LCD). Die Funktionen daraus werden überall im Programm verwendet. Da der Fehler auch beim Aufruf einer Funktion aus dieser Bibliothek aufgetreten ist, und du sagst dass ein Sprung zu lange ist vermute ich das die Bibliothek nicht "in der Mitte" des Programms gelinkt werden konnte und somit vielleicht der Fehler aufgetreten ist.

Leider kann ich den Fehler nicht mehr reproduzieren. Ich hätte ein Backup vom "defekten" Stand machen sollen für weitere Analysen.
Aber die Hauptsache ist ja, dass es jetzt funktioniert.  

Viele Grüße
Andreas

[SprinterSB]

Dazu kann man nur eine Aussage machen, wenn man das nachvollziehen kann. Ansonsten ist's Rumgerate.

Evtl. war auch der µC voll und ein Spring ging zu dem Stück > 100%. Oder du verwendest Optionen wie -mshort-calls ohne zu wissen, was du tust