relocation truncated to fit - msp430

[Patrick N. (patrick_n93)]

Hallo zusammen,

ich habe aktuell ein Problem mit meinem Code.
Bisher habe ich die msp430 Toolchain in der Version: 3.2.3 verwendet.
Nun habe ich die Maschine in Linux neu aufgesetz und mit die msp430-gcc 
toolchain aus dem Repo geholt (Version 4.6.3 20120406).

Wenn ich kompiliere, dann bekomme ich folgende Fehlermeldung:

/opt/dev/MED_Serie/MED_Bedienteil/msp430_dds/dds_brt.c:47: relocation truncated to fit: R_MSP430_16_PCREL_BYTE against symbol `reload_mod_freq' defined in .data section in objs/dds_brt.o
/opt/dev/MED_Serie/MED_Bedienteil/msp430_dds/dds_brt.c:47: relocation truncated to fit: R_MSP430_16_PCREL against symbol `mod_freq' defined in .bss section in objs/dds_brt.o
/opt/dev/MED_Serie/MED_Bedienteil/msp430_dds/dds_brt.c:47: relocation truncated to fit: R_MSP430_16_PCREL against symbol `mod_freq' defined in .bss section in objs/dds_brt.o
/opt/dev/MED_Serie/MED_Bedienteil/msp430_dds/dds_brt.c:47: relocation truncated to fit: R_MSP430_16_PCREL_BYTE against symbol `reload_mod_freq' defined in .data section in objs/dds_brt.o

Ein linker script war bisher nicht vorhanden ... aber folgende Aufrufe 
in der makefile:

CPU    =  msp430f1121
ASMOPT = -mmcu=${CPU}
COPT   = -mmcu=${CPU} -pipe -Os -W -Wall -ggdb -Wa,-aldh,>$(<:.c=.lst) -ffixed-r9

OBJ_MRT=objs/dds_mrt.o objs/spi_handler.o
OBJ_BRT=objs/dds_brt.o objs/spi_handler.o

Erstellung Objekt files: msp430-gcc mmcu=msp430f1121 -pipe -Os -W -Wall -ggdb -Wa,-aldh,>$(<:.c=.lst) -ffixed-r9 -c $< -o $@

Scheiternder Aufruf:
dds_brt.elf: ${OBJ_BRT}
  msp430-gcc -mmcu=${CPU}   -Wl,-Map,dds_brt.map -o $@ $^

Der code sieht wie folgt aus:

void dds_loop(void)
{
  asm(
       "reload:                      \n\t"
      "  tst.b  reload_mod_freq     \n\t"
      "  jz     rel_ma              \n\t"  // Modulationsfrequenz neu laden?
      "  mov    mod_freq, r4        \n\t"
      "  mov    mod_freq+2, r5      \n\t"
      "  clr.b  reload_mod_freq     \n\t"  // Flag l�schen 
      "rel_ma:                      \n\t"
)
}
.....

volatile unsigned long mod_freq=0; 
volatile ubyte reload_mod_freq=1; 
...

Das ganze spiel geht mit mehreren unterschiedlichen Variablen weiter, 
ich habe hier jetzt mal nen ausschnitt gepostet, da der restliche code 
eh auskommentiert ist.

Vielen dank für die Unterstützung

Patrick

[Clemens L. (c_l)]

> relocation truncated to fit: R_MSP430_16_PCREL_BYTE

Das bedeutet, dass die Daten mehr als 2^16 Bytes vom Code entfernt 
liegen. Was beim MSP430 eigentlich nicht möglich ist.

Kannst du mit diesen Compiler ein Hello-World (Blinky) kompilieren?

>       "  mov    mod_freq, r4        \n\t"

Warum mod_freq (PC-relativ) statt &mod_freq (absolut)?

[Patrick N. (patrick_n93)]

Hallo Clemens,

danke für deine Antwort.

Den Code habe ich so vom vorherigen Entwickler übernommen, was er sich 
hierbei gedacht hat kann ich dir leider nicht sagen ;)



Ich weiß nur, dass in einer anderen Schleife die Werte wie z.B. 
reload_mod_freq geändert werden und ein flag gesetzt wird (Reload Data).

Der asm prüft nach jedem Schleifendurchlauf ob reload_data null ist und 
springt sonst in den Haupt Code.

Eine .ld Datei ist für das Projekt auch nicht vorhanden.



Frage:
Macht es einen sonstigen unterschied das & davor zu schreiben?
Bei c würd ich sagen macht sinn, ich nehme das & davor um auf die 
Referenz der Variable zuzugreifen .. mit asm kenn ich mich leider zu 
wenig aus ;)



Interessant ist, dass der Code bei der Version 3.2.3 problemlos 
funktioniert, bei der von mir installierten Version das ganze jedoch zu 
einem Fehler führt.

Zusätzlich würde ich vielleicht noch hinzufügen, dass ich in der 
Makefile folgendes angepasst habe

Alt: CPU    =  msp430x1121
Neu: CPU    =  msp430f1121

LG

[DPA (Gast)]

Gibt es einen Grund, das nicht in c zu schreiben?

void dds_loop(void)
{
  unsigned long temp;
  if(reload_mod_freq){
    temp = mod_freq;
    reload_mod_freq = 0; 
  }
  
}

[Patrick (Gast)]

Ich hab’s nicht programmiert aber es wird im Endeffekt eine Welle 
generiert die ausgegeben wird.

Laut des Entwicklers: Performance bzw höhere raten

[Rufus Τ. F. (rufus)]

Clemens L. schrieb:
> Das bedeutet, dass die Daten mehr als 2^16 Bytes vom Code entfernt
> liegen. Was beim MSP430 eigentlich nicht möglich ist.

Es ist beim MSP430X möglich, das ist der CPU-Kern, der in den Varianten 
mit mehr als 64* kiB Flash-ROM verwendet wird (wie z.B. dem 'F5438).

*) genauer: Bei den Varianten, bei denen die Summe RAM + Flash-Größe + 
I/O größer ist als 64 kiB

[Clemens L. (c_l)]

Patrick N. schrieb:
> Macht es einen sonstigen unterschied das & davor zu schreiben?

Nein, ist genauso schnell. (Und hat mit C nichts zu tun.)

> Laut des Entwicklers: Performance bzw höhere raten

Und das -ffixed-r9 zeigt, dass dort noch interessantere ASM-Schnipsel 
verwendet werden.

Hast du mal einen Compiler probiert, der frischer als von 2012 ist?
Oder warum benutzt du nicht die alte Compiler-Version?

[Rufus Τ. F. (rufus)]

Rufus Τ. F. schrieb:
> Es ist beim MSP430X möglich,

Nachtrag: Dieser Kern wird im (steinalten) 'F1121 nicht verwendet, den 
hatte ich vorher übersehen.

[Patrick N. (patrick_n93)]

Rufus Τ. F. schrieb:
> MSP430X mö

Was genau meinst du mit "nicht verwendet"?



Ich hab die Entwicklungsumgebung auf Ubuntu umgezogen und mir den 
Compiler über die apt-get resources gezogen.

Den alten Compiler habe ich für Linux leider nicht gefunden.

@Clemens:
Was meinst du mit "interessantere" Schnipsel?



Also kann ich den X nicht gegen den F ersetzen?
Die version X1121 ist im Compiler leider nicht verfügbar

VG

[Rufus Τ. F. (rufus)]

Patrick N. schrieb:
> Was genau meinst du mit "nicht verwendet"?

Der 'F1121 hat den alten MSP430-Kern mit reinen 16-Bit-Adressen, da auch 
kein naher Verwandter aus der gleichen Serie auch nur ansatzweise 64 kiB 
Flash-ROM hat (der 'F1121 ist schon der größte mit 4 kiB Flash-ROM).

Bei neueren Familien, die mehr als 64 kiB Flash haben können (wie eben 
der 'F5438) wird der MSP430X-Kern mit 20-Bit-Adressen verwendet.

Welchen Grund hat es, daß Du heute noch mit diesem Fossil arbeitest?

(Nein, der 'F5438 ist kein Gegenvorschlag, aber der 'G2553 wäre einer, 
ebenfalls im 20-Pin-Gehäuse, mehr Flash-ROM, mehr RAM, per SBW 
ansprechbar, mehr und bessere Peripherie (z.B. eine UART) ... und kostet 
weniger)

[Patrick N. (patrick_n93)]

Danke Rufus für die Info.

Das Gerät wurde 2007 gebaut und mit dem MSP430X1121 ausgestattet.
Seitdem wurde ausschließlich Software Entwicklung betrieben, da es sich 
jedoch um ein med Produkt handelt keine Änderungen an der Hardware 
vorgenommen.

Ich werde mir die Spezifikationen des G2553 mal anschauen ;) vielleicht 
wäre dann ein Wechsel ratsam

[Rufus Τ. F. (rufus)]

Patrick N. schrieb:
> und mit dem MSP430X1121 ausgestattet

X? Es gibt den als C und F, was soll X sein?

C wirst Du nicht meinen, das ist die uralte (Masken-) ROM-Version.

Für den 'G2553 gibt es ein kostengünstiges Entwicklungsboard, das 
G2-Launchpad. Das wurde von TI eine Zeit lang für 4.30 USD verkauft - 
inklusive Versand, auch nach Europa. Jetzt bekommt man es für irgendwas 
um die 10 EUR.

Auf dem Board ist ein SBW-Debuginterface drauf, ältere Ausführungen 
verwendeten dazu die Elektronik des MSP-FET430UIF (mit anderer Firmware 
und fehlenden JTAG-Leitungen), die neuste Ausführung nutzt ein neueres 
MSP-FET-Interface.

Und für Bastler ist der 'G2553 auch reizvoll, das ist der größte MSP430 
im DIP-Gehäuse (abgesehen von einem nur über Olimex beziehbaren Exoten 
im 40poligen DIP-Gehäuse).