Forum: Mikrocontroller und Digitale Elektronik Fehler beim Linken : relocation truncated


von Martin H. (e-hermes)


Lesenswert?

Hallo,

schreibe einen Bootloader fuer den at90usb1287. Die Interruptvektoren 
linke ich an Adresse 0x0000. Den restlichen Code (.text) moechte ich an 
die Adresse 0xf000 linken.

Allerdings erhalte ich die Fehlermeldung:
int.o:(.vectors+0x0): relocation truncated to fit: R_AVR_13_PCREL 
against `no symbol'

zurueck.

Linke ich die .text section unterhalb 0x0ff4, geht alles gut. Erst wenn 
ich die section an eine hoehere Adresse linke, tritt dieser Fehler auf.

Weiss jemand Rat? Oder hat jemand eine Idee den Fehler zu finden?

Vielen Dank

Martin

von Markus E. (engelmarkus)


Lesenswert?

Hm... zeig mal dein Linkerfile her. Das heißt normalerweise, dass er 
beim Linken irgendeine Adresse "absäbelt", weil die zu lang ist, als 
dass sie an die Stelle passen würde.
Außerdem siehe hier, selbes Problem: 
Beitrag "Wie lösen (float): relocation truncated to fit: R_AVR_13_PCREL"

von Alfred (Gast)


Lesenswert?

Hallo,

genau den hatte ich gestern. In meinem Fall fehlte ein -lm im 
Linkerbefehl und schon
war der Fisch geputzt. Hast Du alle von Dir benutzen Bibliotheken im 
Makefile (oder wo auch immer Du das in deiner Entwicklungsumgebung 
machst)??

Beste Grüße

Alfred

von Martin H. (e-hermes)


Lesenswert?

Hallo,

den vorhandenen Beitrag habe ich schon gesehen. Habe auch im Makefile 
die Mathe-Bibliothek hinzugelinkt mit -lm. Genutzt hat es nichts. Ich 
sehe auch die Notwendigkeit nicht ein, da ein Linken im unteren 
Adressbereich ja funktioniert.

Ich liefere hier mein Linkerskript:

MEMORY
{
  vec         (rx)      : ORIGIN = 0x0000, LENGTH = 0x008e
  text        (rx)      : ORIGIN = 0xf000, LENGTH = 0x0fff
  data        (rw!x)    : ORIGIN = 0x800060, LENGTH = 0xffa0
  eeprom      (rw!x)    : ORIGIN = 0x810000, LENGTH = 64K
  fuse        (rw!x)    : ORIGIN = 0x820000, LENGTH = 1K
  lock        (rw!x)    : ORIGIN = 0x830000, LENGTH = 1K
  signature   (rw!x)    : ORIGIN = 0x840000, LENGTH = 1K
}

SECTIONS
{
  .vec :
  {
    int.o(.vectors)
  } > vec
  .text :
  {
     int.o(.isr) *(.text) *(.init4) *(.text.avr-libc) *(.fini0)
  } > text
  .data : AT (ADDR (.text) + SIZEOF (.text))
  {
    PROVIDE (__data_start = .);
    PROVIDE (__data_load_start = .);
    *(.data)
    PROVIDE (__data_end = .);
    PROVIDE (__data_load_end = .);
  } > data
  .bss : AT (ADDR (.data) + SIZEOF (.data))
  {
    PROVIDE (__bss_start = .);
    *(.bss)
    PROVIDE (__bss_end = .);
    PROVIDE (__heap_start = .);
    PROVIDE (__heap_end = .);
    RAMEND = 0x20ff;
    __stack = RAMEND;
   } > data
}

Vielen Dank.

Gruss Martin

von (prx) A. K. (prx)


Lesenswert?

Martin H. schrieb:

> int.o:(.vectors+0x0): relocation truncated to fit: R_AVR_13_PCREL##
> against `no symbol'

Klingt nach RJMP mit unerreichbarem Ziel.

von Martin H. (e-hermes)


Lesenswert?

Hallo,

habe die ISR durch einen rjmp aus den Interrupt Vektoren angesprungen. 
Das war wohl die Ursache fuer den Fehler.

Jetzt verwende ich einen normalen jmp und alles ist in Ordnung.

Aus der Zusammenfassung der Instruktionen wird mir die Ursache 
allerdings nicht ersichtlich.

rjmp: PC <- PC + k + 1
jmp : PC <- k

Ich kann da keine Restriktionen fuer den relativen Sprung erkennen.

Kann mir das jemand erklaeren?

Vielen Dank fuer den Tipp.

Viele Gruesse

Martin

von (prx) A. K. (prx)


Lesenswert?

Martin H. schrieb:

> Ich kann da keine Restriktionen fuer den relativen Sprung erkennen.

-2K ≤ k < 2K

von Martin H. (e-hermes)


Lesenswert?

Gilt aber nach Datenblatt fuer rjmp wie fuer jmp.

von (prx) A. K. (prx)


Lesenswert?

Nein. Instruction Set Manual lesen, nicht Datasheet. JMP kann 8MB 
adressieren, RJMP nur +/-4KB.

Bitte 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
Noch kein Account? Hier anmelden.